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:
-
Would having more frequent merges just for the sole purpose of keeping things in sync and preventing surprises create more churn or less churn?
-
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.
Best Answer
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.