>Wrong approach.
>
>Branching is an anti-pattern in continuous integration. Why? You aren't continuously integrating. You should work on the trunk almost exclusively and branch very rarely, and then if should be so short-lived that it doesn't need CI. See my presentation on this https://www.youtube.com/watch?v=aX4nf5Co16Q
>


Hi Craig.

I saw your presentation, but I don't agree with what you said about branching. Branching is not evil, as you said.

May be branching was not good in the past, with old tools like SourceSafe, CVS or even Subversion, but it is something very useful now with modern DVCS tools like Git, Plastic or others.

What you describe is a world of development on which every line of code is going to trunk, but there are valid reasons to develop in parallel, and there are a lot of people doing it right now.

Your workflow is in concordance with the limits imposed by old SourceSafe, when you needed to checkout a file exclusively and nobody else can make modifications to the same library. This is no more the case, and now you can make parallel modifications and merge them later, using tools specially designed for that purpose.

On my work site we have parallel projects on the same core application (1.5 millon lines of code in 2700 files), on which requisites are divided in releases, and while one part of the team is working in release X the other part is working on release X+1, and there are some dependencies and common libraries modified, and we have no problems merging those releases when needed.

If there is a need of a third branch to fix an important production bug, it is not a problem: just branch last release, make the fix, merge into trunk and merge into active releases to level them.

Mike's statement of his need for making changes in another branch to --may be-- merge in a future version or release, is a perfectly valid reason to do it.

Even I do it with my own developments for working on different enhancements, when not all of them are going to stay on next release.


On the other hand, the relation of this workflow with continuous integration, is that you can have fixed CI Projects por fixed branches, like "/main" or "trunk" or "Integration" branch, and can have any CI Project you need for particular branches that, in some point of time, can make his way to trunk, but meanwhile, you can test the quality of each development branch, so when this dev branch goes to trunk, the problems of integration are minimal.

The only needed thing to success in this workflow is that the "Integrator" knows about the developments, and there are many approaches for this.


Best Regards.-

aX4nf5Co16Q