In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Effective peer reviews will eliminate a significant percentage of potential build problems, while at the same time helping to ensure that the architecture remains solid. It's important to have a good peer reivew process, but also a key developer involved, one who understands the architecture and and the wider issues involved. Peer reviews are most effective when they become a teaching tool—it's critical that new developers are aware of this going in.
Your process should not allow code to be checked in unless it has been tested. One of the most effective ways to ensure this is to track the test scripts, whether automated or manual, against the change, along with the test results. These should be reviewed as part of the peer review process. Another key practice is to include a demo as part of the peer review
Finally, it's important that there is control over what is going to go into a build. High-impact and high-risk changes should be accepted early in the process, before the full team begins working on the release cycle. Tight control must be exercised as release dates approach. It's fine to have a developer who can fix thirty problems a week, but if those are all low-priority problems and we're nearing in on the release date, the result may not be desireable. Typically, somewhere between 10 percent and 30 percent of problem fixes will introduce undesireable side effects. If only five of the problems really needed to be fixed for the release, there's a much better chance of not having a severe problem resulting. Still, if it's earlier in the release cycle, there's time to absorb such side effects and fix the problems before they go out the door.
When you're controlling what goes into a build, it is really ineffective to do so at build time. This will likely create a minor revolt among the developers, who have worked hard to complete their work. Instead, you want to ensure that change control is starting prior to assignment of changes to the design team members. Ideally, developers begin work by selecting tasks, problems, or features that have been approved and assigned to them. Then, there's no rejection of unwanted functionality or problem fixes.
Perhaps an even more critical side effect of having a change control process up front is that work flows from the developer through the process and into integration in pretty much the same order. This reduces the need for rollbacks, branches, and merges, and allows you to adopt a more optimized promotion scheme, ideally one where you don't even need to create separate promotion branches. This in turn makes it easier to automate selection of changes, as pre-approved changes can flow through the system as soon as they are successfully peer reviewed.
Manage the Superset Baseline, Build Subsets
Many organizations create and manage a baseline for every build. While this provides for full reproducibility, managing a large number of baselines can be complex. Typically a product has a number of variants. While it is important to try to move variant configuration into run-time or at least deployment, there are a number of cases where this is not or can not be done. In this case, the best strategy is to manage a superset from a baseline perspective, while building subsets. It's natural to configure a product from a subset of the baseline. Instead of dozens of baselines, a single baseline is used for management and reference purposes. Each build can be customized, as long as the CM tool tracks the build definition in terms of the baseline.