Build Server Best Practices

Question

I heard google has some automated process like that:

• When you check in, your code is checked into a temporary location.
• It is built.
• Style checks run.
• Tests run.
• If there are no problems, code goes to actual repository.
• You receive an e - mail containing test results, performance graphs, style check results and whether your code is checked in.

So if you want to learn if you broke something or the great performance gain you expected occurred, you just check in and receive an e - mail telling you what you need to know.

What are your favorite build server best practices?

Answer 1

What you described for google is what every basic build process does. Specific projects may have additional needs, for example - how we deploy web applications from staging to production:

• Build start
• Live site is taken offline (Apache redirects to different directory holding an "Under construction" page)
• SVN update is ran for production server
• Database schema deltas are ran
• Tests are ran against updated source and schema
• In case of fail: rollback is ran (SVN revert and database schema UNDO)
• Site gets back online
• Build ends

Answer 2

On the java platform I have tried every single major CI system there is. My tip is that paying for a commercially supported solution has been the cheapest build system I've ever seen. These things take time to maintain, support and troubleshoot. Especially with a heavy load of builds running all the time.

Answer 3

We installed TeamCity (free) for CI and were up and running in a few hours. Definitely a good use of our time.

Answer 4

The example workflow you give is similar to the one proposed by TeamCity. The idea being:

1. Code
2. Check in to "pre-test"
3. CI server tests the "pre-commit"
4. If (and only if) tests pass, the CI server commits the code change to the main repo

It's a religious war but I prefer:

1. Code - Test - Refactor (loop)
2. Commit
3. CI server also validates your commit

Every responsible programmer should run all the tests before committing.

The main argument for the first way is that it gurantees that there is no broken code in SCM. However, I would argue that:

• You should trust your developers to test before committing
• If tests take to long, the problem is your slow tests, not the workflow
• Developers are keen to keep tests fast
• Relying on CI server to run tests give you false sense of security