5

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?

Improve this question
1
  • 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 '16 at 5:58
2

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.

Improve this answer
10
  • 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 '16 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 '16 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 '16 at 6:41
  • Yep. I'll edit the answer to make that clearer. – mcottle Oct 27 '16 at 6:44
  • Thanks for your adjusted answer, but I just don't like the term "ready to release" in your 3rd para, because this is what has caused me so much confusion. Code that is "ready to release" to me, means code that has passed all testing and has reached minimum viable product status, but that doesn't mean the business will choose to release it. The important distinction for me is that code merges between distinct development lines don't happen unless new code has physically been released to production, or at least has passed all testing and is in the process of being released to production..? – Callum Oct 27 '16 at 7:18
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.

Improve this answer
7
  • 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 '16 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 '16 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 '16 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 '16 at 6:39
  • 1
    Yes, it is a right thing to do. – Vlad Oct 27 '16 at 6:40
0

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.
Improve this answer

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.