Handling Change In the Platform
Changes in your core platform are inevitable over time, but they don't have to be "harbingers of doom." Making the change a success, for the team and your build process, comes down to how you decide to handle the change. For instance, you may decide to pass up a couple of point releases of the .NET Framework (or Java JDK) to avoid instability or new engineering hours in the build process. Gauge how this sits with other stakeholders. Are they disappointed? Does skipping this upgrade hold up their development roadmap? Are they angry? These are activities that can't be settled easily via e-mail and require face-to-face interaction. Be proactive about gathering these details because the effect can be significant.
A platform upgrade in my environment from the .NET 1.1 Framework to the .NET 3.5 Framework was planned over a number of related product releases, with the first release still on .NET 1.1. This can feel like shell shock to those responsible for the build and source management. Two versions of the source must be maintained for a period of time without interfering with each other and be built with different compilers.
To accomplish this, create a new branch from your source code's trunk for the first release. Then upgrade the trunk source code to the targeted platform version. You can now place one team on the old version and another team on the upgraded version. Once the release on the old version is complete, you can reverse merge those changes back into the trunk (see Figure 4). Be careful not to perform the platform upgrade on a development branch; that is, an open invitation to branch on a branch, which gets unruly quickly and is always best avoided. The branch -> upgrade -> release -> merge process is a prime example of the branch isolation advantage in the wild. It also provides a baseline of the code before the upgrade, allowing an easily identifiable rollback path.
Making similar platform accommodations garners support and respect for the build process.
Human Factors: Managing Fear
Underemphasizing the social challenges of software engineering can sound appealing but can produce additional work, or failure, in the future. The changes described here are always possible—there are simply consequences to deal with. The most prominent one that I have experienced is fear.
The business stakeholder fears a development slow down if the source-code repository is changed and a build process is installed. These folks have goals they are trying to achieve via the development teams' output. Software configuration management, build engineering especially, puts these goals at risk—or at least appears to. Your job is to point out the great advantages of the new processes, so education is key. Explaining exactly what the branching strategy is and how concurrent development will make more releases of a higher quality possible helps change the attitude towards the work.
Development management may seem like an easy win, but that's not always the case. If your team hasn't had a structured build and release process in the past (and your systems are functional), the need for the large investment of time and resources may not make sense to them. The education here is different than for business stakeholders. Present these advantages to your team:
- Maintenance of code is easier because of project isolation.
- Bug fixes are quick to deploy because the source repository is clean and consistent.
- Continuous integration keeps the product in a deployable state.
- Release branches provide the ability to do hot fixes on released code without effecting current development.
These are all big wins and make management look good.
The last, and toughest, audience that needs education are software developers themselves. If development management seemed like one that should be easy, the development team can be even more averse to change. This is because your everyday developer is not simply talking about projects and ship dates. They are hacking the software out line-by-line, feature-by-feature. Causing big waves here can sink your efforts before their next release. Fortunately, this is overcome by helping individual developers change their habits. If you have a mid-size to large team, choose one or two developers to represent the new process. Teach them how to work within the new branches, environments, and the continuous integration dashboard before you educate the rest of the team. This way, you have some advocates on the inside.
