Top 10 Tips On Version Control for Small Agile Software Teams

Version control is a fundamental software management tool and process. If you're looking to setup a development environment for a startup, I highly recommend getting version control in place as a step 0. Even startups that have very few developers (even one!) will find long term benefits in having version control configured before development begins. In more established development teams, converting to version control can be more challenging because it often requires changes to existing development, build, and deployment processes. But if you keep things simple, then configuring and migrating even the largest teams is achievable in short time frames.

My simple tips:

1. Insure that your build process is applied to a working set of code. In other words, don't force developers to check in code prior to doing builds. Doing will likely cause developers to check in buggy code and cause issues with other developers.

2. You still want developers to check in code frequently. This is a management process, not a version control issue. If the tasks assigned to developers can be completed in a short duration, say two days max, then you can force developers to check in code when a task is complete. Scripts can be used to monitor the Repository for developers that have not checked in a defined period of time.

3. Backup your repository. Daily if not even more frequently.

4. Develop a simple nomenclature on what information should go into the comments/properties of a code checking. Best case - if you're working with SW requirements w/ ID's, then check in code with the IDs of the requirements (or bugs) that are being addressed.

5. Ask developers to do minor code reviews whenever they update their sandbox. See Simple Code Reviews Using Eclipse.

6. Tag your releases. If your staging a release, say through a QA process, then you can tag the release with a convention that includes the status (QA, PROD, etc.) and a version number for the release.

7. Whenever you cut a release to Production, archive the release and any executable builds. Although you can get the source straight from version control using the Tag, it's more convenient (especially for admins!) to have the releases archived in a folder outside of version control.

8. Make sure you have some form of release notes database (or spreadsheet) that lists the features/bugs with the release Tag and the date/time of the release.

9. Give developers the freedom to merge files. In most situations, merges are additive and the merges can be completed using tools. Even if the merge becomes complex, it's not a bad thing for developers to manage the issue by themselves via dialog and code review (tip #5).

10. Keep production parameters such as URLs, user names, passords, etc. outside of version control. Files with the production values for these resources should be managed by the Production team. The build process should have mechanisms to load in configuration files with these values.

A couple of things that you can avoid:

a) Don't worry so much about branching scenarios. In my experience, it's better to work out branching and merging branches when you're faced with that specific need.

b) Nightly builds are nice, but may be overkill for most teams. Understand why you need the nightly build and how you'll use it before scripting this out.


  1. Nice post. Have you ever read any of Damon Poole's stuff at his Agile Development Thoughts blog? He's CTO of Accurev and has some interesting thoughts on the subject of Agile, including his own Agile methodology, Hyper.


  2. Nightly builds may be overkill, but only if you are building frequently. I've heard first-hand of teams that build (on an isolated, non-development box) only once a week, or even once a month. These delayed builds rarely succeed without major human intervention, turning what should be a simple process into hours or days of scrambling, wasting valuable development hours on integration.

    Ideally a build would occur automatically whenever someone checks in code. If that's not feasible (because the build takes too long), there are some options:

    1. Make the build faster if you can. Optimize it like you would any other software issue -- fix the biggest bottleneck, retest, repeat until it's fast enough.

    2. Reduce your build process to a minimal set of tasks to verify the code. If you're working in a compiled language like C++ or Java, compile the code. If you're doing any unit testing, automate the tests. Things that change less frequently, like install/deployment scripts, may not need to be exercised as frequently.

    3. If you've optimized and reduced as much as you can and it's still not fast enough to build at every checkin, build at frequent intervals throughout the day. Every 10 minutes, every hour, every 4 hours. The more frequently the better.

    It's also important to note that a broken build is not the end of the world (at least you know the system works!) but it should be fixed ASAP. No one should check out or check into a repository that can't be built, and development more or less halts until the build is fixed. If you're integrating and building continuously, most build issues are relatively easy and quick to fix ("oh, I forgot to add this new file...").

  3. Great points Jeremy. The key phrase is "may be overkill". Automating a nightly build in many SW environments shouldn't be that difficult... But it's only worthwhile if there is a purpose to it.

    One good reason is if you have someone in QA working directly in the QA process. Agile dev teams should have a QA resource as part of the core team. If they audit the check in list and match them to the requirements, they can validate the check-ins via the nightly build.

  4. I'll agree with Jeremy. We just had a team that was very proud that they wrestled our build group into providing them a build once a week. This is horrifying to me... we run daily and want more.

    In the general sense, if it's really that hard to run every night, it's probably hard for developers to run as frequently as they need to. It's a pretty good indicator that you need to take a serious look at either your BRM practices and/or your project structure.

  5. I hope no one thinks, and that the author was not implying, that waiting two days to check-in changes is sufficient. Even a short two day task should have several check-ins.

    I don't agree with "Keep production parameters such as URLs, user names, passords, etc. outside of version control." Everything, including binaries used and generated, scripts and configuration files must be under source control. How else are you going to be able to exactly recreate a release?

    A branching strategy is imperative (if you expect to use branching at all). Branching done right is hard enough, branching done wrong is probably worse than no branching. You better be clear with your developers what branching is, when it should be used, and how to do it. Waiting until a developer decides they need it will just lead to confusion, inconsistency and a mess in the repository.

    I highly recommend the book "Software Configuration Management Patterns: Effective Teamwork, Practical Integration".


Comments on this blog are moderated and we do not accept comments that have links to other websites.