We're deploying to a preprod slot in the app, and the actual swapping to prod happens manually by authorised people

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.

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.

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

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.