What the Build phase is, and what it is not
Build is where the approved plan becomes running code. Our engineers write Terraform modules, pipeline definitions, Kubernetes and Helm configuration and monitoring dashboards, and they ship it through the same review process your own developers use.
It is not a black box. A common failure of outsourced DevOps is a long silence followed by a handover of something nobody understands. Our approach is the opposite: small pull requests, in your repositories, reviewed as they land, with documentation written as we go. If you stopped working with us on any given Friday, you would hold working, understandable code.
Why implementation fails without discipline
Infrastructure changes are risky in ways application changes are not. A bad merge can delete a database, open a port or break every deploy. Typical failure modes we design against:
- Large, unreviewable changes: a 4,000-line diff gets rubber-stamped, not reviewed.
- Environment drift: staging and production diverge, so a tested change behaves differently live.
- Hidden state: a manual console tweak that the code does not know about.
- Missing documentation: the only person who understands a module is its author.
- Scope creep: the plan quietly changes and nobody approves it.
Each of these is addressed by a working practice, not a promise.
How we work day to day
Everything is a pull request
All changes reach your environment through version control. A pull request for infrastructure should let a reviewer answer three questions quickly: what changes, what could go wrong, how do we undo it. We use a checklist for this:
| Check | What the reviewer should see |
|---|---|
| Scope | One purpose per pull request, matching a plan deliverable |
| Plan output | terraform plan attached, with no unexpected destroys |
| Tests | Linting, validation and policy checks passing in CI |
| Risk note | Blast radius, affected environments, who to inform |
| Rollback | A concrete step, such as reverting the commit and re-applying |
| Documentation | README, variable descriptions or runbook updated in the same change |
| Secrets | None in code; references to a secret manager only |
Terraform modules that others can read
We write modules with a narrow interface, typed variables and descriptions, and outputs that are actually used. A minimal example of the style:
variable "name" {
type = string
description = "Name prefix applied to all resources in this module."
}
variable "retention_days" {
type = number
description = "Days to keep log data before expiry."
default = 30
validation {
condition = var.retention_days >= 1
error_message = "retention_days must be at least 1."
}
}
resource "aws_cloudwatch_log_group" "this" {
name = "/app/${var.name}"
retention_in_days = var.retention_days
}
Validation blocks, pinned provider versions and a remote state backend with locking are standard. For the wider approach to state, environments and modules, see our Terraform infrastructure as code service.
Pipelines as code
We implement CI/CD in whichever system you already use, whether GitHub Actions, GitLab CI or Azure DevOps, rather than forcing a migration for its own sake. Pipelines build once, promote the same artefact through environments, scan for known issues, and gate production on the approvals you choose. See CI/CD pipeline best practices for the principles we apply, and the CI/CD service page for the engagement.
Monitoring and dashboards built with the platform
Observability is built alongside the thing it observes, not after an outage. Dashboards and alert rules are stored as code, reviewed like anything else, and tied to service level objectives where you have them. Our monitoring with Grafana and Prometheus service covers this in depth.
Decisions and trade-offs during the build
Not every decision can be made in planning. During the build we surface these promptly:
- Module granularity: many small modules are flexible but harder to navigate. We pick the level that matches your team size.
- Speed against safety: a faster merge process is possible, but for production infrastructure we recommend required reviews even when it slows delivery.
- Reuse against fit: a community module may save time but import opinions you do not want. We say which we chose and why.
- Pace of migration: if production behaviour under load surprises us, we slow down rather than hit a date.
When we disagree with part of the plan after seeing the reality, we say so in a change note, not in a surprise pull request.
What the client receives
By the end of the Build phase you hold:
- Merged, reviewed code in your repositories: modules, pipelines, manifests, dashboards, alert rules.
- Documentation in the repository: architecture notes, module READMEs, how to deploy, how to roll back.
- Working environments that match the plan’s acceptance criteria.
- Initial runbooks for the components we built, ready to be refined in the Operate phase.
- A short demo or walkthrough for each major component.
What we need from you
- Repository, cloud and pipeline access appropriate to the scope, under named identities.
- Reviewers: at least one engineer who will approve changes and ask hard questions.
- Timely decisions when we raise a change note or an unexpected finding.
- Access to people who know the legacy behaviour of systems being migrated.
How to verify the quality of the build
You do not need to trust us. You can check:
- Pull request history: small, readable, reviewed by someone from your side.
- Reproducibility: can a new environment be created from code alone, and does a plan show no drift afterwards?
- Rollback tested: has someone actually reverted a change in a non-production environment?
- Documentation test: can an engineer who did not write a module deploy it using only the README?
- Acceptance criteria: is each plan deliverable demonstrably complete?
When this phase may look different
If your team is capable and only needs specialist help, we can pair with them or build only the hard parts, such as the cluster foundation or a migration. If the gap is mostly knowledge, review and mentoring may serve you better than implementation. Our engagement models describe the options, and you can get in touch to discuss which fits.