guides/automations/how-to-configure-a-production-grade-ci-cd-setup-for-apps-and-infrastructure-code/

[utterances-bot]

How to configure a production-grade CI/CD workflow for infrastructure code

Learn about CI/CD workflows for Terraform and Terragrunt, including the differences between application code, different CI servers, threat models, and more.

https://gruntwork.io/guides/automations/how-to-configure-a-production-grade-ci-cd-setup-for-apps-and-infrastructure-code/

[ThomasGHenry]

The warning that many of the links throughout this are deliberately dead should be more prominent. After investing time in learning your way of doing things and then finding that all of your tooling links 404 on purpose for non-customers doesn't inspire me to subscribe. Instead, I feel tricked, like my time has been wasted by people that are at best careless or at worst not trustworthy.

[josh-padnick]

@ThomasGHenry Thank you for this very helpful feedback. Our thinking was that even if you're not a subscriber, the first sections of the guides are generally useful without any dependency on Gruntwork. That being said, we certainly don't want anyone to feel tricked. We'll discuss options internally for making sure users know what to expect.

It sounds like you'd prefer a notice at the top clearly stating that some links starting in the deployment section are for subscribers only, and perhaps labeling those links with a special icon?

'cc @tsmit291 Can you make a story for this issue so we can discuss how to tackle it later on?

[ThomasGHenry]

Thanks for the quick response and taking my expressed annoyance as useful feedback.

It's actually not as bad as I thought. After a few 404s on various links (which I still think is a weird/sloppy way to handle public doc intentionally) and then finding this message, I thought more of the ecosystem was locked down than it really is.

I see now that terragrunt is still public, and that redeems a lot the investment in reading about this way of working.

My annoyance level has been downgraded from "very annoyed" to "very slightly annoyed".

Good luck!

[trallnag]

Just wondering, why are different live environments in the same repository? Doesn't this make different implementing different policies for CI/CD pretty difficult to realize?

[brikis98]

Just wondering, why are different live environments in the same repository? Doesn't this make different implementing different policies for CI/CD pretty difficult to realize?

What sorts of CI / CD policies did you have in mind?

[trallnag]

@brikis98, for example that prod deployments require merge requests and something like 2 approvers but not non-prod deployments. I feel like it would be just easier to do it in separate repositories

[brikis98]

Ah, I gotcha. Yea, some things definitely get easier with multiple repos. However, some things get harder too. In particular, it's harder to see everything deployed in your environments in one place, and keep it all consistent: i.e., the same services in each env, the same approach to state management, etc. So it's a trade-off, but if the trade-off for your company ends up being more favorable with multiple repos, then go for it!

[trallnag]

Alright, thanks

[gwvandesteeg]

The problem with the multiple environments in the repo breaks the entire purpose of CI/CD when you are promoting artefacts through the local build -> test -> stage -> prod. DRY is the whole purpose, by having each environment as its own directory inside the live repo you've created yourself a complicated copy paste problem and broken the DRY approach. You've repeated yourself in each environment.

[brikis98]

DRY is always on a spectrum: on one end is everything copy/pasted, so there's loads of duplication, and making updates is error prone, and on the other is 0 copy/paste, where there's no duplication, but then everything is tightly coupled. You rarely want either extreme. At the very least, you need something to indicate each environment exists and that those environments use specific modules, at specific versions, with the ability to define different input variables for each environment. You can make repetition very minimal if you want.

[gwvandesteeg]

I'm going to disagree on pretty much all of that, DRY with little to 0 copy/paste is achievable without tight coupling. The only perceivable coupling would be in regards to the fact that your promoting the changes from test -> stage -> prod as part of the intended purpose of continuous delivery. The only differences you should have are some variables defining names and IP addresses and the like. The only time you should have differences in versions in modules between your environments is when a change is being propagated through the CI/CD process until it reaches production. If you are allowing each environment to run different versions then you don't have a CI/CD pipeline for promoting the changes through to production, you're just running different environments from the same repository.
The point i'm trying to get across here is that the promotion of builds is done automatically through the entire CI/CD pipeline, the article you're referring to still requires manual promotion of changes from dev to stage to prod.

[randall-caylent]

This how-to should include examples of how to use either the DEPLOY_SCRIPT_ALLOWED_APPLY_REF environment variable or the --allowed-apply-refs-json command line flag for the infrastructure-deploy-script.