Friday, April 25, 2014

Best Practices for Code Checkin

A stable build is important to a project, whether large or small scale. Stability means that the code builds, any unit tests run successfully, and you can navigate the program's critical path. Ideally, there should be no or few crashes. A lot of development time is wasted on debugging stability issues. Much of this could be prevented with a careful code check-in process.

As soon as you get to a stopping point where you can check-in, check-in! It's ok to check-in small parts of features incrementally. Software development is an iterative process, and your check-ins should be iterative as well. Don't wait until you have a lot of files changed to do your check-in - do it sooner rather than later!

You know how you press Ctrl-S all the time while coding (I know I do!)? Think of this as a Ctrl-S.

Why?
  • The more you check-in your working code, you keep a better baseline so if you do make a mistake, there's less backtracking to find out where you went wrong.
  • Less changes = less chance for bugs or build breaks
  • Better visibility to your team - your team can see where you're at with your feature development, which helps especially when they are doing work that is intertwined with your feature.

When it's time to check-in follow this process to minimize build breaks and bugs: 
  • Pull down latest code and merge, if necessary.
  • Go through each of your changed files and diff them against the repo. Check for:
    • Test code that was accidentally left in
    • Files that are actually unchanged
    • Wiping out someone else's work
    • Anything you do not mean to check-in
  • Build and test - someone may have checked something in that breaks your code, so it's important to test after getting latest. Also, test any features that may have been affected by your development, even if it's not the feature you were working on.
  • Run any unit tests set up for your project.
  • When you're confident everything builds and runs, check in. Make sure to be descriptive in your check-in notes. A month from now, when you're looking through the file history, you'll thank yourself! Your coworkers will thank you as well!
  • Don't leave! Make sure your check-in works. Check your automated build server to make sure the build passes. If you don't have an automated build server running for your project, get one! If you don't have time to verify your check-in, you do not have time to check in!