Peter Verkest's List: Qwan Technology

• The basic idea of a feature branch is that when you start work on  a feature (or story if you prefer that term) you take a branch of  the repository to work on that feature.
• The advantage of feature branching is that each developer can  work on their own feature and be isolated from changes going on  elsewhere. They can pull in changes from the mainline at their own  pace, ensuring they don't break the flow of their  feature. Furthermore it allows the team to choose its features for  release.
• Although our developers can develop their features in isolation,  at some point their work does have to be integrated.

• The problem I worry more about is a semantic conflict. A simple  example of this is that if Professor Plum changes the name of a method  that Reverend Green's code calls. Refactoring tools allow you to  rename a method safely, but only on your code base. So if G1-6  contain new code that calls foo, Professor Plum can't tell in his  code base as he doesn't have it. You only find out on the big merge.

  A function rename is a relatively obvious case of a semantic  conflict. In practice they can be much more subtle. Tests are the  key to discovering them, but the more code there is to merge the  more likely you'll have conflicts and the harder it is to fix  them. It's the risk of conflicts, particularly semantic conflicts,  that make big merges scary.

• This fear of big merges also acts as a deterrent to  refactoring. Keeping code clean is constant effort, to do it well it  requires everyone to keep an eye out for cruft and fix it wherever  they see it. However this kind of refactoring on a feature branch is  awkward because it makes the Big Scary Merge worse. The result we  see is that teams using feature branches shy away from refactoring  which leads to uglier code bases.

   
• CI is effective at removing the problem of big merges, but it's  also a vital communication mechanism.
• It's important to note that, most of the time, feature branching  like this is a different approach to CI. One of the principles of CI  is that everyone commits to the mainline every day. So unless  feature branches only last less than a day, running a feature branch  is a different animal to CI. I've heard people say they are doing CI  because they are running builds, perhaps using a CI server, on every  branch with every commit. That's continuous building, and a Good  Thing, but there's no integration, so it's not CI.
• The point here is that the primary issue with  the isolated feature branching scheme is its isolation. When you  isolate the feature branches, there is a risk of a nasty conflict  growing without you realizing it. Then the isolation is an illusion,  and will be shattered painfully sooner or later.
• I see CI as primarily giving birth to  a release candidate at each commit. The job of the CI system and  deployment process is to disprove the production-readiness of a  release candidate. This model relies on the need to have some  mainline that represents the current shared, most up to date  picture of complete.
• With CI, you lose the ability to use the VCS to do cherry  picking. Every developer is touching mainline, so all features grow  in the mainline. With CI, the mainline must always be healthy, so in  theory (and often in practice) you can safely release after any  commit. Having a half built feature or a feature you'd rather not  release yet won't damage the other functionality of the software,  but may require some masking if you don't want it to be visible in  the user-interface. This can be as simple as not including a menu  item in the UI to trigger the feature.
• On the whole, however, I don't think cherry-picking with the VCS  is a good idea.
• Feature Branching is a poor man's  modular architecture, instead of building systems with the ability  to easy swap in and out features at runtime/deploytime they couple  themselves to the source control providing this mechanism through  manual merging.
• I much prefer designing the software in such a way that makes it  easy to enable or disable features through configuration changes. My  colleague Paul Hammant calls this Branch by  Abstraction. This requires you to put some thought into what  needs to be modularized and how to control that variation, but we've  found the result to be far less messy that relying on the VCS.
• Indeed with a disciplined team, I would usually  prefer to use a DVCS on a CI project than a centralized one. With a  less disciplined team I would worry that a DVCS would nudge people  towards long lived branches, while a centralized VCS and a  reluctance to branch nudges them towards frequent mainline  commits. Paul Hammant may be right: "I wonder though, if a team  should not be adept with trunk-based development before they move to  distributed."

12 more annotations...