I'm facing a challenge with managing Terraform updates across different environments, specifically how to enable developers to update lower environments while keeping production secure. Right now, we have separate directories for each environment within our repository—like `production`, `dev`, and others. Terraform configurations are stored in GitHub, and I have set up GitHub Actions to automatically run a Terraform plan when a Pull Request is made that affects the Terraform code. PRs require approvals before they're merged, and once merged, GitHub Actions will perform a Terraform apply.
The thing is, when developers want to make minor updates, such as adding new environment variables, they still have to go through the whole PR approval process, which feels unnecessary. I'm trying to find a way to let them commit directly to lower environment directories while still requiring reviews for production changes.
I've considered moving Terraform code to a separate repository, using a CODEOWNERS file to manage approvals for production, and applying branch rules that require PRs but allow for certain exceptions. While this seems to work in theory, I'm not entirely convinced it's the best approach for my company's needs, especially since our lower environments are long-lived and configured differently due to integration with external partners. I'm looking for suggestions on how to streamline this process without major redesigns.
4 Answers
Check out solutions like Atlantis or Digger. They facilitate changes and approvals right at the PR merge without additional steps. Also, make sure to use modules consistently. This lets you maintain environment specifics while keeping the overall structure similar.
One way to handle this is to allow developers to deploy their own branches to lower environments without PR approvals, while keeping main branches protected. This way, they can test changes freely. For cleanup, you could destroy the environment or apply the production branch if needed.
Consider letting developers push from their local machines to staging directly for testing. Alternatively, automate the push to staging as part of your CI process, while keeping PRs for production changes. Given the long-lived nature of your environments, requiring PRs for staging changes seems reasonable. You might also think about creating a separate 'dev' environment for testing.
You might want to explore ephemeral environment patterns. Giving developers tools to create temporary environments can greatly speed up their work and allow for parallel development without the PR bottleneck. It also makes testing out third-party integrations easier.
Related Questions
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically
[Centos] Delete All Files And Folders That Contain a String