DevOps: Continuous Integration and Delivery

Continuous Integration is a software development practice where developers frequently merge their code changes into a shared repository, often multiple times per day. Each merge triggers an automated build and test process to detect integration errors as early as possible. The goal is to catch bugs quickly and reduce the cost of fixing them. In Google Cloud, the primary CI service is Cloud Build, which executes build steps defined in a cloudbuild.yaml file.

Continuous Delivery extends CI by automatically deploying all code changes to a testing/staging environment after the build and test stage. The key is that the deployment is automated, but the release to production is a manual decision (a 'go/no-go' gate). Continuous Deployment goes further: every change that passes all stages is automatically released to production. The GCDL exam expects you to distinguish between these two. Google Cloud's CD tools include Cloud Deploy (for delivery pipelines) and Deployment Manager (for infrastructure deployment).

In a cloud environment, infrastructure is programmable (Infrastructure as Code, IaC). CI/CD pipelines can manage not just application code but also infrastructure changes. This is called GitOps: using Git as the single source of truth for both code and configuration. On Google Cloud, you can use Cloud Build with Terraform or Deployment Manager to apply infrastructure changes automatically. The exam tests the understanding that CI/CD reduces risk, increases release frequency, and improves team velocity.

Cloud Build is a managed CI/CD platform that runs builds on Google Cloud's infrastructure. You define build steps in a YAML or JSON configuration file. Each step runs in a Docker container. Steps can compile code, run tests, produce artifacts, and deploy. Key components:

Example cloudbuild.yaml for a Python app:

steps:
- name: 'python:3.9'
  entrypoint: pip
  args: ['install', '-r', 'requirements.txt', '--user']
- name: 'python:3.9'
  entrypoint: python
  args: ['-m', 'pytest', 'tests/']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image:$SHORT_SHA', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image:$SHORT_SHA']
images:
- 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image:$SHORT_SHA'

Cloud Deploy is a managed delivery service that automates the promotion of application releases across a series of targets (environments). It uses a delivery pipeline defined in a YAML file. Key concepts:

Example delivery pipeline:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-pipeline
serialPipeline:
  stages:
  - targetId: dev
  - targetId: staging
    strategy:
      canary:
        canaryDeployment:
          percentages: [25, 50, 75]
          verify: true
  - targetId: prod
    strategy:
      canary:
        canaryDeployment:
          percentages: [10, 20, 70]
          verify: true

CI/CD pipelines can also manage infrastructure. On Google Cloud, you can use Deployment Manager (Google's native IaC) or Terraform (third-party). The pipeline applies changes to infrastructure declaratively. This ensures that infrastructure is versioned, testable, and repeatable. The exam expects you to know that IaC is a prerequisite for effective CI/CD in cloud environments.

The GCDL exam expects you to understand these benefits and be able to identify the correct Google Cloud service for a given scenario.

An online retailer uses a microservices architecture on GKE. Each service has its own CI/CD pipeline. Developers push to feature branches, which trigger Cloud Build to run unit tests and build a Docker image. On merge to main, a build trigger deploys to a dev GKE namespace using Cloud Deploy. After automated integration tests pass, a manual approval promotes the release to staging, where performance tests run. Finally, a canary deployment to production rolls out to 10% of users, then 50%, then 100% with automatic rollback if error rates spike. This setup reduces deployment time from hours to minutes and catches issues before full rollout. Misconfiguration example: forgetting to set the verify step in the canary strategy, causing a bad release to reach 100% before detection.

A bank uses Cloud Build to compile Java applications, run static code analysis (SonarQube), and package into JARs. Artifacts are stored in Artifact Registry with vulnerability scanning enabled. For regulatory compliance, every deployment must be audited. Cloud Deploy's delivery pipeline includes approval gates at each environment (dev, QA, staging, prod). All approvals are logged in Cloud Audit Logs. The pipeline also runs integration tests against a test database spun up in Cloud SQL. Common issue: the Cloud Build service account lacks permissions to access Cloud SQL, causing test failures. Solution: grant the Cloud Build service account the cloudsql.client role.

A startup uses Cloud Run for a serverless application. They use a push-to-deploy pipeline: every commit to main triggers Cloud Build, which runs tests, builds a container, pushes to Artifact Registry, and deploys to Cloud Run using gcloud run deploy. To minimize downtime, they use Cloud Run's traffic splitting: the new revision receives 0% traffic initially; after smoke tests, a Cloud Build step updates traffic to 100%. They also use Cloud Deploy for a canary rollout to gradually shift traffic. Performance consideration: Cloud Build's default machine type may be too slow for large builds; they switch to E2_HIGHCPU_8 to reduce build time. Misconfiguration: not setting --no-traffic on the initial deploy, causing the new revision to immediately receive 100% traffic before tests.