Git - Development with multiple environments

Question

We are a small software development company which started out with 2 people, but are now steadily growing. Therefore we need a development strategy using Git, but we are running into some issues. We are using Gitlab as our Git provider.

The situation:

• We have 3 environments all running different versions of the code: Development, QA and Production
• Each environment has its own Git branch: Development, QA and Production
• We usse Jenkins to pull and build the right branch for each environment. Currently this is not automated, but we intend to automate this in the future.
• When starting a new feature or fix, we create a feature branch, by branching from Production. We code and merge our feature branch with Development, QA and Production when it is time to do so

Now the issue we are running into is that when we merge our feature branch into development and QA, using merge requests, we also see the changes done on production. But those changes are already merged with development and QA, so these have no effect. This however makes it extremely difficult to track commits and do code reviews.

We are a young team and this is our first time tackling such issues. It could be that we have to change our Git strategy completely, so giving some feedback on multiple possiblilities to implement different strategies is more than welcome.

Answer 1

The question is a bit broad, and there are multiple strategies you could adopt here.

Generally, having one branch per environment ends up complicating the deploy pipeline because Git branches were not designed for release management. Git is designed to use 'tags' for release management.

How this would work is:

• All feature branches get merged to master
• Latest master is tested by QA. When QA completes the testing, tag the commit and release it to production.
• If there are bugs in master, the bug is fixed first before new features are merged.

One caveat is that the feature branch must be thoroughly tested by the developer and reviewer before merging. I would say that's a minimum amount of effort you would expect from a developer and reviewer.