Hey guys, we are using Pulumi Self-managed backend to make K8s deployments in a team environment and use the common stack for the same purpose. Aside from that, we deploy apps to K8s platform through CircleCI deploy pipelines whenever there is a merge to master branch but we are facing concurrent update issue when there are concurrent merges to master stating that there are 'pending_operations' for previous Pulumi update operation. To get this around, one probable solution I can think of would be to ask people to create different stacks based on what they work feature development/fix an issue so they wouldn't interfere with other's Pulumi update operations. Any other suggestions you guys could think of?

IIRC self-managed backends do not lock on updates, you need to do that yourself. Also self-managed backends do not automatically separate your state by project, you need a new backend location for each pulumi project - otherwise stacks with the same name across projects will collide.

How about creating different stacks with distinct names based on different feature/fix branches having the same backend and triggering deployment pipeline for every master merge?

I don't understand - it would make sense to have feature branch stacks but those stacks would only be alive until the merge at which point they would be destroyed, so why would you trigger them on master merge?

Yes, we trigger deployment pipeline during master merge but I was wondering if we could delete feature branch after successful deployment of the concerned stack with feature branch name. I don't know if this is the optimal solution but want to try to see that's gonna help though.

ah. I've always wanted to implement something like that! Maybe it could be part of the merge pipeline? I.E. check if the source branch is

feature/XXX

and if so, run a destroy on a stack name generated by that source branch? Or maybe there is a way to trigger a pipeline when a branch is deleted? It's easy enough to have a pipeline that catches

feature/XXX

branches and spins up a new stack accordingly, but finding the right moment to destroy that stack is tough, right? Like the PR pipeline will have already been executed once the PR is approved and the branch is merged to master and the feature branch is deleted, at which point the pipeline that is then triggered on master is probably no longer aware of the source branch so it may not know what stack to destroy after updating the master stack... I'm really curious to hear what you come up with though because I would love to configure feature branch stacks for my devs at some point!

Sure, I will let you know for certain if I come up with anything in future 🙂