Andre's Blog

Personal blog of Andre Perusse

Rules for Checking In Code to Source Control

The golden rule of checking in code is:

Don't check in code that will break the build.

Nobody likes code that won't compile. Also see Scott Hanselman's First Rule of Software Development.

In order to help verify that your pending check-in will continue to result in a healthy build, you may wish to view the following rules and procedures that I find helpful.

  1. Try to work on small chunks of code and features at any given time. As Tim Stall points out, "It's easier to integrate 5 small things than 1 big thing."

  2. Before checking in anything, perform a "get latest" on your entire solution's code-base. Resolve any version conflicts before proceeding.

  3. If you have any web sites in your solution that have references to web services, make sure you update all web references.

  4. Perform a build on your entire solution. Obviously, fix any compilation errors.

  5. Database scripts. Ahhh, these are lovely, aren't they? Unless you're fortunate enough to be using some cool database tools (like Visual Studio for Database Professionals), you don't likely have any compile-time error checking for your database scripts. It is essential that you ensure all your database scripts for changing the schema, updating the programming (e.g., stored procs), and inserting default foundation data work properly. If they don't, you'll soon have a swarm of angry developers beating down your door. The best way to do this is to run the update scripts on your machine and test the software. Update scripts should be written in such a way that they first check to see if a particular update has been applied first before trying to apply it again. This makes it much easier to test, and for other developers to apply to their database copies.

  6. Check in ALL files you have checked out. This is a tricky one, since perhaps you know that a particular file doesn't work properly, even though it will compile properly. Unfortunately, you may not know what dependencies exist on this file from some of the other files that you're checking in. So, while you may think you're doing a favour for the rest of your development team by not checking in a file you know to not work properly, you may actually be more causing grief by checking in code that won't build!

Even if you use a fancy-shmancy tool that performs delayed commit or source integration (such as TeamCity), as a professional developer you should really follow these guidelines to save yourself (and your team) pain and suffering.