Deep Dive: Gemini CLI DevOps Extension

TL;DR

Google Cloud โชว์ Gemini CLI DevOps Extension ที่ทำให้ agent ไม่ได้หยุดแค่เขียน code แต่ช่วยพา code ไป cloud ได้ด้วย ตั้งแต่ deploy prototype ไป Cloud Run หรือ Cloud Storage ไปจนถึงช่วยออกแบบ Cloud Build pipeline, สร้าง Artifact Registry, ต่อ Git repository ผ่าน Developer Connect และตั้ง trigger ให้ deploy อัตโนมัติ

ผมชอบทิศทางนี้นะ เพราะปัญหาจริงของ AI coding ไม่ใช่ “เขียน app ได้ไหม” อย่างเดียว แต่คือ “ship แล้วดูแลได้ไหม” มากกว่า

แต่ห้ามอ่านเป็นใบอนุญาตให้ agent แตะ production แบบหลับตา repo ของ extension เองเขียนชัดว่า experimental, ต้อง review output และควรใช้ least privilege เสมอ

เรื่องนี้แก้ pain ตรงไหน

ยุคนี้คนทำ prototype ได้เร็วขึ้นเยอะ Antigravity, Claude Code, Gemini CLI หรือเครื่องมือ coding agent อื่น ๆ ทำให้จาก idea ไปเป็น app ในเครื่องเร็วมาก

ปัญหาคือหลังจากนั้น

• ต้องเขียน Dockerfile
• ต้อง build image
• ต้อง push ไป registry
• ต้องตั้ง IAM
• ต้องเขียน cloudbuild.yaml
• ต้องต่อ GitHub กับ Cloud Build
• ต้องตั้ง trigger

ตรงนี้แหละครับที่หลาย project ตายเงียบ ไม่ใช่เพราะ code ไม่เสร็จ แต่เพราะ deploy ไม่คุ้มแรงสำหรับ prototype เล็ก ๆ

บทความของ Google Cloud เรียกช่องว่างนี้ว่า inner loop กับ outer loop

• inner loop คือรอบเร็วในเครื่อง: เขียน, รัน, แก้, test
• outer loop คือรอบของ production: container, CI/CD, infra, IAM, deployment

Gemini CLI DevOps Extension พยายามให้ agent เดินข้ามสองโลกนี้ได้จาก terminal เดิม

extension นี้ประกอบด้วยอะไร

จากบทความและ repo gemini-cli-extensions/cicd โครงหลักมี 3 ชั้น

1. Skills

มี skill เฉพาะทาง เช่น google-cicd-deploy และ google-cicd-pipeline-design เพื่อบอก agent ว่าควรวิเคราะห์ code ยังไง, ควรถามอะไร, ควรหยุดตรงไหน และควรจัดการ error ยังไง

1. CI/CD MCP server

นี่คือมือของ agent ครับ ตัว MCP server ให้เครื่องมือที่เรียก Google Cloud ได้จริง เช่น scan secret, deploy Cloud Run, สร้าง Artifact Registry, สร้าง Cloud Build trigger หรือเชื่อม repository

1. Local knowledge base

มีฐานความรู้แบบ RAG สำหรับ pattern ด้าน architecture และ CI/CD เพื่อให้ agent ไม่เดาสุ่มจาก prompt อย่างเดียว

พูดสั้น ๆ คือ Google ไม่ได้บอกว่า “ให้ LLM ไปพิมพ์ gcloud มั่ว ๆ” แต่พยายามแพ็ก workflow, tools และ reference knowledge ให้เป็น extension ที่เรียกใช้ซ้ำได้

inner loop: deploy prototype ให้มี URL เร็วขึ้น

ตัวอย่างในบทความคือแอป React + Node.js Express ชื่อ Cosmic Guestbook จากนั้นใช้ prompt ประมาณนี้

gemini "Deploy this application to Google Cloud using the google-cicd-deploy skill"

ฝั่ง Claude Code หรือ Antigravity ก็มีแนวทางติดตั้ง/เรียกใช้ผ่าน plugin หรือ skills เช่นกัน

สิ่งที่ extension ทำใน flow นี้คือ

• scan secret ก่อน code ออกจากเครื่อง
• อ่านไฟล์อย่าง package.json หรือ go.mod เพื่อเดา framework
• ตัดสินใจว่า app ควรไป Cloud Storage หรือ Cloud Run
• ถ้าเป็น dynamic service และไม่มี Dockerfile ก็ใช้ Google Cloud buildpacks ช่วย containerize
• ถาม clarification ก่อน deploy เช่น region, public/private access, service name
• deploy แล้วคืน public URL

จุดที่ดีคือ agent ไม่ควรกด deploy เงียบ ๆ หากข้อมูลสำคัญหายไป ในตัวอย่างของ Google agent หยุดถาม region และ access ก่อนทำต่อ อันนี้เป็น pattern ที่ควรจำ เพราะ agent ที่ดีไม่ใช่ agent ที่ทำทุกอย่างเอง แต่คือ agent ที่รู้ว่าเมื่อไหร่ต้องถาม

outer loop: จาก deploy ครั้งเดียวไปเป็น pipeline

ถ้า prototype เริ่มจริงจัง การ deploy จากเครื่องไม่พอ ต้องมี source control, test, build และ deploy อัตโนมัติ

ตรงนี้ใช้ skill google-cicd-pipeline-design ให้ agent ทำหน้าที่คล้าย platform engineer ช่วยถาม requirement, เสนอ plan, provisioning resource และ generate cloudbuild.yaml

ตัวอย่าง resource ที่ extension แตะได้จาก repo คือ

• create_artifact_repository
• create_build_trigger
• create_git_connection
• create_git_repository_link
• deploy_cloudrun_service_from_source
• deploy_cloudrun_service_from_image
• scan_code_for_secrets
• search_cicd_patterns

ถ้ามองเชิง operation นี่ไม่ใช่ feature เล็กนะครับ เพราะมันเริ่มแตะจุดที่มีผลจริงกับ cloud bill, IAM และ deployment path ของทีม

ทำไม secret scan ถึงควรอยู่ต้น flow

บทความอ้าง GitGuardian 2025 ว่าปี 2024 พบ secret ใหม่บน public GitHub ประมาณ 23.8 ล้านรายการ และ secret ที่รั่วตั้งแต่ปี 2022 ยัง active อยู่ราว 70%

ตัวเลขนี้บอกอะไรเรา

มันบอกว่า “เดี๋ยวค่อยลบ secret” ไม่ใช่ strategy ที่ดี เพราะเมื่อ secret หลุดไปแล้ว หลายทีมไม่เคย rotate มันจริง ๆ

การให้ deploy agent scan secret ก่อนเอา code ออกจากเครื่องจึงเป็น guardrail ที่เข้าท่า โดยเฉพาะกับยุค vibe coding ที่คนทดลองเร็ว, copy paste เร็ว และบางทีก็ hardcode key ชั่วคราวจนลืม

แต่ต้องไม่เข้าใจผิด secret scan ไม่ได้แปลว่าปลอดภัยทั้งหมด มันเป็นแค่ด่านหนึ่ง ยังต้องมี IAM ที่แคบ, environment separation และ review pipeline อยู่ดี

จุดที่ทีมไทยควรระวังก่อนใช้จริง

ผมจะไม่เอา extension แบบนี้ไปเสียบ production project วันแรกครับ โดยเฉพาะ project ที่มี customer data หรือ cloud account ที่สิทธิ์กว้าง

เหตุผลคือ repo ของ gemini-cli-extensions/cicd เตือนชัดว่าเป็น experimental project และอาจแก้ resource ใน Google Cloud ตามสิทธิ์ของ Application Default Credentials ได้

Checklist ที่ควรมี:

• ใช้ sandbox project แยกก่อน
• ADC ต้องเป็น account ที่สิทธิ์แคบ ไม่ใช่ owner ทั้ง organization
• service account ของ pipeline ต้องใช้ least privilege
• ให้ agent สร้าง plan ก่อน apply
• review cloudbuild.yaml, IAM role และ trigger ทุกครั้ง
• log ทุก tool call ที่แตะ cloud resource
• ห้าม feed untrusted document เข้า context เดียวกับ deploy agent แบบไม่กรอง เพราะมี indirect prompt injection risk

พูดแรง ๆ คือ AI DevOps agent ดีมากสำหรับลด friction แต่ถ้าสิทธิ์มั่ว มันก็กลายเป็น intern ที่ถือกุญแจ data center

มุมธุรกิจ: สิ่งที่เปลี่ยนไม่ใช่แค่ developer speed

ถ้าเครื่องมือนี้ mature ขึ้น ผลกระทบจะไม่ใช่แค่ dev ทำงานเร็วขึ้น แต่จะเปลี่ยนวิธีที่ทีมเล็ก ship product

ทีมเล็กจะทำสิ่งเหล่านี้ได้ง่ายขึ้น:

• ทำ prototype ให้ลูกค้าลองจริงภายในวันเดียว
• เปลี่ยน demo ในเครื่องให้เป็น URL สำหรับ webhook, LINE OA, OAuth callback หรือ sales demo
• สร้าง pipeline ตั้งต้นโดยไม่ต้องเริ่มจาก YAML เปล่า
• ให้ founder หรือ product engineer คุยกับระบบ deploy ได้ โดยยังมี platform engineer review ทีหลัง

สำหรับตลาดไทย จุดนี้สำคัญมาก เพราะหลายทีมไม่ได้ขาดไอเดีย แต่ขาดคนที่ข้ามจาก code ไป infra ได้เร็วและปลอดภัยพอ

วิธีลองแบบไม่เจ็บตัว

ถ้าจะลอง ผมแนะนำ path นี้

1. สร้าง Google Cloud sandbox project ใหม่
2. ตั้ง budget alert และอย่าใช้ billing account หลักแบบไม่คุม
3. ใช้ account หรือ service account ที่สิทธิ์จำกัด
4. ติดตั้ง Gemini CLI และ extension ตาม docs
5. ลองกับ app ที่ไม่มีข้อมูลจริง
6. ให้ agent deploy แบบ inner loop ก่อน
7. อ่าน resource ที่ถูกสร้างใน console
8. ค่อยลอง pipeline design ใน repo ทดลอง
9. เก็บ cloudbuild.yaml เป็น code แล้ว review เหมือน PR ปกติ

อย่าเริ่มจาก production repo ครับ เริ่มจาก toy app ก่อน แล้วดูว่า agent คิดและถามอย่างไร

สรุป

Gemini CLI DevOps Extension เป็นสัญญาณว่าการเขียน code ด้วย AI กำลังขยับไปสู่การ ship ด้วย AI

นี่คือขั้นต่อไปที่สมเหตุสมผล เพราะ value จริงไม่ได้เกิดตอน code อยู่ใน laptop มันเกิดตอนระบบมี URL, มี pipeline, มี security gate และมีคนใช้จริง

แต่ DevOps agent ต้องอยู่ใต้ guardrail ที่ชัดกว่า coding assistant ทั่วไป เพราะมันแตะ cloud resource จริง เสียเงินได้จริง และพัง production ได้จริง

ใช้มันเป็น pair platform engineer ได้ แต่อย่าให้มันเป็น platform owner ตั้งแต่วันแรก