4 ms·
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
by willsmith72 3y ago
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
- geraldwhen 3y agoOr put the sha in the version number.
- redcobra762 3y agoSo if the “deployed branch” were really just a “tag”, that would fit trunk based development? Because that’s basically what git is doing. It’s not like there are two sets of files anywhere, afaik. My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.
- deleted 3y ago[deleted]
- ToJans 3y agoI've been working on my product for over 8 years, sometimes alone, sometimes with a tiny team. I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging. I can hot-swap my staging and production environment with the click of a button. Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be validated first... But,... It all depends on your context and your needs...
- willsmith72 3y agothe hotfix is extremely useful but you have to be so so careful when you're missing up history, when it comes to db migrations and api compatibility
- andix 3y agoSounds neat, but I still think complexity is removed if the deployment is not directly linked to the code repository. For me the code repositories purpose is to build software, and operation is not it's responsibility. I prefer having a gitops repository that describes the environment. Completely decoupled from the source code repository. If some automation directly from the source repository is required, a CI job can automatically update the gitops repository and trigger a deployment. Separation of concerns.