One-Click Builds End-to-End

We want to automate the build so that it is easy to use. We wanted it to be so brain-dead simple to use that we use it all the time and we invoke the build whenever we make even a minor change to the system. This is how we get the most value from our build — when we use it all the time.

To facilitate this we have the idea of the one-click build, which means that you can invoke the entire process with a single click. We can set this up so that when we save a change it re-compiles all of its dependencies on the local machine and then runs tests on the local machine. If these tests pass the changes are pushed up into the build server and a more complete set of tests are run against it. All of this should happen automatically. Ideally, we want the build to run fast and that means anywhere from a few seconds to a few minutes.

There is even a program called N-Crunch that watches you type keystrokes and when you enter in an executable line of code it automatically invokes the build so you don't even have to do the single click to kick it off. N-Crunche is for .NET and there's an equivalent program for the Java world called Infinitest.

The build should run fast and give clear results. A lot of times when I'm developing I only want to invoke my local build until I have a feature ready for integration. I still try to build the smallest behavior that I can so that I can quickly verify it and move on.

Our compilers, lint checkers, automated unit tests and everything else that we use in the field are powerful tools that require compilable and/or executable code. We need to be running these tools frequently. I try to integrate the smallest pieces of functionality that I can so I use these tools often.

As a result, I have become somewhat addicted to the green bar. I like to see the green bar when I'm coding and very often if you ask me how I am doing I'll respond by saying, "Green bar!"

That's my way of saying all is good.

I remember I was at the office early in the morning on the project about five years ago. I like coming in early in the morning because there is no one there and I can get a lot of work done. Anyway, I'm sitting there and I run my tests and then I sit there for a while and run my tests again.

I didn't know it but one of my colleagues came in and was sitting behind me watching. He said that he saw me run my tests in green bar twice without making any changes to the code and asked me why I did that. He was concerned that perhaps I thought that the build was flaky and was giving intermittent results because running tests without making any changes shouldn't change the test results. I said that wasn't the issue. I said, "It just feels good."

I must admit that I love being in the green bar. The green bar means safety because I can freely refactor my code while I'm in the green bar and I know that if I make a mistake my tests will catch it. This is the value of having a good and reliable build that is invoked through a single click. It has your back, and what more could you ask for?

Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.