Home/ Questions/Q 7491285
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T15:57:28+00:00

Given that we are using GIT with more or less the branching workflow of

  • 0

Given that we are using GIT with more or less the branching workflow of http://nvie.com/posts/a-successful-git-branching-model/ does it make sense to regularly do integration testing with a CI tool like Jenkins by following this process.

  1. Create a new branch just for the daily integration test, branching from develop
  2. Merge all feature branches scheduled for the next release (if we name them all Sprint-#-feature then we can select branches by name prefix and auto merge) into this special branch
  3. Run CI integration tests on this new branch
  4. Delete the branch

My theory is that by doing this we can avoid scary merge problems in a couple of ways. First of all an auto merge could fail letting us know that during the day something was done to move us out of simple merge territory. Secondly, we get the results of the same kind of integration tests that we would have had if we had decided to merge everything into a release at that point in time. Obviously this does depend on developers cleaning up their work on feature branches and pushing to master every day before the CI build starts but that doesn’t seem like a really onerous requirement. Since we throw away the merge this means that a developer still has a chance to clean up their commit history before they do the official merge into the development branch.

Has anyone tried this kind of thing? Would you do it in a different way?

I’m really just looking for a way to leverage automation to do more testing and more frequent testing. Writing unit tests and TDD doesn’t really address this area of integration tests because you would generally run additional tests for integration, not just the unittests and TDD tests.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You actually get all the benefits you mention, plus one.

    The rerere extension to git will record your manual resolutions of merge conflicts, so if you do that daily integration branch-merge by hand when the automatic merger fails, your final “real” merge will be easier (and you can leverage this to make each discrete breakage be a one-time thing, since the next automerge will succeed).

    The only down side is confusion: it can be difficult to track which changes are present where. Be careful not to forget what’s not present in the integration branch…

    But yes, the principles are sound.

    • 0