https://pulumi.com logo
Title
b

brave-winter-60074

05/11/2021, 1:59 PM
Hi everybody We are using pulumi for our IaC and Azure DevOps pipelines for build, Iac, deploy etc in one pipeline pr microservice. We now want to take the project further and start having staging and production environments as well. How to handle this in a smart way when using Pulumi? Azure DevOps Releases doesnt seem to fit our needs and we don’t think its a good idea that every develop can update the “prod” pulumi stacks and we would also like to have some kind of gate when going from staging to production. Any thoughts, articles or ideas? Thanx in advance
e

enough-butcher-66045

05/12/2021, 1:16 PM
what's the target component in Azure? App Services?
We're deploying to a preprod slot in the app, and the actual swapping to prod happens manually by authorised people
b

brave-winter-60074

05/12/2021, 3:29 PM
Hi @enough-butcher-66045 its actually many things, function apps, app configuration, storage, cosmosdb account etc etc. Self contained microservices consisting of several azure resources and configuration created by Pulumi code and then deployed from a build artifact. But maye the preprod slot could be interesting to be a manual process
e

enough-butcher-66045

05/12/2021, 3:34 PM
I mean, you can have azure pipelines evaluate which branch/tag is being pushed and decide whether to run the deployment job/stage based on that
assuming you have code reviews in place, no one would be able to simply push to production, it'd require approvers
if you're using github you can use the CODEOWNERS feature to require approvers
not sure if azure repos offers something similar
what's not clear for me is: Are you trying to deploy a specific project or are you trying to rebuild your entire production infrastructure? The latter seems tricky imo.
r

rich-farmer-40546

05/12/2021, 3:37 PM
What I would suggest is create a component resource, have different repositories for your environmental pipelines so you can create access control to who can promote changes in each environment.
You could even manage without a component resources and in azure devops have a step to just bring in that repo itself. But ultimately you want to be able to differentiate your environments and where that configuration lives, you don’t want to have:
Pulumi.dev.yaml
next to
Pulumi.prod.yaml
basically. They could live in different repos. Another solution would be that your azure devops pipeline have different stages, and using azure devops environments, you can control who can deploy to each stage. In this scenario you do have everything in the same repo, but you’re using azure devops itself to be that access control.
With Azure DevOps Environments, you can say “Only This Team or This Person can approve X stage gets run”, so you could have: Only the release manager can approve so the code gets run into production. Etc…
There’s many ways to go about this and it really depends on your organization’s structure, those two examples align to different concerns, but you can always mix and match.
b

brave-winter-60074

05/19/2021, 7:31 AM
Thanks @rich-farmer-40546 I will look in to your suggestions, we would really love not to have seperate branch for production (trying to be trunk based development ish)
but environments sounds like a way to go, that still doesnt solve the case with a pulumi restriction so that all the devs cannot access the prod stage, only solution i can see is to pay for a “silent” user with pulumi token that manages prod. and thats a quite expensive workaround
r

rich-farmer-40546

05/19/2021, 2:48 PM
Something I’ve stumbled upon is that, application code and how it’s deployed are two separate concerns, that you can use a same repo to attend, but you shouldn’t lock yourself in that mindset.
A commit id is ultimately a way for you to say, hey, this is an artifact, the state of my app code. And how it gets deployed doesn’t necessarily have to live in the same repo. There’s many git branching strategies that assume you are using the same repo for deploying, like git flow. But things like single trunk are usually more on the side of “how this gets deployed, environments? they’re not my concern”
When you do mix them, you tend to then have to make many exceptions. Because your app code lives with your code and logic on how it gets deployed, you start to ignore files, then folders, it gets more as the complexity of your deployment is. This is exacerbated in kubernetes environments, where you see things like: Dockerfile, pipeline file, helm chart or kustomize, etc, and you have to ignore them for a pipeline build and deploy, or not.
That’s where ultimately you see patterns like gitops appear, and in this approach you will usually see that it’s another repo that has all those concerns, and it is separate from the app repo.
All of these patterns are valid, I’d suggest you maybe open up to see if another one adjusts better to your needs.
Adding this as context, and to answer your last concern, if you have different repos that represent your environments, you can place to access control there, in who the code owners, or who is allowed to merge to that repo which could represent production
But I like to think of this in terms of “Where are you putting the access control?” is it git? is it in the pipeline?
Maybe both? different repo and azure devops environments?
Just using the pipeline itself, without separating the git code or anything else, you could say, even though a developer could make a mistake and commit/push to the production branch, that would not get deployed by the azure pipeline until someone approves that to get executed in the environment. So you have added that safety.
Though you still have the issue with people can still ‘touch’ the production branch, the code. That’s where separating that out helps, or move the concern elsewhere.
b

brave-winter-60074

05/20/2021, 12:16 PM
Thank you very much @rich-farmer-40546 for all your valid input, that gave me and my team some additional stuff to think about before setting up our production pipeline and setup.
🙏 1