These are the fundamental rules I use when managing a source tree. To many these are a given, but others don’t know these things.
- There must be an automated build.
- If you break the build, fix it.
- Building the code must be trivial.
- The code should run from the source tree, with no installation steps required.
- Creating a new build machine be as easy as following the document you wrote saying how to do it.
- Things needed to build the code aside from the contents of the source tree must be minimal and well documented. Ideally, this is nothing more than your compiler and your build system.
- Source control is for source code. Checking in binaries is allowed only in the pursuit of #4, or when said binaries are a critical part of the software itself. Even then, tread carefully.
- If you can choose between a binary and textual representation for a source file, use text. Consider this when choosing your tools. (WiX good, InstallShield BAD)
- It must be trivial for developers to run the unit tests in the same way the automated build does.
- Be considerate. Think about your fellow developer.
My project is pretty good on this list, I think we’re at 7.5/10. I’ve had major headaches enforcing #7, to my great disappointment. And number 8 is a continuing struggle. We’ll get there, hopefully. The half point is from #10 – turns out it’s hard to create a culture of mindfulness out of nothing.
What’s the score on your project? Are you working any of these things?
Russell Mull 
Do you read Hacknot? The most recent article there (“If They Come, How Will They Build It?”) takes a lot more words to say essentially the same thing you accomplish with ten rules.
agree.
its time consuming setting all this up as a single developer…. but since i work in a large organization there is a dedicated person managing multiple programs.
now if i can only bring them home from work to setup my personnel projects correctly
“Continuous Integration” – Martin Fowler
– lm