Below is a list of the core principles that have defined the CI solutions that I have built over the last few years.
Use the lowest common denominator in technology for scripting
This has meant that the main workflows have been written in PowerShell rather than MSBuild or Nant as its more accessible, a terser language, can use .Net framework directly & debuggable.
I have seen too many systems that need loads of dependencies installed before you can run a build e.g. Using Ruby as a build language
Everything should be in source control
As a developer I want to install VS & SQL, get latest, build and go.
That means no “installed” dependencies, they all need to be mapped into the source tree or pulled in from Nuget
No build masters
The build should be something that everybody understands, can fix and improve
Team leads should be the custodians of a project build as they are the people that should have the big picture view of a project
You broke it you fix it
Exactly what it says on the box. It does not matter if its a code, unit test or build script failure. If you changed something that means the build has stopped working then you fix it.
Same build for local as remote
A lot of build systems hold the configuration on the server, I believe this to be wrong.
I want to be able to run the same build that’s on the server on my local machine before I commit
Everything the build server does should be available for me to me locally.
Dashboards & emails are great but a flashing light is better
The last system I built had a flashing tractor light and a USB Santa drumming Christmas tunes when the build was broken, makes things a little more fun!!!
The below books really shaped my attitude to CI and contain invaluable information.