Path to Production

Three seperate git repos for dev, stg & prd

Published: Saturday, May 21, 2022 Last modified: Monday, Dec 5, 2022

Service teams would get vended a set of accounts (e.g: dev, stg, prd) that contain it-security guardrails (e.g. predefined roles that can be assumed) or other resources that are commonly used within the organization. An example of this could be integration with CI/CD. Service teams would use the accounts (dev, stg, prd) to develop software, typically with a different IaC solution (e.g terraform or cdk). These tools offer better ergonomics for application development. - Olaf Conijn

Assuming three accounts {dev,stg,prd} accounts, how does a cross functional service team deploy to production in a rigorous manner?

  1. Develop and commit to dev
  2. Cut a dev commit to staging
  3. Promote a tested staging commit to production
  4. Rollback when needed

The simplest way to do it

Path to Production

Each {dev,stg,prd} account has an AWS Code{Commit,Build,Pipeline} that triggers a build/deployment pipeline once code has been pushed to it.

The workflow is simple:

  1. git commit and git push # dev is default
  2. git push stg # cut a dev commit to staging account
  3. git push prd # promote the tested stg commit to production

Need to rollback? With git push $env $prev_commit, you effectively practice gitops since deployments map to your git code state.

Pros:

Cons:

Using Github

Workflows are great, but to effectively deploy to your {dev,stg,prd} environments, Github needs to be externally trusted.

Pros:

Cons:

Github’s access can be limited to say the Container Registry, i.e. builds instead of deployment, nonetheless there is a supply chain issue.

Using some CI/CD tool in a dedicated account in your AWS Organisation

Also described as a One stack definition managed with a pipeline, however the problem is that “the pipeline” is often centralised unlike “The simplest way to do it” above, where the pipeline is minimal, native to each AWS account and driven exclusively via git push.

Pros:

Cons:

Summary

The top heavy, high maintenance, complex, centralised CI/CD pipelines in organisations is in stark contrast to the proposed AWS managed CI/CD aka AWS Code* in each {dev,stg,prd} account.

Other managed CI/CD management options like Github are considered, but that requires strong external trust and integration.

AWS supplies a decentralised, fault tolerant, auditable path to production coordinated by git pushes with Code*.

This path stresses reproducible builds and uses a git repository’s commit hash as the source of truth. Furthermore it empowers the service team since they can take responsibility for their Continuous Integration build rules and deployment. That said, production deployment approval and further guard rails can be introduced with a self service pattern.