3

My team has been using Continuous Integration for a while now, using the 'everything goes in trunk' approach. We're investigating changing this practice to allow us to release individual features as soon as they are ready, without having to wait for other features to catch up (we have multiple teams working on different features at once). There are lots of examples on how to do this with branching strategies (branch per feature etc), using git and the like, and that's probably my preferred approach. But we've been asked by the managers to at least investigate other options, because the worry is that a branching strategy could result in delayed integration points, which we want to avoid. I don't want this to get into a discussion on CI/branchging strategy though, so I'll try and be specific in my question.

Has anyone used any strategies for releasing features when ready, without running multiple version-control branches? For example, using Branching by Abstraction or some other means of having features with different states of 'readiness' in a single branch. If anyone has experience (good or bad) with this kind of approach I'd love to know.

thecodefish
  • 388
  • 2
  • 13
  • Are your managers familiar with proper distributed version control? They may be worrying because of bad experiences with SVN / CVS, which make branching and merging much harder than it needs to be. Maybe point them to http://www.joelonsoftware.com/items/2010/03/17.html – artbristol Apr 11 '11 at 10:58
  • There is definitely a fear of merging, stemming from VSS/TFS experiences. We have a wealth of information as to how using a distributed system could solve those problems (thanks for the extra link though). I almost want that extra nail in the coffin though that says this single branch approach can't work for us. Or I want to be surprised and find evidence that it actually can. – thecodefish Apr 11 '11 at 11:08

2 Answers2

1

The branching by abstraction mechanism don't scale easily for large projects with legacy architecture, because said "abstraction layer" isn't always easy/quick to introduce in order to isolate your changes.

However, the other idea mentioned in this article is a very few number of branches, with only commits representing an application ready to be deployed.
That is something a DVCS (Decentralized VCS like Git or Mercurial) can easily accommodate because of the publication mechanism (orthogonal to branching), and which allows to:

  • not publish (not push) private commits made in a local repository (so you can branch/experiment as you want, and more importantly, you can rebase your work on top of official branches very often and very quickly to ensure your work don't diverge from a working application)
  • publish (push) your work, once ready, only on a 'trunk' or a 'release' branch on a unique repository acting as the reference for all the revisions "ready to be deployed".

That don't prevent to have other intermediate repositories to push to, in order to share intermediate works, but since said work has been rebased locally on top of official branch, even that development effort can be deployed and tested.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I don't have to rep to vote up unfortunately but this was useful - thanks. Will see if any other responses come in. – thecodefish Apr 13 '11 at 10:09
0

Try a social engineering approach to your managers desire to not use branches - use GIT with each feature done in it's own GIT clone, and pushed into the release clone when it's ready. Have a CI clone to ensure that the teams developing the features.

So the work flow, starting a new feature is

Clone the CI repo implement feature, regularly pulling from the CI repo Final pull from CI repo, then push feature into CI Push feature from CI into release repo.

All the Feature commits can be rolled into one big one if needed, or otherwise tracked such that they can be easily selected for pushing though the system.

With this solution you will never need to make a branch.

mattnz
  • 517
  • 2
  • 13