We have a PL/SQL (Oracle DB procedural language, but it doesn’t really matter) git project. We have
develop branch that holds all changes and appears to be PRO current state (though it should’ve been better to use
master instead but it’s been for years). We usually create branches from
develop, do some changes to this branch (assume, it’s
feature/JIRA-1234). Then we have env-branches that represent state of QA, Integration, UAT testing envs (assume, it’s one of them and it’s
env/qa). We merge ready-to-be-tested features into desired env branches. After testing we create release branch that collects all the features which are ready to be deployed in PRO. We check deployment on stage env, fix installation problems if any and then tag the latest commit of this branch with release tag and pass it to OPS team which takes care of deployment process.
A problem we’re facing now with such approach is that
feature/JIRA-1234 branch remains "unprotected" after merging to
env/uat, etc up to the moment of merging to a release branch. So I can pass a branch to a QA team after having 6 commits there and push something new to this branch and then pass it to
env/uat, for instance, and later even make changes before it will be merged into release branch. So after some time QA engineer can’t really say that he/she tested the latest version of the branch.
I thought of maybe somehow "locking" the feature branch from merging before some event happens (like "QA passed"). Or maybe change development process. Sometimes developers want to improve their code by adding a small little fix that really shouldn’t be tested but later it turns out to be a bug in PRO.
We are using gitlab as a tool for reviewing and managing merge requests. So possibly it has some tools for solving this puzzle but I haven’t managed to find it so far.
Any suggestions are appreciated! Or maybe you can share links with articles that cover such situations.
I’m aware of
git flow approach. I don’t think that it works for us as we can’t merge features back to
develop as a scope of the upcoming release is uncertain till some moment in time. So my tested feature couldn’t get into a release just because biz team doesn’t want to see it in PRO by now. That’s why we don’t have
develop branch in terms of
git flow approach.
Thanks to @JoelFan I finally got understanding of working with branches.
Also after some googling I found out that except git-flow process there exists github-flow and gitlab-flow.
The first one is quite simple and applicable for a small and quick-to-roll-out releases while the second one offers an approach for SAAS-like products which have env-dependent branches. I think it will be useful for our releasing model with some additional tweaks.
Answered By – Roman
This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0