search

antonbabenko / terragrunt-reference-architecture

Terragrunt Reference Architecture (upd: May 2020)
MIT License
375 stars 104 forks source link

Reference Workflow #7

Closed jwenz723 closed 3 years ago

jwenz723 commented 3 years ago

Do you have any suggestions for what a work flow would look like for the developers interacting with a repository following the same structure as this repository?

Things that would be interesting to understand your opinion on:

  1. What would an automated pipeline look like for this repository?
  2. Would a PR be able to sufficiently serve as the 'manual approval's step for each PR made to this infrastructure?
  3. What steps would be necessary to deploy a change to one of the base modules to all of the environments (how many PRs, how would you validate the change as it is deployed to each environment)?
antonbabenko commented 3 years ago

This is a rather broad topic depending on many factors.

In simple terms and in general, I recommend splitting modules away from this repository and have them in their own pipeline.

Once a new module version is released, this repository is updated with PR to acme-staging, which is deployed to staging after merge.

GitHub's PR is not a replacement to manual approval's, but Atlantis and other forms of GitOps can act as approval step in your pipeline.

I highly recommend reading http://infrastructure-as-code.com/ and Kief's books where he covers these topics in much more details.