I’m not sure if we’re on the same page; let me try to explain in a different way what I would like to achieve:
- I probably wouldn’t use branch deploys - branches are short lived (e.g. hours or a couple days at most) so it probably isn’t worth it
- All code is merged directly to master branch.
- Master branch deploys to two (or more? I would probably only use 2 to start, but I have used 3 at various places) different sites:
- a “stage” website. This website is always deployed/updated when code is merged to master
- a “prod” website. This website deployment is “locked”, and then can be “unlocked” when we’re ready to “deploy to prod”. We can then lock it again afterwards
- Both the stage and prod website are managed in a single website config, since really it’s the same repo and even same branch - the only difference is which specific commit has been deployed.
This workflow better matches how trunk-based development generally works, and would improve trunk-based workflows significantly.
Does this help? Let me know if it still doesn’t make sense. Thanks!