Analyzing and optimizing technical and business processes · Topic 1 of 4
SDLC, CI/CD and Testing
The software lifecycle on Google Cloud: CI/CD with Cloud Build, Artifact Registry and Cloud Deploy, testing levels and safe schema changes for releases.
- 4 min
- Includes a diagram
- Cloud Build builds and tests; Artifact Registry stores; Cloud Deploy promotes with approvals and rollback.
- Build once, promote the same digest.
- Unit tests every commit; integration and load tests at the right stage; fast critical subsets on every change.
What it is
The software development lifecycle (SDLC) is the path from an idea to running, maintained software. Continuous integration builds and tests every change; continuous deployment releases tested changes automatically or with approval. Architects design the process so releases are fast, safe and auditable.
How it works
The CI/CD toolchain on Google Cloud
| Stage | Tool |
|---|---|
| Source | Git repositories (GitHub, GitLab, Bitbucket, or Secure Source Manager) |
| Build and test | Cloud Build triggers on pushes and pull requests |
| Store artifacts | Artifact Registry (images, language packages) |
| Deliver | Cloud Deploy pipelines with targets, approvals, canary strategies and rollback, for GKE and Cloud Run |
| Infrastructure | Terraform through Infrastructure Manager or the pipeline |
| Policy | Binary Authorization, Policy Controller |
Release principles
- Build once, deploy many: the image tested in staging is the image promoted to production, referenced by digest.
- Small, frequent changes are easier to test and roll back than large releases.
- Automated gates (tests, scans, SLO checks) replace manual checks where possible; keep a human approval only where the business requires it.
- Every promotion recorded: Cloud Deploy and audit logs show who promoted what.
Testing and validation
| Test type | Validates | When |
|---|---|---|
| Unit | Single functions or classes | Every commit |
| Integration | Components together, with real or emulated services | Every merge or nightly |
| End-to-end | User journeys | Before release |
| Load and performance | Behaviour at expected and peak traffic | Before major launches |
| Infrastructure tests | Terraform plans, policy checks, configuration validation | Before applying infrastructure changes |
| Safety-critical subsets | The scenarios that matter most | On every pull request when the full suite is too slow |
When a full test suite takes hours, run a fast, high-value subset on every change and the full suite on a schedule. That catches the important regressions before merge without slowing every change.
Cloud emulators for Pub/Sub, Spanner, Bigtable and Firestore let integration tests run without touching real cloud resources.
Database changes without downtime
Rolling updates run old and new versions side by side. Use the expand and contract pattern: add the new column, deploy code that writes both, backfill, switch reads, and drop the old column in a later release. Renaming a column in one step breaks the old version during the rollout.
SDLC improvements architects advise
| Problem | Process change |
|---|---|
| Production differs from what was tested | Build once and promote the digest |
| Untested changes reach users | Required checks and staged environments |
| Slow developer feedback | Cloud Code with Skaffold continuous development against a dev cluster |
| Releases ignore reliability | Error budget policies tied to SLOs |
| Manual environment builds drift | Infrastructure as code from Git |
How the exam asks about this
- "Releases must pass staging, need approval for production, shift traffic gradually and roll back fast." Cloud Deploy with a canary strategy and approval.
- "Production image differed from staging because a dependency changed between builds." Build once in Cloud Build, store in Artifact Registry, promote the digest.
- "Rename a column with a 99.9% target and rolling updates." Expand and contract.
What to remember for the exam
- Cloud Build builds and tests; Artifact Registry stores; Cloud Deploy promotes with approvals and rollback.
- Build once, promote the same digest.
- Unit tests every commit; integration and load tests at the right stage; fast critical subsets on every change.
- Expand and contract for schema changes during rolling updates.
- Automate gates; keep manual approval only where required.
Tagging images as "latest" and pulling the newest tag in each environment means staging and production can run different code.
Common mistakes
Rebuilding per environment. The artifact is no longer the one tested.
Running hour-long suites on every pull request. Developers wait and bypass them.
Single-step destructive schema changes during rolling updates.
Check yourself
Which Google Cloud service promotes releases between targets with approvals and canary strategies?
Cloud Deploy.
How do you guarantee production runs exactly the image tested in staging?
Build once and promote the same image digest.
What pattern renames a column safely while old and new code run together?
Expand and contract: add, write both, backfill, switch, then drop later.
Topic 1 of 4 in Analyzing and optimizing technical and business processes
Test yourself on Analyzing and optimizing technical and business processes
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.