Continuous deployment automatically moves successful builds toward production. Continuous integration builds and tests frequently merged code; deployment follows only after the required checks pass. Automating this path reduces manual errors and the delay between completing code and releasing it. section 10.3.1
A dependable deployment path needs more than a pipeline:
- Keep a fixed, recurring release path and maintain the health and consistency of production and nonproduction environments. Application and infrastructure deployments both depend on rigorous releases and automated testing. section 6.3.3
- Treat every customer-facing platform environment as production from the platform team's perspective, even when application teams use it for preproduction testing. section 6.3.3
- Fetch secrets from a secrets manager as needed rather than duplicating them in pipeline environment values. This supports credential rotation and reduces the risk of human error. section 6.3.3
From commit to production
A service team commits a change. Its CI/CD pipeline runs unit tests, integration tests, and security scans, then deploys to staging. A successful build proceeds to production after the necessary checks. The team also owns deployment and maintenance, so fast feedback can lead directly to fixes. section 10.3.1
Figure 6.9 For users of the platform, an environment in the path-to-production is a Kubernetes namespace. There will be one or more namespaces in a preproduction cluster, or eventually multiple clusters, where development teams test their application before deploying to a production cluster. Something you may not have seen before is the preview environment in the similarly named preview cluster.
The environment diagram makes the application team's path to production concrete: Kubernetes namespaces provide places to test before deployment to a production cluster. section 6.3.3
Track whether automation improves outcomes, not just release frequency. A shift from periodic releases to continuous deployment shortened commit-to-release time in the organizational example. Alongside stronger monitoring and SRE practices, the broader delivery changes also improved reliability; those gains should not be attributed to deployment automation alone. section 10.7.2
