Hoping someone can help me get my head around the best way forward on this…
We’re creating a set of DevOps standards to serve as guidelines for new products we create in house.
One of the things we want to create a standard for is our branching strategy. We want to use GitFlow with feature branches merged into release branches as well as back into the develop branch.
We have local development environments then hosted int, QA, stage and prod environments.
My question is this… once a release branch is ready which environment should it be deployed into first? Should it pass through all environments or should it go straight into Stage because the feature branches have already been tested and so that development can continue in until and QA?
Just looking for some general direction really from people that have released using similar branching strategies. So much conflicting info out there it’s hard to make sense of it all!
Feature branch should be merged only with Dev and not with Release. Upon successful testing, Dev should be forked to release branch. Release should be considered as ‘production-ready’ code base and only ‘emergency/bug’ fix code updates should be directly merged with release before pushing to production.
Where to release first ? This depends on your test plan/ functional tests and number of environments. In your case, it should be QA > Staging -> Prod.
Once I’ve forked a new release branch should I create a package from that for deployment and if so should it be deployed through QA, stage an then prod? Or should the package created from the release branch go straight into stage so we don’t tie up the QA envy which might be being used for other dev streams / product versions given that the features in the release branch were already tested before the fork to release.
Good continuous deployment practice says that the same packaged code should be deployed throughout environments but if I’m forking and cutting out environments because the code has been tested on another branch I’m not adhering to this?