Ship code within minutes with the Gemini CLI DevOps Extension

With AI coding tools like Antigravity and Claude Code, I can build a working web app in record time. But deploying it? That's where I'd historically lose the rest of the afternoon to Dockerfiles, IAM bindings, and YAML. So I'd take the shortcut most developers take: I just wouldn't do it. The app would stay on my laptop, and my work would never ship.

This is the classic tension between the inner loop: the fast, local cycle of writing and testing code, and the outer loop: containerization, CI/CD pipelines, and production infrastructure. Most developers are productive in one but not the other, and the gap between them is where projects stall.

The Gemini CLI Extension for CI/CD bridges this gap. It handles both quick deployments and full pipeline generation from a single terminal interface. Let me show you how.

Building the Cosmic Guestbook App

To demonstrate this workflow, we need an app. Let's start from an empty directory and use our agent to "vibe code" a brand new project: the Cosmic Guestbook.

We want a full-stack architecture: a React frontend and a Node.js Express backend API. Instead of scaffolding this by hand, we can ask our agent to jumpstart the app:

Within moments, our agent scaffolds the backend/ directory with server.js and the frontend/ directory with a fully styled React app. We now have a functioning, two-tier web app sitting on our laptop.

Installing the Extension

But code on a laptop isn't shipping. To get this guestbook online, we need to equip our chosen environment with the CI/CD extension. Regardless of your setup, start by ensuring that you have the gcloud CLI installed and authenticate using Application Default Credentials: gcloud auth application-default login.

Now, install the extension in your preferred development environment:

For Gemini CLI

Run the following command directly in your terminal:

For Claude Code

Add the marketplace and install the plugin directly from the terminal:

For Antigravity and agents supported by npx skills

You can enable the extension's MCP Server as custom MCP and add skills to your workspace:

How It Works

The CI/CD extension is a powerful three-tier system designed to translate your intent into secure, production-ready infrastructure in all these agent environments:

1. Skills: Specialized AI skills like google-cicd-deploy and google-cicd-pipeline-design are defined in the extension. These instruct your AI agent (Gemini CLI, Claude Code, or Antigravity) on how to think—helping it analyze your code, ask the right questions, and handle errors gracefully.

2. CI/CD MCP server: Running in the background is a specialized Go-based Model Context Protocol (MCP) server. This server provides a suite of tools that gives your agent the hands it needs to actually manipulate Google Cloud: everything from scanning for secrets to provisioning Cloud Run services.

3. Local knowledge base: To ensure the most accurate answers, the system includes a pre-indexed retrieval-augmented generation (RAG) database containing verified architecture patterns, which lets the agent ground its design decisions in the source of truth.

Your chosen AI assistant orchestrates these tools and patterns into a cohesive deployment lifecycle.

The Inner Loop

When you're building a prototype or testing a new feature, you don't need a massive, multi-environment CI/CD pipeline. You just need a public URL to test your webhook or show a stakeholder. This is the inner loop, and it needs to be fast.

The traditional approach involves manually writing a Dockerfile, authenticating with a container registry, building the image, pushing it, and finally deploying it. The CI/CD extension turns this into a single natural language prompt: gemini "Deploy this application to Google Cloud using the google-cicd-deploy skill". If you're using Claude Code, you can prompt it exactly the same way via claude -p "Deploy this application...", and in Antigravity, simply type your deployment request.

When you run this prompt, your AI agent analyzes your local workspace to figure out the best deployment approach.

Step 1: Pre-Deployment Security Scan

Leaked secrets are one of the most common and expensive security failures in software. GitGuardian's 2025 State of Secrets Sprawl report found 23.8 million new credentials exposed on public GitHub in a single year; 70% of secrets that were leaked in 2022 are still active today. It happens fast: you hardcode a database password during local testing, forget to remove it, and push.

The extension catches this before it becomes a problem. Before any code leaves your machine, it runs a secret check across your workspace. If it finds a Stripe API key or a database credential sitting in your source, the agent halts the deployment and warns you. No secrets ship to the cloud by accident.

If you accidentally commit a database password or a Stripe API key while hacking on localhost, your assistant catches it and prevents the deployment. This is what true shift-left security looks like in practice.

Step 2: Application Analysis & Containerization

Next, your agent checks your package.json or go.mod to figure out your framework. It automatically decides whether to use Google Cloud Storage (for static sites) or Cloud Run (for dynamic services).

If you're building a dynamic service that doesn't have a Dockerfile, the extension leverages Google Cloud's buildpacks to containerize it for you on the fly.

Step 3: Clarification and Deployment

Conversational agents don't blindly guess how you want your app configured. Before making any changes to your Google Cloud environment, the assistant pauses the flow to ask prioritizing questions based on what it found during its analysis.

For our Cosmic Guestbook, I didn't specify a region or whether the service should be public. The assistant paused and asked me about it:

"I have completed the analysis and prepared the application for a unified deployment to Cloud Run. Since the Node.js buildpack requires a single entry point, I created a root package.json with a custom build script that builds the React frontend and allows the Express backend to serve it statically.

Additionally, the secret scan completed successfully, and no sensitive credentials were found.

Before we deploy using the Cloud Run source deployment option (buildpacks), I need to clarify a few deployment parameters:

1. Region/Location: The gcloud defaults do not specify a location. Which Google Cloud region would you like to deploy to (e.g., us-central1, europe-west1)?

2. Access: Should this application be publicly accessible or private?

3. Service Name: I propose naming the service cosmic-guestbook. Does that sound good to you?"

This conversational pause ensures that even in the fast inner loop, you retain complete control over your cloud architecture. After you confirm the details, the agent pushes the code live and returns the public URL:

Behind the scenes, the deployment is handled automatically via cloudrun.deploy_to_cloud_run_from_source.

The Outer Loop

A scrappy deployment prompt is perfect for a Tuesday afternoon prototype, but you can't run a production system from your laptop. Eventually, you need the rigors of the outer loop: automated testing, source control integration, and formal continuous deployment.

Writing cloudbuild.yaml files and provisioning the necessary infrastructure (like Artifact Registry repositories or GitHub connections through Developer Connect) is notoriously tedious and error-prone. With the google-cicd-pipeline-design skill, your AI agent acts as your personal platform engineering consultant.

Instead of writing YAML from scratch, you have a conversation. Your agent will ask you about your testing strategy and where you want to deploy, and then it autonomously provisions the required Google Cloud infrastructure.

Step 1: Architectural Design & Feedback

You start the process directly in your conversational interface:

Your assistant doesn't work in a black box. It retrieves common CI/CD patterns from its knowledge base. With the most relevant knowledge in hand, it proposes a concrete plan in YAML for you to review.

Step 2: Infrastructure Provisioning

After you approve the plan, the assistant works sequentially through the required infrastructure steps. For example, it might first create a registry for your containers.

It might then set up a Git connection so that Cloud Build can read your source code.

Step 3: Pipeline Generation & Trigger

Finally, the agent generates the actual cloudbuild.yaml file that defines the pipeline stages (test, build, deploy). Here's a snippet of a generated configuration from the repository that highlights the initial build steps:

With the pipeline defined, we need a way to execute it automatically. The agent finishes by creating a Cloud Build trigger. The trigger acts as the glue between your GitHub repository and Cloud Build, ensuring that every push to the main branch automatically fires off the cloudbuild.yaml steps.

Security And Control

AI-assisted infrastructure generation sounds incredible, but it's reasonable to ask: is it safe?

The extension operates strictly within the permissions of your local Application Default Credentials (ADC). It can't do anything that you can't do. Because it uses the Model Context Protocol (MCP), every action that it takes, from creating an Artifact Registry to modifying a Cloud Build trigger, runs through strongly typed, verifiable tools.

If you don't like a step in the proposed pipeline, you tell your agent to change it. You're always the "Editor-in-Chief" of your infrastructure. We strongly recommend that you adhere to the principle of least privilege for both your local ADC and any service accounts that are used by the generated pipelines.

When Dev and Ops Converge

The friction between wanting to write code and needing to ship it is finally dissolving. We're moving past the era where deep expertise in YAML formatting was a prerequisite for putting an app on the internet.

By handling the boilerplate of both the scrappy inner loop and the automated outer loop, conversational AI lets developers focus on the business logic that actually matters.

Next Steps

If you want to experience this convergence yourself, here are your immediate next steps:

1. Get the tools: Install the CI/CD Extension for Gemini CLI.

2. Deploy the inner loop: Take an existing side project (or ask your chosen agent to scaffold a new one like our Cosmic Guestbook) and prompt it to deploy to Google Cloud to instantly see it live on Cloud Run or Cloud Storage.

3. Automate the outer loop: Run a design command against a repository that you're ready to productionize, and watch your agent generate your cloudbuild.yaml and provision your infrastructure.

Stop wrestling with configuration files and start shipping. Let me know what you build by reaching out on LinkedIn, X, or Bluesky!