Let's say you have three development branches going at once (dev 1, dev 2, dev 3), each branch working on different features for a given software product.

If I understand continuous integration correctly, these development lines would each need to constantly check code back in to a shared main line (once it has passed testing), with the shared main line code being merged back in to each dev branch on a regular basis.

What happens though when one of the dev branches (dev 1) is ready for a production deployment, and the other dev branches (dev 2, dev 3) are not? If the dev 1 branch code gets pushed through UAT and in to Production, all code from dev 2 and dev 3 branches that have been 'continuously integrated' in to dev 1 will also get pushed in to Prod, even though features in dev 2 and dev 3 may not be ready (or scheduled) for release.

How can I avoid this problem while still adhering to Continuous Integration?

  • I should clarify. In my above example, any code checked back in to the 'main line' has been tested and is stable.
    – Callum
    Oct 27, 2016 at 5:58

3 Answers 3


Further to Vlad, you would set up testing environment(s) for each branch. CI would then be configured to push changes made to branch A to Test A and Branch B to Test B.

A branch can contain between 1 and n features. The fewer you have in a branch, the less impact if it slips.

The changes stay in their branches until they have been released.

Once Release A has been made you would merge the new Main (containing release A) into Branch B and continue working on Release B.

The only limit to the number of branches you can run simultaneously is your team/infrastructure. One dev can theoretically be assigned more than one feature isolated in separate branches simultaneously. Do I recommend doing that? Probably not. Finish one job at a time. If however there's a change in priorities, a branch can be parked while another one is worked on.

  • Thanks, but this doesn't address the problem of what happens when release B is ready for a Prod deployment but release A is not.
    – Callum
    Oct 27, 2016 at 6:01
  • @Callum - the opposite. Merge B into the main branch, release, merge the main branch into branch A (and any other in-flight branches) and continue development on branch A. Meanwhile you create branch C, D etc. to do more features. Continue until the software is finished ;)
    – mcottle
    Oct 27, 2016 at 6:40
  • Ok, I think I'm getting this. With Continuous Integration, are you saying there should be absolutely no merging of any code between distinct development lines unless a given development line is in the process of being (or already has been) deployed to Production?
    – Callum
    Oct 27, 2016 at 6:41
  • 1
    This may be 'using a CI tool', but it is not CI. Integration is not continuous, it is done in chunks, based on branches that have had months of seperate development. This will slowly kill you with technical debt, becuae noone can safely refactor.
    – soru
    Oct 27, 2016 at 11:58
  • 1

This statement is wrong: "development lines would each need to constantly check code back in to a shared main line". The very reason to introduce branches is to not merge unstable code to main. Why do you actually need three dev branches if you are merging to main right away?

CI does not push you to sacrifice quality for deployments frequency. It pushes you to deploy as fast as possible, but not faster.

  • Thanks Vlad, I should have specified in my example that any code checked back in to the 'main line' has been tested - but is not necessarily scheduled or ready for a production deployment.
    – Callum
    Oct 27, 2016 at 6:00
  • 1
    Callum, you are saying "we deploy the code which is not ready for deployment, how to avoid this?" Don't push to main branch the code which is not mature by all the criteria you have (not only tests).
    – Vlad
    Oct 27, 2016 at 6:10
  • Just because code has been tested and is "ready" for deployment does not mean the business will make a decision to deploy that code ASAP. We recently had some software features delivered ahead of time but we did not deploy straight away because other areas of the business were still setting up advertising campaigns and competitions around the deployment. Hence, we waited.
    – Callum
    Oct 27, 2016 at 6:38
  • 1
    Would I be right in saying that if my org is doing Continuous Integration, that we should refrain from merging dev lines unless a given dev line is in the process of being deployed to production, even if it successfully passed all testing and was 'finished' 3 months earlier?
    – Callum
    Oct 27, 2016 at 6:39
  • 1
    Yes, it is a right thing to do.
    – Vlad
    Oct 27, 2016 at 6:40

As @vlad indicated the problem is with "development lines would each need to constantly check code back in to a shared main line"

Here's what you should consider doing:

  • create a development branch as needed
  • do work on the branch and push the commit in that branch
  • fetch the latest changes from master (to update your master, NOT your branch)
  • rebase or merge your branch against master, but stay in the branch
  • push the updated branch to remote
  • continue work, rebasing against master and pushing commits during development
  • when work is done, merge into master and release.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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