Refreshments and sandwiches from 18:00.
My adventure with source code management
Or, How I learned to stop worrying and love the merge
This is the story of how my colleagues and I revised our approach to managing source code for a large software product; we make 1-3 major product releases each year, so that most of the time we have 6-10 supported versions of the product, each separated by several thousand person-days of development effort. Our customers prefer not to upgrade too often, generally only every 2-3 years, so although we try to avoid it, we often have to retrofit new features (legislative changes) into older releases.
I’ll present the approach that we devised in an attempt to streamline the flow of changes between releases, how we tried to address the problems caused by refactoring or technology changes between them. I’ll explain how we tried to introduce a development model that would better support incremental enhancements (Continuous Delivery) and ease a number of other bottlenecks in our organisation, and how we found ourselves advocating Feature Branches just as industry best practice seems to be discouraging them.
To be honest, we’re still learning - a more accurate subtitle should be “how we hoped to stop worrying and tried to love the merge”. We devised a new way to draw branching diagrams, changed our policy for retrofits, and tried a new model, and it hasn’t worked… yet…
It is a case study that embraces topics like
- How to choose the best SCM tool for your organisation (SVN vs Git)?
- Feature branches vs. continuous integration
- Clean vs. “dirty” code lines
- A deeper understanding of continuous integration/continuous delivery (or do we all mean the same thing?)
- Where should you apply your automated regression tests?
We have been on a quest for best practice - we’re asking big questions, so is it really all that surprising to find that one-size-fits-all answers are a bit thin on the ground.
Graeme Macfarlane has spent 30 years in software development, a journey that began in research then moved into industrial process control, and then into publishing business information on CDs, and then online during the “dot com” boom. For the last 11 years he was worked for aquilaheywood, market-leader in life and pensions administration systems, in a variety of technical management roles. In his current role as Group Chief Architect he has responsibility for technical product strategy and takes a particular interest in the software process, enterprise architecture, systems integration, test automation, performance test and assurance.