I’ve been running this check in procedure for several years with my development teams. The intention here is for developers to get their code into an acceptable state before submitting it to source control. It attempts to avoid some classic bad habits around source control, such as:

• Check in changes at the end of each day
• Missing changeset comments
• Using the build system as point of compiler/quality validation
• Big bang changesets
• Cross purpose changesets

Changeset Contents

Changesets need to be related to a particular set of related changes. A changeset should not include changes or functionality from unrelated pieces of work. This makes reviewing changesets and work tracking very difficult. If you do need to work on unrelated pieces of work, shelve the prior work (undoing local changes) and start working on the new piece of work. Once a piece of work is checked in according to the procedure below, the previous shelveset can be brought back down to your local workspace and you can continue to work on it.

Check In Procedure

The following set of actions must be taken in order to check in changes to source control.

1. Pre- Check-in
   • Code is functioning correctly and to spec.
   • All code comments are correct and well formatted
   • Code has been cleaned up and is consistent to team standards
2. Run get latest on the solution
   • Fix any merge issues
3. Undo any files that haven’t changed - see Quick tip for undoing unchanged TFS checkouts
4. Switch to Release build
5. Rebuild solution (not just build)
   • Fix any compilation errors
   • Fix any compilation warnings that can be addressed
6. Deploy database projects to local machine as required
7. Run all tests
   • They must all pass
8. Write a comment that describes the changeset
9. Assign a work item to the changeset
10. Raise a code review request if the changeset contains code changes
    • Minor changesets that do not change code or have any functional change do not require a review
11. Verify that no other check ins have occurred since doing #1
12. Check in
13. Wait for build to complete (you can do other work during this process)
    • Verify build successful or investigate any failures