DevOps toolchain: from commit to running code
A DevOps toolchain is the chain of tools that carries a code change from a developer's laptop to production, checking it on the way and watching it afterwards. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and what to decide first.
Quick answer
A DevOps toolchain keeps code in source control, then a CI/CD pipeline builds, tests and scans every change and stores the result in a registry. Infrastructure as code creates identical environments, secrets stay in a vault, and monitoring and logs report on the live system, so problems return to developers quickly.
| Best for | Teams that release often and want every change tested, repeatable and easy to roll back |
|---|---|
| Less suited when | A one-person site changed twice a year, where a manual upload is simpler |
| Start with | One repository, one pipeline that builds and tests every change, and one automated deploy to a test environment |
| Main services on AWS | AWS Secrets Manager, AWS CloudFormation, Amazon CloudWatch, AWS CodeConnections, AWS CodePipeline + CodeBuild, Amazon ECR |
| Main services on Azure | Azure Key Vault, Bicep, Azure Monitor, Azure Repos, Azure Pipelines, Azure Container Registry |
| Main services on Google Cloud | Secret Manager, Infrastructure Manager, Cloud Monitoring, GitHub, GitLab or Bitbucket with Cloud Build, Cloud Build, Artifact Registry |
The idea in plain words
Without a toolchain, releasing means a person copies files, runs commands in the right order and hopes nothing is forgotten. That is slow and risky, so teams release rarely and in big batches, which makes each release riskier still.
A toolchain automates the path. Every change is saved in source control, built and tested by a pipeline, packaged into an artifact or container image, and deployed the same way each time. Environments are created from code instead of by hand, secrets are kept out of the code, and monitoring tells the team what happened after release.
The goal is not the tools but a quick, safe loop: small changes, fast feedback, easy rollback. Start with the smallest pipeline that gives that loop and grow it as the team grows.
The architecture
Boxes show the job each part does. Pick a cloud to see the service for each job.
Step by step
- Write and reviewA developer works on a short-lived branch and opens a pull request. A teammate reviews it, and automatic checks run before it can be merged into the main branch.
- Every merge triggers a buildThe pipeline starts by itself, fetches the code, builds it and runs the fast tests. A red result stops the change and tells the author within minutes.
- Scan for problemsThe pipeline checks code style, known weaknesses in the libraries you use, secrets committed by mistake and, for containers, vulnerabilities in the image.
- Package onceThe build produces one artifact or container image with a version number and stores it in a registry. The same package moves through every environment, so what you tested is what you ship.
- Deploy by pipelineThe pipeline deploys to a test environment, runs deeper checks and then deploys to production, with an approval where your rules require one. Release gradually, to a few users first, where you can.
- Environments come from codeInfrastructure as code files create and update networks, servers and services, so test and production match, and a lost environment can be rebuilt in minutes.
- Watch and learnMonitoring, logs and traces show errors and speed after each release. Alerts reach the team, and what they learn goes into the next change, with a quick rollback when needed.
Services side by side
The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| Store secrets (passwords, API keys) |
|
|
|
| Infrastructure as code |
|
|
|
| Monitoring, metrics and alerts |
|
|
|
| Source code hosting (Git) |
|
|
|
| CI/CD pipelines |
|
|
|
| Container image registry |
|
|
|
| Central logs and log analyticsOptional |
|
|
|
Many teams mix tools here, for example GitHub for code and pipelines that deploy to any cloud. The table shows each cloud's own services, and your choice does not have to match the cloud you host on.
Common variations
- Apps packaged as containers. Build images in the pipeline, scan and sign them, push them to a registry and deploy them to a managed container platform. See the microservices pattern.
- You want Git to be the single source of truth. Adopt GitOps: describe the desired state of the system in Git, and let an agent in the cluster apply it and report when reality drifts.
- Many teams on one platform. Offer a shared, supported set of templates, a golden path, so teams reuse the same safe pipeline instead of building their own.
- Strict change control. Add required approvals, separation of duties and an automatic record of who changed what and when, which the pipeline can keep for you.
Hosted pipeline service or a tool you run yourself?
Each cloud offers a pipeline service, and popular platforms such as GitHub and GitLab bring their own. The alternative is to host an open-source automation server yourself.
Hosted pipeline service
Good
- Nothing to install, patch or scale
- Quick to start with ready-made steps
- Links well to the cloud's identity and deploy targets
Watch out
- Pricing by build minutes can add up
- Limits on build size and runner types
- Pipelines written for one service need rework to move
Self-hosted automation server
Good
- Full control of runners, plugins and data
- Runs inside your own network
- No per-minute fee
Watch out
- You patch, secure and scale it
- Plugins need constant care
- An outage stops every release
Keep in mind
- Small, frequent changes. Teams that release small changes often find and fix problems faster than teams that release rarely. Measure how often you deploy, how long a change takes to reach production, how often a release fails and how fast you recover. These four measures come from the DORA research programme, not the EU regulation of the same name.
- Protect the pipeline. Whoever controls the pipeline controls production. Limit who can change it, give it only the permissions it needs, use short-lived credentials instead of stored keys and keep build runners clean and disposable.
- Secrets never go in code. Keep passwords and keys in a secrets vault, scan for leaks on every commit and rotate anything that was exposed. Once a secret is in Git history, treat it as public.
- Supply chain risk. Packages and base images you pull in can be tampered with. Pin versions, use a private registry, scan dependencies, sign what you build and keep a list of what is in each release.
- Tests you trust. A pipeline is only as good as its tests. Keep tests fast and reliable, fix or remove flaky ones quickly, and do not let people bypass failing checks.
- Rollback and recovery. Plan how to undo a release in minutes: keep the previous package, use gradual releases or feature flags, and make database changes that work with both old and new code.
- Cost. Build minutes, artifact storage and always-on runners add up. Clean old images, cache dependencies, stop idle runners and review usage every month.
Words used on this page
Services in this pattern that have changed
Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.
- Google Cloud Shut down Google Container Registry was shut down on 18 March 2025. Use Artifact Registry. Details
- AWS Shut down AWS Proton reached end of support on 7 October 2026 and its console and resources are no longer accessible; infrastructure it already deployed keeps running. AWS suggests CloudFormation Git sync as the replacement. Details
- Google Cloud Shut down Google Cloud Deployment Manager support ended on 31 March 2026. Existing resources keep working but can no longer be managed with it. Google points to Infrastructure Manager (or Terraform) instead. Details
Sources and further reading
Check details such as features, limits, prices and regions in the providers' own documentation.
- AWS documentation (opens in a new tab)
- Microsoft Azure documentation (opens in a new tab)
- Google Cloud documentation (opens in a new tab)
Announcements about the changed services above
Frequently asked questions
What is a DevOps toolchain?
A DevOps toolchain is the set of connected tools that moves a code change from writing to running in production: source control, a CI/CD pipeline, an artifact registry, infrastructure as code, secrets storage and monitoring. Together they make releases frequent, repeatable and safe.
What is the difference between CI and CD?
Continuous integration builds and tests every change as soon as it is merged. Continuous delivery keeps each change ready to release, and continuous deployment goes further by releasing it to production automatically once the checks pass.
What is infrastructure as code?
Infrastructure as code describes servers, networks and services in text files that tools read to create and update them. The files live in source control and are reviewed like code, which makes environments repeatable, so test and production match.
Should I use my cloud provider's pipeline service or GitHub or GitLab?
Any of them can work. Choose the one your team already uses for code, check that it can deploy safely to your cloud with short-lived credentials, and compare cost at your build volume. Keep pipeline logic in scripts so switching later stays easy.
What is GitOps?
GitOps keeps the desired state of your systems in a Git repository. An agent compares that state with what is running and applies changes or reports drift. Every change is a reviewed commit, which gives you history, approval and easy rollback.
Want this reviewed for your case?
CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.
Building something else?
Describe it in plain words and get matching services on all three clouds.
Service suggester → Cloud consulting →