4

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.

Improve this question
5
  • Are you using squash-and-rebase as your merge strategy when merging into development and QA? Commented Oct 23, 2020 at 10:03
  • @LasseV.Karlsen We do not squash commits as we would like to have a history of changes. Commented Oct 23, 2020 at 10:04
  • 1
    @Cerebres Squashing commits doesn't remove the history of changes, it actually makes it more readable and easier to work with. Commented Oct 23, 2020 at 12:00
  • 1
    @Mit94: that's true as far as it goes, but sometimes it goes too far. :-) More precisely, when using git merge --squash, you're generally best off killing off the branch on which you made the original commits. You trade N original commits for one single commit that does what the N original commits did. Depending on the original commits, this can be good or bad (or a mix). Commented Oct 23, 2020 at 19:47
  • There is no magic bullet for the problems you get with releases, but I recommend reading through the entire set of articles here. Basically, create a strategy for doing releases, but then also think about how you go about doing bug fixes. Commented Oct 23, 2020 at 19:50

1 Answer 1

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.