This book has described many tools and techniques. By now you are probably wondering what is the best place to start and how you can implement these techniques in your environment. This section offers some suggestions, starting with your SCM environment.
Start with a Strong Base
The order of the chapters in this book is no coincidence. You no doubt have noticed that the first chapters described the SCM environment and, in particular, the configuration of ClearCase to best support the software build and release process. This was reinforced throughout the remaining chapters by illustrating how SCM labels, baselines, branches, and streams can be used to ensure traceability or isolation of the build or release. One of the first things you should do to create an effective SCM environment is make sure you have drawn up an SCM plan. Such a plan does not necessarily have to be a tome (unless you are required to prove some adherence to a software process standard such as CMMI or SPICE). Rather, it needs to effectively convey the following information:
Although the definition of a lot of this information might seem like overkill for defining a build or release process, it is very difficult to construct a reliable and automated build process without it. For example, if the project's baselines and streams are not created according to a convention, how can you automate their creation or hook into them for further automation? For more information on SCM plans, see Haas [Haas02] or Wahli, Brown, Teinonen, and Trulsson [Wahli04].
Automate Only What You Need To
There is a common misconception in software development that automation is good and everything that possibly can be automated should be. Well, this is true to a degree. Certainly this book has looked at how many aspects of the software build and release process can be automated. However, automating everything takes time. You need to ask yourself how often the task that you will automate will be run. If it will be run 100 times, the effort of automating it is worth it. However, if it will be run just two or three times, is the investment in automation really worth it?
It takes time to build up your automated process, so you need to identify the areas where automation is typically first needed. This depends on which phase of development you are in, as illustrated in Figure 12.4. Usually automation is first needed in the compilation, integration, and unit testing processes, which are relied on heavily during initial active development. An early adoption of automated Ant build scripts driven by CruiseControl can certainly provide significant benefits. Once you have managed to automate this part of the process, you can move on to other activities, such as automating the generation of baselines, change request reports, or release packages.
Figure 12.4. Project automation steps
Finally, just because everything can be automated and initiated by a tool such as Cruise Control, this doesn't mean you have to or should. There might be areas where you want to do things manually. The example I have referred to throughout the book has been the generation of the final release for deployment to the user acceptance testing (UAT) or production environments (or the golden master to create the distribution medium). There is no reason why this release couldn't be generated automatically by CruiseControl, but I prefer a separation of concerns and to have a known, stable environment under which I initiate the construction of a Release Build.
Find Your Project Rhythm
One of the most important decisions you will make on your project is how often you will create an Integration or Release Build. To some degree your release schedule will be defined by project and customer expectations. However, internal to the project you will have greater control over how changes are integrated and on what schedule. There is no predefined schedule; you need to find the "project rhythm" that suits you best, typically by looking at patterns such as how long the build takes, how often developers can sensibly deliver, and so on. If you are adopting a continuous integration approach, this can mean building many times a daymaybe every 20 minutes or every hour. With more traditional forms of development this can mean building once a day (maybe as part of a nightly build).
Your project rhythm also is determined by any dependencies that exist between components or projects and how long the build process takes from beginning to end. Here are some questions you can ask to help determine your project rhythm:
This is not an exhaustive list of questions, but it should be enough to help you determine the setup of your initial automated build and release environment. The next section answers some of these questions in the context of a working example.
One important point to note is that any one project might have multiple frequencies, typically one for each scale of integration or type of build. In Figure 12.5, as the scale of integration progresses, builds are carried out less frequently. Normally this is because each kind of build has a different type and level of visibility, and hence a more appropriate frequency to go with it, as illustrated in Table 12.1.
Figure 12.5. Build frequencies
As Table 12.1 shows, each type and scale of build has a direct consumer, and the consumer needs to be involved in deciding what the build frequency is. It should be as frequent as possible, but it may also be subject to constraints within the consumer's tolerance level. For example, System Release Management might not be able to tolerate a build each day for each component, or customers might not be able to easily accept a new release as often as monthly or even quarterly without significantly disrupting their environment. The important thing is to plan and identify when the different types of builds will typically happen in your own environment.
When you have fun in your work, I believe you will be more productive. This is certainly true for me. Having an automated build process that constantly updates the development team on the progress of your builds is one way of achieving this. People like to see successful progression, and seeing working build after working build is a good indicator of success.
Out of the box, you can use CruiseControl to send e-mails to indicate build success or failure. However, some development teams have been more imaginative and actually linked CruiseControl to visual indicators such as flashing lights or even lava lamps (see [Clark04] for more information). Unfortunately, I can't guarantee that you will have fun on your project. But if you take away a lot of the drudgery of manual and error-prone tasks through automation, you will certainly be starting to create the right environment for it.