How do you update multiple module versions and apply them all at once?

[marijakstrazdas]

A customer asked:

How do you update multiple module versions and apply them all at once? For example, there’s a module deployed in 10 different accounts that you’d like to update. How do you (a) modify the version number in all 10 terragrunt.hcl files, and (b) apply the updates to all files in a single Pull Request / CI job?

[zackproser]

Gruntwork Pipelines simplifies the deployment model when managing architectures deployed across multiple AWS accounts. Gruntwork Pipelines comes configured out of the box with each new Gruntwork Reference Architecture deployment.

When you push a feature branch with changes to the dev environment and open a Pull Request, for example, a terragrunt plan is generated for you to review while Pipelines implements a hold for manual approval. You can review and discuss the pull request with your team.

Once the pull request with the changes is merged, Gruntwork Pipelines will run a terragrunt apply to deploy your infrastructure changes.

Note that when you wish to update multiple accounts, we recommend leveraging the DeployOrder attribute for your accounts. See the documentation for DeployOrder here..

DeployOrder allows you to specify which account's changes should be done first when handling multiple account updates. For example, you may wish to have your internal dev and sandbox accounts deployed first as canaries - so that any unexpected fallout is constrained to your internal environments. You might then promote your release candidate to staging and finally to prod, assuming all acceptance tests pass.

For example, suppose you have the following folder structure:

.
├── accounts.json
├── _envcommon
│   └── services
│       └── my-app.hcl
├── dev
│   └── us-east-1
│       └── dev
│           └── services
│               └── my-app
│                   └── terragrunt.hcl
│
├── stage
│   └── us-east-1
│       └── stage
│           └── services
│               └── my-app
│                   └── terragrunt.hcl
└── prod
    └── us-east-1
        └── prod
            └── services
                └── my-app
                    └── terragrunt.hcl

And suppose you had the following in your accounts.json file:

{
  "logs": {
    "deploy_order": 5,
    "id": "111111111111",
    "root_user_email": ""
  },
  "security": {
    "deploy_order": 5,
    "id": "222222222222",
    "root_user_email": ""
  },
  "shared": {
    "deploy_order": 4,
    "id": "333333333333",
    "root_user_email": ""
  },
  "dev": {
    "deploy_order": 1,
    "id": "444444444444",
    "root_user_email": ""
  },
  "stage": {
    "deploy_order": 2,
    "id": "555555555555",
    "root_user_email": ""
  },
  "prod": {
    "deploy_order": 3,
    "id": "666666666666",
    "root_user_email": ""
  }
}

If you make a change in _envcommon/services/my-app.hcl, then the Infrastructure CI/CD pipeline will proceed to run plan and apply in the deploy order specified in the accounts.json file. For the example, this means that the pipeline will run plan and apply on dev first, then stage, and then finally prod. If anything fails in between, then the pipeline will halt at that point. That is, if there is an error trying to deploy to dev, then the pipeline will halt without moving to stage or prod.

Using Gruntwork Pipelines and its DeployOrder functionality, you can orchestrate complex multi-account deployments in a sane way that leverages familiar pull request workflows your team is already comfortable with.

[zackproser]

credit for this solution goes to @rhoboat