In the book ‘automated delivery’ there is this controversial statement:
Thus one of the more controversial statements in Continuous Delivery is that you can’t do continuous integration and use branches.
However, with new systems like DVCS branching is incredibly easy so no branching? What is actually meant here?
 |
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) The bible on continuous delivery |
During a session on supporting multiple versions of our software application we got into the argument if we should create multiple copies of our system by using branches. Keeping multiple copies (in different branches) of your software is of course a totally different (even worse) statement then just ‘use branching’ as in a very short lived one day local version of the code.
The book gives the answer to that option of using copies for versioning already, but think about the consequences of that approach. For example if you have to fix a bug in one of the versions you probably need to copy that fix over to the other version branch, which in time might divert to a different direction altogether. Divert, because different versions of software always divert as you are supporting different clients.
Now, think about what would happen if you just have one application. Supporting multiple versions. The same software supports all the different clients that it needs to support. Your software might have different entry points.
– It can support multiple currencies.
– It can support multiple languages.
– It can supports multiple different frontends, that itself can have different pages
– It can support different workflows, wizards.
The software also supports different backends, like when you support a service for maintaining shopping baskets, over time you might have to integrate with different financial backends. How? By branching on abstraction.
That way, the software is highly configurable.
This would not have been possible if we would have different versioning branches for all of the possible config-switches / configurations to support all connectionted other software components.
We have one ‘pallet’ of options that is configurable. Having configurable software, switchable by settings makes integration flexible.
In the ever changing life cycle of software we can not maintain software in different versioning branches because bug-fixing would have to be done multiple times for each versioning branch.
So yes indeed: to support multiple versions that indeed will mean we have to support different versions and have multiple of the same kind of classes in the same codebranch indeed.
However, at some point in time, we discontinue support for an older version, and then we remove it again. From the same codebase.
Note that this has always been the case for the mid office software we are working on within my current company Travix. Last months we switched and deleted support as well as enabled support for connecting to several hotelproviders, carproviders or a flight provider. All with the same mid office servicelayer code. Simply put the codebase is highly configurable.
So when you read a statement from a book about ‘do not use branches’ this goes for branches in tools that have a central repository like TFS, SVN. Branching is to be done in the code itself; implement different behaviours by abstraction, use interfaces with different implementations. Make use of patterns like the strategy pattern. If you can do this well you eventually do not need branching and merging.
| |
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) The book is packed with information on getting your software on to continuous delivery. |