1. Thou shall not break the build.
To enforce this rule, all developers must install CruiseControl Notification Service (aka CC tray, very similar to GMail notification service). The status of the build is broadcasted live to all developers.
2. Thou shall fix the build if it is broken.
Very simple, if you break the build, you fix it. If you are not available to address the broken build, someone must be delegated in your place.
3. No going away (especially going home) immediately after checking-in.
After checking-in the code it would take few minutes for Cruise Control to trigger the build on the build box. When one checks in the code, he or she must verify that the continuous build success. If build is broken, the last one checking in the code is obligated to investigate the problem and fix it ASAP. If a proper fix is not possible in time, problematic code must be undone in TFS so that one can work on the solution offline without holding back the whole team.
4. No check-in while build is broken
Build will be broken sometimes. That’s ok. Someone will fix it! While the person is fixing it, let not complicate the problem with new check-in.
5. ZERO Compilation Warnings
Warnings are as good as Errors. All warnings must be eliminated! If not, they must be suppressed (i.e., masking) (provided there is strong reason for doing that).
6. FxCop is your friend! Do not fail him!
This static code analysis helps to enforce .NET coding standard. If the enforcement is too rigid, exception can be given on case by case basis.
7. Failed Automatic Test(s) = Broken Build
Automatic test is the First Line of Defence against Runtime and/or Logical Errors. So when test failed on Build Box, please follow Rule 1 and 2.
8. Regularly check-in code and retrieve the latest from TFS to minimise merging possibility
TFS can auto-merge if changes are well isolated enough. Otherwise, manual merging will be required and it can be time consuming.
9. Code check-in should be done against Work-item
It’s all about traceability and project progress tracking. By working against work-item, project tracking is automated by TFS.
10. When working in off-line mode (i.e., not connected to TFS), make sure to note down list of hijacked files (i.e., read-only files that were forced to writable)
Sometimes TFS is out of reach,(network down for example), temporarily working without the source control is OK provided that care is taken as recommended. Remember to synchronise with TFS as soon as connection becomes available.