20

I've been doing some reading about continuous integration recently and there is a scenario which could occur which I don't understand how to deal with appropriately.

We have a stable mainline/trunk branch and create branches for features. Each developer will keep their own feature branches up to date by merging from trunk into their branch on a regular basis. However it is entirely possible that two or more feature branches could be created and worked on over a period of several weeks or months. In this time many releases of the software could be deployed. This where my confusion arises.

It is very likely that changes for one feature branch will cause merge conflicts with other feature branches. CI suggests you should merge into trunk at least daily which would resolve the conflicts quickly. However, you may not want to merge the feature code into trunk because it may not be finished or you may not want that feature available in the next release. So, how do you deal with this scenario and still follow CI principles of daily code integration?

Daniel Daranas
  • 22,454
  • 9
  • 63
  • 116
Phil Hale
  • 3,453
  • 2
  • 36
  • 50

6 Answers6

11

There are no feature branches in proper CI. Use feature toggles instead.

Aleš Roubíček
  • 5,198
  • 27
  • 29
  • 2
    Why do you think so? Feature toggles are great but the person living in a feature branch would like to reap the benefits of CI before he has pushed the feature out toggled or non-toggled. – toomasr Apr 10 '11 at 10:54
  • 10
    I do not agree with this feature toggle thing. A source control software has several features. One of them is to take care of changes and backup of your source code. Developper should be able to have the reliability of source control even if their code doesn't compile or doesn't build or isn't stable enough for production. Not all modifications can fit in a few hours... Branches allow your code to be safe without risking breaking the trunk. – Nicolas Bousquet Apr 18 '11 at 15:39
  • 2
    Every change you do, can be small, so you never check-in code that does not compile. It is true message of CI :) – Aleš Roubíček Apr 21 '11 at 07:12
  • 20
    This is oversimplified: even though I wrote a [feature flag implementation](https://dev.launchpad.net/LEP/FeatureFlags) and love the idea, they are not a panacea. Not every project, or every feature, is amenable to a runtime toggle, and not every bug people could introduce can later be disabled through a flag or will be caught by flag-based testing. People can reasonably want to have feature branches that live at least for a couple of weeks, and that get regularly tested. – poolie Sep 19 '11 at 08:28
  • 6
    #ifdef SOME_FEATURE_IS_ENABLED (or it's Web2.x interpreted language kin), is a horrible, horrible idea. – slacy Aug 31 '12 at 17:26
  • Compile time toggles sure is. – Aleš Roubíček Sep 03 '12 at 06:36
  • 10
    Feature toggles are a terrible idea. It is almost impossible to toggle off and isolate changes between versions this way as not all features being developed are completely isolated from one another: they may share substancial amounts of code, or the work for a toggled off feature may include changes to a common library, so toggling off does not isolate this change. Code for features that are not complete should not be in the dev/trunk branch period. There is no reason why feature branching cannot be used with CI if forward merges from the trunk and back are not too far apart. – MrLane Oct 10 '12 at 03:37
  • Of curse you should have good architecture and use techniques like branch by abstraction and inversion of control. I did not said it is easy. But it is doable and mostly worth it. – Aleš Roubíček Oct 10 '12 at 06:56
9

The idea explained more fully in this article is to merge from the trunk/release branch to feature branches daily, but only merge back in the other direction once a feature meets your definition of 'done'.

Code written by one feature team will be pushed into the trunk once it's complete, and will be 'distributed' to the other teams, where conflicts can be dealt with, as part of the daily merge process.

This doesn't go as far as satisfying Nick's desire for a version control system that can be used a backup tool, unless the changes being made are small enough that they can be committed to the feature branch within a timeframe where the the risk of losing your work is acceptable.

I personally don't try to reintegrate code into the release branch before it's done, and although I've never really tried, I'm sure building feature toggles in for unfinished work has its own issues.

nzduck
  • 476
  • 4
  • 12
  • You're either doing Continuous Integration or not. Under CI, commits should be integrated to the mainline on a daily basis. That means you should not only merge from the trunk to feature branches, but also merge the feature branches to the trunk on a daily basis, which beats the purpose of having feature branches in the first place. Simply, feature branches are not compatible with CI – Jake Dec 05 '15 at 18:22
3

I think they mean merging mainline into the feature branch, not the other way 'round. This way, the feature branch will not deviate from mainline too much, and be kept in an easily mergeable state.

The git folks do the same thing by rebasing feature branches on top of the master branch before submitting a feature.

Simon Richter
  • 28,572
  • 1
  • 42
  • 64
  • That's what I've said, but I may have not worded it very well. My question is specifically about the problems associated with having *multiple* feature branches and wanting to follow CI practices – Phil Hale Feb 09 '11 at 10:42
  • 1
    Multiple feature branches aren't special; each of them must be easily mergeable into mainline and work on its own. If another branch is merged, then that change needs to propagate to the other feature branches, which may require manual resolution -- this is however something you cannot avoid, but at least you are doing that in the feature branch rather than in mainline. – Simon Richter Feb 09 '11 at 11:46
2

In my experience with CI, the way that you should keep your feature branches up to date with the main line changes as others have suggested. This has been working me for several releases. If you are using subversion make sure you to merge with the merge history enable. This way when you are trying to merge your changes back to line it will only like you are merging the feature changes to line, not trying resolve conflicts which your feature might have with the main line. If you are using more advance VCS like git the first merge will be a rebase where the second will be a merge.

There are tools that can support you to get thins done more smoothly like this Feature branches with Bamboo

GAP
  • 29
  • 6
1

Feature branches committing back into the mainline, and OFTEN is an essential feature of Continuous Integration. For a thorough breakdown, see This Article

Sam Jacobs
  • 346
  • 1
  • 8
1

There's now some good resources showing how to combine both CI and feature branches. Bamboo or Feature Branch Notifier are some ways to look.

And this is another quite long article showing pros of so called distributed CI. Hereunder, one excerpt explaining the benefits:

Distributed CI has the advantage for Continuous Deployment because it keeps a clean and stable Mainline branch that can always be deployed to Production. During a Centralized CI process, an unstable Mainline will exist if code does not integrate properly (broken build) or if there is unfinished work integrated. This works quite well with iteration release planning, but creates a bottleneck for Continuous Deployment. The direct line from developer branch to Production must be kept clean in CD, Distributed CI does this by only allowing Production ready code to be put into the Mainline.

One thing that still can be challenging is keeping the branch build isolated so that it doesn't pollute your repository of binaries by pushing its branch builds to it. Bamboo seems to address that, but not sure it's as easy with Jenkins.

Doc Davluz
  • 4,154
  • 5
  • 30
  • 32