Many agile development teams struggle with the concept of delivering shippable software at the end of every iteration — that’s every 1 or 2 weeks in many cases. Many agile experts advocate keeping stories brief. That’s a good idea, and I’ve advocated it myself, but it’s not enough.
There are times when 1-2 weeks or even 3-4 weeks is just not enough time to make a major structural change to the software. Such changes are often needed to accommodate unforeseen functionality or to accommodate a heavier load (more users and/or more data) than predicted.
This is where good software configuration management (SCM) practices come in.
Every enterprise-level project requires a quality SCM tool and a good set of guidelines for using the tool effectively. You’ll need parallel software development paths at some point. You may even need three or four such paths for a large and complex application.
Here are some guidelines to get you started:
- Select a good SCM tool. There are many open source and commercial packages available. Consider these open-source options.
- Developers should create and manage workspaces either for personal use or for use by a very small group. Don’t allow source files to be scattered around randomly.
- Check-ins should be frequent to stay in sync with the team. Some developers will avoid check-in until they believe their code is complete. That’s not agile.
- Establish a trunk and set policies for its use. Recognize that over time, there may be more than a single trunk. (For example, this would occur if you start out developing in Microsoft .Net and later decide to re-write the entire application using AJAX.) Each trunk will have branches.
- Create branches as needed but try to limit them. Major revisions are typically branched so the team can support them independently. Minor revisions often don’t require branches simply because trying to support too many revisions at once is a major challenge.
- Merge often. Changes to branches in active use must be merged so that defects don’t re-appear in a future release. The longer you put it off, the more complex it will be.
- Create a disciplined build procedure backed by quality build tools — and build often. Some teams build multiple times each day. Breaking the build is a major fauz pas.
- Track changes. A major benefit of having a good SCM package is the ability to keep track of what changed in every release. If something goes wrong in the field, you can trace back and determine how it started.
- Have an owner for every trunk, branch, code segment and procedure. Good SCM practices are not easy so you’ll need oversight.
- Make the whole process agile. Design it for change. Keep fine tuning to make the SCM efforts as fast and simple as you can.
Perforce Software has a more in-depth article on the subject of SCM best practices. It is worth reading.
Very informative tip provided…thanks. Here’s to read more on software configuration management. Yes, Configuration management softwares are very helpful in managing and organising changes in any organisation. Hence reducing & minimises disruption to the business by restoring service operation to agreed levels very quickly.