I want you to make it so easy to build software that it becomes invisible to you. You should be able to launch the build with a single click of the mouse.
Slow tests are the number one reason builds are slow, but there are techniques to make tests run much, much faster. Builds should take less than ten minutes to run. This is actually something James Shore and Shane Warden say in their book The Art of Agile Development [SW07]. But I think even ten minutes is pushing it.
For local builds, I like to see them run in just a second or two and when I promote to the build server I like builds to happen in just a few minutes, though it depends on the nature of what I’m building and how big it is. Some builds actually do require several hours. But you don’t always have to do a full build of your entire system when you make one small change if your system is correctly decoupled.
When builds take over ten minutes to run, they’re run less frequently. If that’s happening, find the dependencies for the specific modules that are being worked on and only test those modules.
This will speed up builds, but what will really speed up builds is to write good unit tests and only test code that needs to be tested, not other code that code might use—and fear not, we’ll talk about this in Chapter 10, Practice 6: Write the Test First and Chapter 11, Practice 7: Specify Behaviors with Tests.
Understanding the dependencies related to making changes into a system is very helpful not only for identifying what module should be compiled and what test should be run but also because it helps segregate the system, making it easier to deploy and extend. The build should happen on the developer’s local machine first. When everything works there, it gets promoted up to the build server. The build should be able to work even when the Internet connection goes down so that developers can continue to be productive even while there are problems with the network.
There are tools for Java, .NET, and other environments designed to automate builds. When a local build on a developer’s machine is successful, and all the tests pass, it should automatically get committed to version control. This triggers the build server to run. Once the new code is compiled, tests should automatically be run to verify that those changes don’t affect other parts of the system. Tests that take too long to run can move to a nightly build.
When code is simple its tests are also simple. We want to test as much as we can against simple units of behavior rather than complex ones so we can have as few bigger integration tests as possible.
With all the various techniques for speeding up unit tests, if we’re testing our code in the correct way we can have thousands of unit tests run in under a second.
If the build breaks it not only holds up the developer who broke it but everyone else working on the project, so it’s imperative that broken builds be fixed immediately. It’s typically the responsibility of the developer who introduced the code that broke the build to either roll back the code or fix it.
Several years ago, I went to visit a friend of mine who works at a development shop that practiced Extreme Programming. Their walls are covered with team agreements and task boards and every station has two monitors, two keyboards, two mice, and one computer so two developers can work together and pair program. The sight almost brought tears to my eyes, especially since I knew the team was wildly successful. Then I noticed some pretty heavy-duty hardware in the corner with one of those red flashing lights and a firefighter’s helmet sitting on top of it. I asked my friend what that was and he said it was the build server for the team. Then he grabbed the keyboard and said, “Let me show you what happens when the build breaks.”
He went in and changed some code in the system to force the build to break—and all the fluorescent lights went out in the building, a siren started to go off, and the red light started to flash.
He said, “Broken builds are not allowed in our shop.”
The moment a build breaks everyone is aware of it, and the developer who broke the build has to go to the build server, put on the firefighter’s helmet, sit down at the terminal, and fix it right then and there. A working build is fully ingrained into their culture, and they’ve come to depend on it so much every developer needs the working build to do any of their work.
It always has to be up and running.