Merge is Release August 31, 2011at22:28
“A small part of me dies on every release”
A colleague wrote the above statement on the white board in the war-room today after working close to half a day with an internal release of source code meant for the other dev-teams working on the same project. When it takes almost four hours to do an internal release, a manual process that often goes wrong and has to be mended or redone, then it is something terribly wrong with the procedure.
Release should be as easy as Merge
Any new feature should be developed on a separate feature branch. Once the code is in place, it compiles, all unit- and function-tests pass, no lint warnings, no doxygen warnings, no code duplication and the code is peer reviewed; then you merge back to main/trunk. The merge should be close to trivial since the application you are writing are well partitioned, abide to the SOLID principles. (especially to OCP – open closed principle**) and each feature is small and distinctive enough so that you finish within a few days.
We do all that, or pretty close to it. The problem is not our coding practice –at least not in this instance. The problem is the version control system and the release process. I’m too embarrassed about the actual system in place so I won’t go into details. Lets just conclude that it is awful.
If your release process is any more complicated than a merge, than you are doing something wrong.
** If you are not familiar with the SOLID-principles or specifically the Open Closed Principle, please read this blog-post. Also stay tuned; future posts will discuss the individual principles behind the acronym.