We have two system analysts in our team who can accept a merge request into master. That's a mere formality as they have no code expertise. We opted to not let devs do it just as a security measure towards proper versioning and release control.
They will accept the merge request and trigger build and deploy of the production channel.
Developers work in the develop branch until a release is created and sent to test, working in fixes directly in the release while new stuff can be added to develop for the following version already.
These merges that don't involve master can be accepted by the developers themselves.
Why, though? It is almost as if devs could commit directly to master, but with this extra step, we can guarantee some order in an environment that is very prone to people sending any proper versioning to hell and losing track of what is being tested or what can be released, etc.
Graph 1 is what a common gitflow looks like. My goal is to get my team to work with graph 1.
Graph 2 is what I got so far since I got in the project in the last few months.
Sorry for it not being in English. Quick translation:
Each of the main branches are an environment deployed separately. Jenkins is reading these guys, but it doesn't have to be this way.
M - Master: Production. Only receive merges from release branches, but can be the origin of hotfix branches
E* - Mirror: Same code as production, but with DB from the day before
H* - Release Candidate: The key users test the changes here and aprove them or not
T* - Test: The test team tests the changes here and aprove them or not
D - Develop: This is the origin of every feature branches and the origin of release branches.
B - Hotfix: urgent stuff that can't wait for a release
F - Feature: new stuff or bugs that aren't that urgent. These are your every day issues
R - Release: this is the features package planned to be released next.
*These aren't really needed. You can deploy the RELEASE branch directly in the proper environment.
After you have a good amount of stuff in DEVELOP, you can create a RELEASE and this is what you will give your testers to test. After test, this is the branch you will send your key users as a release candidate. All fixes in the release both from testing and from the users are made directly in it. Meanwhile, you can keep developing the following release into DEVELOP and it will not mess with your current release candidate.
After all set, today we merge into MIRROR just as a prediction of what it will look like in production. Normally that wouldn't really be needed.
All that to say that the merge request into master is the smallest part of all this. By then, the version to be delivered will already be very well tested and there is no point in actually reviewing the whole thing again.
The merge request into master is really only accepted by the system analyst because developers are humans and humans sometimes tend to try shortcuts that can and will mess with everything.
Giving devs only the DEVELOP branch to play with, it is guaranteed that what is being done will eventually be part of a release that will be tested.
I am an enthusiastic front-end developer with more than 8 years of experience in London. I love anything interactive and UX is my top priority when it comes to coding, followed by good practices
Location
London
Education
Electrical and electronics engineering at City university, 2:1
Commit to master. Not joking.
Totally agree, it's the only sensible way to develop in my opinion. Everything else is just extra process that slows you down and leads to problems.
We have two system analysts in our team who can accept a merge request into master. That's a mere formality as they have no code expertise. We opted to not let devs do it just as a security measure towards proper versioning and release control.
They will accept the merge request and trigger build and deploy of the production channel.
Developers work in the develop branch until a release is created and sent to test, working in fixes directly in the release while new stuff can be added to develop for the following version already.
These merges that don't involve master can be accepted by the developers themselves.
That sounds dreadful
Why, though? It is almost as if devs could commit directly to master, but with this extra step, we can guarantee some order in an environment that is very prone to people sending any proper versioning to hell and losing track of what is being tested or what can be released, etc.
Take a look into these two graphs:
tinyurl.com/thssnpx
Graph 1 is what a common gitflow looks like. My goal is to get my team to work with graph 1.
Graph 2 is what I got so far since I got in the project in the last few months.
Sorry for it not being in English. Quick translation:
Each of the main branches are an environment deployed separately. Jenkins is reading these guys, but it doesn't have to be this way.
M - Master: Production. Only receive merges from release branches, but can be the origin of hotfix branches
E* - Mirror: Same code as production, but with DB from the day before
H* - Release Candidate: The key users test the changes here and aprove them or not
T* - Test: The test team tests the changes here and aprove them or not
D - Develop: This is the origin of every feature branches and the origin of release branches.
B - Hotfix: urgent stuff that can't wait for a release
F - Feature: new stuff or bugs that aren't that urgent. These are your every day issues
R - Release: this is the features package planned to be released next.
*These aren't really needed. You can deploy the RELEASE branch directly in the proper environment.
After you have a good amount of stuff in DEVELOP, you can create a RELEASE and this is what you will give your testers to test. After test, this is the branch you will send your key users as a release candidate. All fixes in the release both from testing and from the users are made directly in it. Meanwhile, you can keep developing the following release into DEVELOP and it will not mess with your current release candidate.
After all set, today we merge into MIRROR just as a prediction of what it will look like in production. Normally that wouldn't really be needed.
All that to say that the merge request into master is the smallest part of all this. By then, the version to be delivered will already be very well tested and there is no point in actually reviewing the whole thing again.
The merge request into master is really only accepted by the system analyst because developers are humans and humans sometimes tend to try shortcuts that can and will mess with everything.
Giving devs only the DEVELOP branch to play with, it is guaranteed that what is being done will eventually be part of a release that will be tested.
I agree that you don't need graph 2, graph 1 looks good and is very similar to what we do.