Infrastructure Pipeline
The workflow sketches the end-to-end Infra build and deployment pipeline, including quality gates(detectors & risks).
Branching: As a developer, it is recommended to have a local branch, which is essentially a copy of the mainline branch. This local branch should be used for making isolated changes and should be short-lived. While the local branch has no constraints, the developer is responsible for ensuring that the branch is always synced with the mainline to avoid merge conflicts.
The mainline branch, or the trunk, is used to assemble and build deployable artifacts. Every merge in the mainline has the potential to be released to any given environment. Therefore, it is vital to keep the mainline deployable. In other words, we must ensure that the merge has no issues. To achieve this, appropriate quality gates must be built to keep the mainline continuously deployable 🔒. The mainline remains locked until we assess the risk of the change.
Modules — Infrastructure is coded in Terraform modules; modules are designed based on blast radius and applicability; it is essentially to understand the scope of the modules; the scope helps define policies.
Infra Config Management — For successful zero-touch deployments, appropriate configurations must be supplied to the deployment framework; a central configuration management system can store configurations.
Risk Meter — A risk meter would help assess the risk we carry if the specific version of the module is deployed; this would help us determine additional actions beyond certain risks. With evolving CI/CD, lean releases translate to lower risk. It determines if a standard set for quality is met; if yes, we move to the next deployment phase; if not, appropriate feedback is delivered back to the team on the expectations and gaps to be closed.
Detectors — A Detector performs analysis, gathers details of changes, and maps the analysis independently for the change set. Every detector carries a weight.
Approve Plan — The objective of this gate is to generate a doc suggesting what change set is getting applied; the artifact produced by this gate needs to be carefully reviewed. This can be auto-reviewed depending on the risks meter in some environments, whereas we would need a more careful eye in others.
Deploy — Deploy of infra would work against a planned artifact generated in the “plan phase”; the plan would have versions similar to builds.
Meanwhile, Deploy would also validate( which is intrinsic to IaC tools ) the creation of infra; for example, if an S3 bucket needs creation, Terraform would validate if an S3 bucket is created.
Monitoring tools can be queried to inspect the health of applications.
Release Manifests — While each merge to mainline can be released to a different set of env, we assemble a list of modules that changed in a manifest to deployed together; this would benefit us from integration with pipeline solutions.
Early feedback & velocity of reporting back failures are vital — risk meter returns failed assessment and logs metrics and keep mainline locked till issues are resolved.
The infrastructure pipeline is an essential aspect of any software development process. The use of quality gates, risk assessment, and detectors helps to identify issues before they become problems, while the use of monitoring tools and release manifests ensures that the infrastructure is running smoothly. Ultimately, by following these guidelines, developers can ensure that their infrastructure is robust and meets the needs of their organization.
