Section 7.5.  Use Automation

7.5. Use Automation There are many tasks over the course of a software project that can be automated. Unit tests are a good example of automation before programmers started using automated unit tests, they had to manually verify each function and user interface element before delivering a build. By automating unit tests, the programmers were able to make them much less time-consuming tasks and, as a result, many more programmers take the time to build unit tests. But unit tests are not the only manual programming task that can be automated. Automation can ensure that the software is built the same way each time, that the team sees every change made to the software, and that the software is tested and reviewed in the same way every day so that no defects slip through or are introduced through human error. When projects become complex and require many steps to build, it's easy for programmers to forget a step. A programmer may build a version of the software that is missing a library, or is compiled with incorrect options. What's more, some programming teams have discovered that, as their build process becomes more and more complex, they have to dedicate more of a senior team member's time to generating new builds on a regular basis, which can cause delays in the project. Eventually, it becomes difficult for the team to even generate a reproducible build. When the build is delivered to users, there are often defects that can be traced back to missing libraries, or to required files that should have been included. There are many automated build tools that address all of the problems caused by an unpredictable and difficult-to-reproduce build process. Popular ones include: Make (which ships with most Unix-like operating systems and some IDEs) GNU Make (http://www.gnu.org/software/make) Apache Ant (http://ant.apache.org) Jam (http://www.perforce.com/jam/jam.html) Each of these tools automates a set of steps required to build the project. There are ways to ensure that dependencies are honored, so that a piece of code is only built after the tool first builds every library that it depends on. With an automated build tool, a programmer can cut a new build at any time and without extra input or interaction. The team can be sure that the software is built the same way each time and includes all of the necessary files and dependencies. One of the most important ways a software project can be automated is with a development monitoring system . Two of the most popular ones are CruiseControl (http://cruisecontrol.sourceforge.net) and TinderBox (http://www.mozilla.org/projects/tinderbox), both of which are free and open source. These tools allow a project team to construct a set of tasks to be run automatically on a schedule. These tasks include: Retrieving the latest build from the version control system, building it, copying it to a folder, and reporting any build warnings or errors Running automated unit tests, generating a test report, and reporting critical failures Running automated code review tools and reporting any warnings or rule violations Listing any changes that have been committed and by whom, including links to code listings for the changes Emailing results as text or visual reports (or sent via SMS text messages or some other communications system) These tasks can be configured to run on any chosen schedule. Many teams will schedule daily builds. Some will require builds on an hourly basis (or another schedule), while others will only require automated builds to kick off when changes are checked in. The important aspect of this is that the team can depend on these tasks being run the same way each time. They are kept aware of every change made to the code, and they are always aware of the health of the current build. If code is checked in that causes the build to break or important unit tests to fail, the team will know about it immediately and will be able to fix the problem early on, before any other changes are made. It is especially useful to combine the reports from a development monitoring system with code reviews. This is an especially common practice on successful open source projects, where every change or patch applied to the code is emailed to the developers and reviewed before it is incorporated into a production release.