Discussions about branching often focus on the wrong thing. Unintegrated code sitting around slows teams down, whether the code is in a branch or in a developer’s workspace. Discussions about improving pace of development often veer into arguments about branching. Arguing about whether branches are good or bad will distract you from the more basic question of “Do changes get integrated and tested rapidly enough to ensure the rate of delivery we want?”
Integrating too slowly is the main challenge to agile development. Slow integration makes it harder to show incremental progress and maintain an always working code line with valuable features. Frequent integration helps the team deliver incrementally and maintain working software. Your process should help you to integrate quickly so that you can deliver value at a good pace.
The ideal integration frequency varies from team to team. Merging once a day is good, more frequently can be better, but too often can cause churn and overhead if you aren’t doing it well. Team and planning dynamics are key decision factors, but some things are universally true: small frequent commits improve reliability, changes that move the design forward are more valuable than trivial changes. These factors often lead to once a day as a good initial target, but each team needs to decide what values of “small” and “frequent” work for them. (Retrospectives are a good forum for exploring that question.) Automated testing is essential to moving quickly even though it can add a small increment of time to the commit interval in the short term.
Getting this to work well can be challenging, but it is doable. Small useful increments and effective tests are easier than many believe. Though you may need to change your mindset.
Branches and reviews can improve collaboration for both co-located and remote teams. So rather than starting with a “branch or not” conversation, start with an integration rate goal and evaluate how long it takes code to get into production. The next post will talk about why branching can have advantages for your team.
(This is adapted from an earlier Techwell article)
. In addition to the contributions about coding and design, I was pleasantly surprised to see the number of items that relate to release management. While I've long been interested in how to build architectures and processes that make deploying and releasing software easy, I sometimes get the impression that these items were often though of necessary evils that could be done at the end, often by the someone who isn't doing "more valuable work." Much like awareness of agile software development made it obvious that testing and quality assurance activities work best when they are integrated throughout the development lifecycle, agile has also made it more obvious why build and release engineering is something to work on as you go. This makes a lot of sense, as ease of release is closely tied to the physical architecture of the system, and your build process defines the physical architecture.
is a book that bridges the gap between tradition SCM and Release Engineering and Agile teams. Mario asked me to be a reviewer of the draft manuscript and I knew that Mario had great experience in establishing SCM processes in larger organizations, and that he was also a strong advocate of Agile methods. I was pleased to discover a book that, while being able to help those from a traditional release management background adapt their processes to support agile, also addresses the needs of those transitioning to agile who can benefit from using appropriate SCM processes to help them.
) this means that each Release Line has a maven version, and your Mainline is use to create the SNAPSHOT version of the next release artifact.
