How do you handle integrating code from multiple branches/developers each sprint?

Question

Just got off a retro call where developers expressed concern around the integration of their stories into the master branch each sprint. The developers all code within their own branch and towards the end of the sprint they all merge into one master branch.

Then, one developer (usually the same one) is left with the task of making sure everything has integrated well with other dev's code (Most of the changes are on the same page. For example, a data display story, data filtering story, and a SLA indicator).

How can we reduce this burden and make it easier for our code to merge together? From my perspective, having the PO or SM prioritize the stories in a more efficient way so we don't have these sort of dependencies in the same sprint may solve some of the issues. How does everyone else tackle this? Or is this just part of the process?

Answer 1

If you are using Git, each developer would be pulling from the develop branch into their own feature branch so that they ensure they don't go too far from the current baseline. They can do that daily, so that tasks that take more than a couple days stay in sync and merge issues are resolved while they are still small.

When the developer is done with their work, they create a pull request. When approved, that gets merged into the develop branch.

The develop branch should always have working code, and be ready for release at any time. When you actually make a release, you merge develop into master and tag it.

If you have a good Continuous Integration Server, then it will build each branch when changes are checked in--particularly for pull requests. Some build servers integrate with your Git server to auto-approve or disapprove a pull request if the build fails or the automated tests fail. This is another way to find potential integration bugs.

Answer 2

I worked in a team where we struggled with the same problem. We found that the less time we had before integrating, the less difficult it became. I know most people teaching continuous integration talk about committing every few minutes - we probably actually committed every hour or so.

We also found that just building wasn't enough. We needed a good test coverage level in order to make sure that we didn't accidentally break each others' code.

Answer 3

• Keep your branches short-lived (it sounds like you're already doing this).
• Let your test results speak for themselves.
• Don't wait for the end of the sprint.

You don't even need to subscribe to TDD for this one. All you need are some tests which prove that your developers' features are working correctly. These could include Unit Tests and Integration Tests but will ideally be a couple of automated end-to-end tests of the critical features. Standard regression pack stuff.

Then, once your merge has been completed, you can check the automation test report together and verify that everything has been integrated successfully.

I agree with one of the other answers where the author stated Git PRs would solve this problem by getting each developer to merge their own work.

One other point which I believe is important enough to leave until the last paragraph. I suggest that you run manual tests over your nightly builds, rather than waiting until the end of the sprint. Developers should merge in as soon as the feature is complete so that it can be integrated, deployed, and tested as soon as possible.

Answer 4

Don't

Depending on your language and what files you're editing, it may not make sense for each developer to edit them on their own branch. For example, in C# I've found it's best for only one person to edit any UI designer files at a time. These are autogenerated files, and so code is sometimes moved around for no apparent reason - and this wreaks havoc on most merging tools.

This means that some stories may block other stories until the UI work is done. And/Or, a new story is created to just layout the UI, with the other stories implementing functionality. Or, maybe one developer does all the UI work while others implement the functionality of that UI.

On a related note, if you know multiple stories will all be touching the same file(s), you may just want to avoid working on them all at the same time. Don't pull them all into the same sprint, or don't start working on them all until one or more are done.

Answer 5

Another possible approach to avoid late and large merges are feature flags: you protect your changes with a (ideally dynamically) configurable flag that prevents them from becoming active before intended.

This allows you to merge your changes early back into either master or your joint development branch without breaking anything. Other developers can then merge these changes back into their feature branches (or rebase their branches accordingly).

As the other answers have already pointed out this should be combined with a continuous integration solution.

Feature flags have additional benefits (for example, they make it easy to do A/B tests). See this article by Martin Fowler for more information.

Answer 6

We are following an approach of separate development branch for each feature, and then we are merging the branches to a QA branch for testing in integration testing environment.

Once regression and integration testing is completed, we easily move the features which are ready to go, to the release branch.

If all goes well, we merge release branch back to master branch.

Answer 7

To put it simply, committing and merging often reduces the window of opportunity for merge conflicts and will greatly reduce conflicts. The other part is indeed planning by the lead, which can further ensure that work flows smoothly.

The other answers give some great insight regarding best practices for commits and simply by following those you'll probably reduce the vast majority of your merge issues. More merges is almost certainly a necessity, but for a smaller team, your branch-per-person approach probably works well enough. Of course, it doesn't hurt (much) to get into more extensible practices though!

However, no one seems to have addressed one of your most significant questions--what to do when you're all touching the same areas of code. This is where it's useful to have a lead who is familiar with the code base and can recognize dependencies of different tasks. If they don't orchestrate the timing of work and commits, you'll likely end up with merge conflicts and line by line resolution. Organizing the tasks\timing is much more difficult with a larger team, but with a small team its possible to identify these conflicting tasks. The lead could then even shift all the related tasks to the same engineer, to avoid the conflict altogether.