Branchageddon DevOps anti-pattern
Mark Wheeler
How do you avoid a branchageddon situation when working with large organisations?
We work with a number of large financial organisations whose approach is to not take updates to software, but instead only high/critical security patches and bespoke functionality. These organisations will only take patches and custom release in between major updates. Major updates can be years apart and carry high costs. This approach causes us (the software house) to have a branch of our code per major customer, which carries all the costs and inefficiencies of long term branching.
My interpretation of Jez Humble's Continuous Delivery book is that it promotes development on trunk and short lived branches at the worst. Branches existing for years is an unpalatable thought for a team aspiring to adopt DevOps principles and practice.
My questions to this group are:
• Have you experienced similar update acceptance approaches from your customers?
• What suggestions do you have to help work with this approach?
• What suggestions do you have to help change organisations approaches to taking regular software updates?
Thierry de Pauw
- They only maintained 2 major releases: N and N-1. N is developed on mainline, N-1 is maintained on his release branch. N-1 was only kept alive for a year after N has been released. For example if your software is currently at version 5.3. Next month your company releases a new major version of the software: version 6. From the moment version 6 comes out, the 5 branch will only live for another 12 months.
- Every month a new minor release came out of the current major release. In our example every month we had a 6.x release. If important bugs or security patches had to be done on the N-1 release, they got planned for the next upcoming month. This means every month we had a new 6.x release. But it could be that some months there were no 5.x releases.
- A clear communication about this release strategy existed towards the customers. This is very important. Customers knew this the moment they bought the product.
- If customers reported bugs in older versions (other than the current maintained versions) they were gently asked to upgrade to the latest version where the problem was already fixed.
- As much as possible fixes to the 5.x release are performed (if possible) on mainline and cherry picked into the 5.x release branch. If that was not possible fixes are performed on the 5.x release branch and have to be replicated on mainline.