When managing dozens of microservices, letting each repository define its own CI/CD pipeline script is a recipe for drift. If a security scanning step needs to be added, someone has to update 30 different files. Instead, platform teams design a Golden Pipeline—a standardized pipeline template that all services reuse.

Using Bitbucket Pipelines along with Helm charts for deployment allows us to define standard compilation, container building, and GKE deployment blocks.

1. Structure of the Golden Pipeline

A robust deployment pipeline is structured into three main phases:

1. Build & Test: Compile Go code, execute unit tests, and perform static analysis.
2. Package: Build the Docker container, run security vulnerability scans (e.g., Trivy), and push to Google Container Registry (GCR).
3. Deploy: Update the target GKE cluster using Helm, pointing to the newly built container tag.

2. Standard Helm Deployment Command

To keep configurations dry, we reuse a generic base Helm chart across all services. The pipeline overrides values dynamically for each specific microservice:

helm upgrade --install $SERVICE_NAME ./helm/charts/microservice   --namespace $KUBE_NAMESPACE   --set image.repository=$GCR_REPO/$SERVICE_NAME   --set image.tag=$BITBUCKET_COMMIT   --set env.DATABASE_URL=$DB_CONNECTION_STRING   --values ./environments/$ENV_NAME/values.yaml

This standardized approach ensures that all services follow the same build, security, and deployment stages, reducing infrastructure discrepancies.

Reusable Helm Library Charts & Workload Identity on Google Kubernetes Engine (GKE)

Standardize readiness probes, HorizontalPodAutoscalers, PodDisruptionBudgets, and GCP Workload Identity bindings across dozens of microservices via a single versioned Helm template.