GCP Artifact Promotion Pipeline
Date Posted: 2026-05-16
Project Overview
This project establishes an automated container image promotion mechanism within isolated Google Cloud Platform (GCP) environments using Azure Pipelines and GCP Cloud Build, reducing redundant builds and improving artifact consistency.
The Challenge
Our organization utilizes GCP to host applications across two distinct, air-gapped environments: Non-Prod (containing Dev and Test projects) and Prod (containing Stage and Prod projects).
Because the Non-Prod and Prod environments are completely isolated from one another, a single image cannot be promoted across the entire lifecycle. Previously, however, the deployment workflow required applications to be recompiled and rebuilt from scratch for every single sub-environment (Dev, Test, Stage, and Prod). This process introduced two major issues:
- Redundancy: Significant time and compute resources were wasted running four separate build processes for a single deployment cycle.
- Risk of Configuration Drift: Rebuilding artifacts between Dev and Test, or Stage and Prod, meant there was no guarantee that the identical code verified in the lower environment was what landed in the next.
The goal was to optimize this workflow by creating a promotion mechanism within the boundaries of each air-gapped environment.
Technical Implementation
To solve this, I developed an Azure DevOps pipeline that interacts with GCP Cloud Build. The application is compiled and built twice per lifecycle: once at the Dev phase and once at the Stage phase.
To eliminate the remaining redundant builds, the pipeline targets the verified source image based on its tag, downloads it securely, and writes it directly to the Artifact Registry of the target environment (promoting from Dev to Test, or Stage to Prod). This ensures that the exact same artifact tested in Dev is what runs in Test, and what is tested in Stage is what runs in Prod.
Overcoming Infrastructure Constraints
During implementation, I encountered a rigid governance constraint: our team relies on centralized, templated Azure Pipeline YAML files that cannot be modified at the project level. Because of this restriction, I could not introduce standard pipeline runtime parameters to capture user inputs, resulting in template schema errors.
To work around this limitation without violating governance policies, I utilized Azure DevOps Variable Groups within the Pipeline Library as the configuration layer.
Instead of passing parameters directly into the YAML template, the person deploying the application updates a dedicated Variable Group with the required runtime details:
- Application name to promote
- Source image tag
- Source artifact repository
- Target artifact repository
The pipeline dynamically reads these values from the library at runtime, successfully bypassing the template restriction while keeping the deployment process flexible and user-driven.
Results and Impact
- Improved Artifact Consistency: Guaranteed that the exact container image verified in Dev is promoted to Test, and Stage is promoted to Prod, isolating and reducing the risk of environment-specific rebuild bugs.
- Process Efficiency: Optimized the deployment lifecycle by cutting the required build and compilation steps in half (from four builds down to two).
- Policy Compliance: Delivered a practical automation solution within the strict boundaries of corporate YAML templates and air-gapped network architecture.