5

We have a very large code base in mercurial. We have about a 6 month release cadence with 2 week sprints. For each release we have about 10 feature branches and maybe 5 or so people working per branch.

Now whether or not feature branches are a good idea is a question for another day.

Currently we do merge-downs/copy-ups from feature branches into the main QA line twice during that 6 months - once about 1/2 way through and once a few weeks before the end of the release. (specifically, merge-down from qa, then feature branch copies up).

The reason seems not to keep in sync with each other, but to enable some testing about half-way through the release.

This has caused a lot of angst about looming merges and a few nasty merge conflicts, but not as many as one might expect.

So I guess my questions are:

  1. Would having more frequent merges just for the sole purpose of keeping things in sync and preventing surprises create more churn or less churn?

  2. If so, what would be a good schedule? I've thought about this a bit - more frequent merges would require teams to have their code in good shape more often, which might not be a bad thing. Too often though might spread bugs around to all feature branches before they get a chance to be fixed.

We're using Hg, but I'm adding git as a tag because I think the issues are pretty much the same.

Improve this question
5
  • 2
    How good are your teams at delivering working software at the end of each sprint? If you deliver working software at the end of each sprint, what is stopping you from merging the result of each sprint to the main QA line?
    – Bart van Ingen Schenau
    Apr 16, 2015 at 18:17
  • 5 people work simultanously on one branch, where each branch is one feature? How comes the communication overhead does not explode? Splitting up the work into smaller features (=feature branches), where each feature is developed by less people, might help.
    – Doc Brown
    Apr 16, 2015 at 20:50
  • Is this code base comprised of only one large repository?
    – Dimas Kotvan
    Apr 16, 2015 at 21:23
  • @DimasKotvan no, it is about 15 repos. Typically a feature spans several repos unfortunately.
    – marathon
    Apr 17, 2015 at 0:19
  • @DocBrown communication has never been a problem. Maybe because the code base is so vast there are seldom people stepping on each other. Also, oddly, there is almost no communication between feature teams except at the scrum master level.
    – marathon
    Apr 17, 2015 at 0:23

1 Answer 1

Reset to default
6

The good schedule is to merge only stable code (or "likely to be stable" code).

If you merge half-way just to begin tests, and you know that some of the features you're currently coding are not finished, you surely will get some testing feedback about these features.

The question you have to ask is "Am I confident with the completeness of what I already built ?"

If the answer is Yes, you can test it. If not, there is no point testing it, just keep coding.

EDIT : Actually, you could start testing partially each time one of your devs tells you that he finished a feature that could be ok by itself.

Improve this answer
3
  • in theory our feature branch code is supposed to be stable by the end of each sprint. While all our unit tests usually pass, I'm not sure things are ready to be shared that soon. Maybe each team could make that determination. But if they did, they would probably not merge until they were forced to.
    – marathon
    Apr 16, 2015 at 16:33
  • 4
    If they are supposed to be stable at the end of each sprint, you should test it right there, in order to continue on a clean project. But it depends on the depth of your tests, if they take more time than the sprint itself, it doesn't make sense to do it too often.
    – Caillou
    Apr 16, 2015 at 16:39
  • You can merge incomplete code and not get feedback on how buggy it is if you make sure testers won't be able to run it. That's fair if the users won't be able to run it either if a release was built from the current version. Either don't put in the final code to connect it to the UI, or include some feature toggle code that switches it off.
    – bdsl
    May 31, 2017 at 21:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.