I’m curious about <continuous delivery> and how to...
# general
b
I’m curious about continuous delivery and how to deploy / apply infrastructure changes safely and effectively. Let’s consider a Pulumi project that creates infrastructure for an application. It will be deployed to 20+ environments (qa, staging, training, production). Option 1 Deploy this Pulumi project in the same deployment process / pipeline as the application. This connects the Pulumi program version with the application version and environment. Currently we use CircleCI to deploy the application and can put manual approval steps in so the infrastructure changes can be reviewed before deploying the infrastructure changes. However, the preview of the infrastructure changes is hidden inside CircleCI logs or we have to navigate to the Pulumi web UI to see the changes. Neither is convenient. How can we make the infrastructure changes more visible during the deploy process? I’m open to changing tools, process, etc. Option 2 Deploy using a git branch per Pulumi stack. The preview of the infrastructure changes can be added to the GitHub pull request with the Pulumi GitHub App. In this approach, it feels like the Pulumi program might change from one git branch to another: might be convenient to add a custom infrastructure change to “just this one” stack / environment. Or people forget which git branch they are on. In this case, what options are available to reduce Pulumi program drift between git branches / stacks / environments?
s
Is the infra code maintained by same team as the app code or a different team? If different teams, separate repos may be best.
You definitely do not want 20+ git branches to separately maintain, so I would caution against Option 2.
b
Currently I am the only one adding / maintaining infra code for an existing application.
I am starting with a separate repo for convenience. Hopefully moving the application specific infra into the application repo when feasible