Don't Break The Trunk |
 |
 |
 |
| Written by Graham Stoney | |||
|
Virtually all software development processes and source code control systems have a notion of a “trunk” and a “branch”. Most of the work goes on on the trunk. The trunk should represent the main development work and have monotonically increasing functionality. It should be considered sacrosanct. At the very least, the version at the head of the trunk should always build, and ideally it should never regress. If a major change involving multiple developers is in the works, it should be done on a branch until such time as it passes all the regression tests that the trunk passes, and then at some point it should be merged onto the trunk. This help a development team function efficiently because it reduces the amount that developers need to know about the state of other work which isn't directly relevant to them. You no longer need to send emails to each other saying “it's OK to check out the trunk now” or “hold off on committing because the trunk doesn't build”. When developers can always assume that the version at the head of the trunk represents the latest and greatest version in existence, life gets a lot easier than if mainline development proceeds in stops and starts, or heads off on some branch never to return. You need a good tool and process for this to work, of course. In some organisations, if a developer checks in code on the trunk that doesn't build, they get chosen as the release manager for the next release. This isn't just a punitive action, it also helps raise awareness of why it is important that the trunk always builds. If you're following the rest of my suggestions about not breaking the trunk, automating the build process, doing nightly builds, running regression tests, and automating your release procedure, preparing a software release should be relatively painless. Social Bookmark this page:         
|