| The field of software development is littered with acronyms and definitions, and Software Build and Release Management is no exception. Therefore, it is important that you understand the difference between types of builds, the difference between builds and releases, and the processes that construct them. This section tackles this issue by defining the terms I use and the processes I will be seeking to automate. I will also position where Software Build and Release Management sits in the complete software development life cycle. What's in a Name? Definitions Everyone seems to use the term build in software development, but, if asked, most people would have difficulty defining it. Sometimes the terms build and release are used interchangeably. Even more confusing, these terms are used not only as nouns, but also as verbs. You can "release a build" or "build a release." For the uninitiated, this could be confusing. To find some clarity, let's consult the Rational Unified Process (RUP) [Kruchten03], which defines a build as follows: An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product. OK, that's a start. What the RUP is defining here is that a build is something that can potentially be executed and that contains a discrete level of functionality. Of course, execution here does not mean that the build results in a complete application ready for installation and testing; it might simply mean the creation of a single system library. The important thing is that you could do something with the buildwith the library it might be running some unit tests. Obviously, this assumes that the build actually completes. To further refine this definition of a build, I also refer to Berczuk and Appleton's book, Software Configuration Management Patterns [Berczuk02], and their additional paper with Konieczka, "Build Management for an Agile Team" [BerczukBM], where they break down the definition of build into three distinct patterns: Private Build A build that is created by a developer in his or her own workspace. This type of build is usually created for the purpose of checking the ongoing status of the developer's changes, such as to assess whether his or her source code compiles. Integration Build A build that is carried out by an assigned integrator or central function. This type of build can be performed manually by a lead developer or a member of the build team, or alternatively through an automatically scheduled program or service. This build is created to assess the effect of integrating a set of changes across a development team. Release Build A build that is carried out by a central function, usually a member of the build team. This build is created with the express intention of being delivered to a customer, either internal or external. A release build is usually created in an isolated and controlled environment.
One important point to note is that although three explicit patterns are defined here, this does not mean that each type of build should be constructed in an entirely different manner. In fact, I recommend that the same set of build scripts be utilized, irrespective of by whom and for what reason the build is being carried out. In this way, errors with the build scripts are identified early onduring development or integration time, not when you are just about to make a release. I use this concept of maintaining a central build script throughout this book. Also, there might be variations on these patterns. For example, integration can occur at a number of distinct stages. You might have component integration, where you integrate the code for a single component, or system integration, where you integrate multiple components, some of which have possibly already been built. Speaking of making a release, let's turn our attention to its definition. The Rational Unified Process defines a release as follows: ...a stable, executable version of product, together with any artifacts necessary to use this release, such as release notes or installation instructions. A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. The important aspect of this definition is that a release is constructed and handed over for evaluation or installation by a third party: the quality assurance (QA) team, the test team, or eventually the external customer. Consequently, a release needs to be packaged and made ready for installation, together with all its associated artifacts. It also needs to be possible to identify exactly what is in the release in terms of new features, enhancements, or defects that have been addressed. The customer usually wants to know why he should take a new release. After all, he might think the one he has works fine! As you can see, this maps directly to Berczuk and Appleton's definition of a release build. What all this means is that a release is a special type of build for which there is a significant investment in effort and additional processes that need to be carried out. I discuss these processes next and in more detail in Chapters 10 and 11. How It All Comes Together: Process Now that the terms build and release have been defined, let's consider the process that generates themSoftware Build and Release Management. Most if not all software builds are usually created during the Implementation work flow of a project, when coding and unit testing are under way. Figure 1.1 illustrates how the Implementation work flow is positioned relative to the other work flows of a typical iterative or incremental software development process. Figure 1.1. Typical iterative software development life cycle (from the Rational Unified Process) 
Note that it is unimportant whether the software development life cycle is iterative, incremental, or traditional waterfall. The point is that Software Build and Release Management is of no value in its own right but is part of a greater process. The center of Figure 1.1 shows two supporting work flows: Environment and Software Configuration Management (SCM). Software Build and Release Management is actually part of SCM. It is also very closely dependent on the environmentthe development languages, supporting tools, and associated hardware that are to be used. Software Configuration Management is the "unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components, and products during the life of a system" [Haas02]. It includes all aspects of version control, change control, workspace management, support for parallel development, and process control. SCM definitions are always a bit dry, but put simply, without the ability to identify versions and collectively baseline them, without change control to identify and authorize content, and without a suitable process to guide or enforce, how can you possibly hope to be able to construct builds and releases? The Software Configuration Management Solution Perspective This book focuses on the Configuration and Change Management of software applications (SCM). Since the aim of this book is to enable process automation through the adoption of suitable tools, another relevant definition of SCM is the solution perspectivewhat aspects of SCM support a tool can offer. The general consensus is that SCM tools can support five functional areas: Version Control Enables the secure and controlled storage, retrieval, and versioning of all project assets (source code, documentation, test results, and so on). Build Management Enables the consistent and reliable construction of software applications in as short a time as possible. Workspace Management Enables the creation of workspaces to give project members access to a project's shared versions of assets and consequently support for parallel development and controlled integration. Change Control Lets you capture, track, and manage all types of project changes (requests for change, enhancements, and defects). It also lets you compare these changes to the versions of the project assets used to implement them. Process Control Lets you report actions, history, and milestones, as well as customize or enforce development work flow and procedures.
I will make use of each of these functional areas at various times throughout this book. |
Software Build and Release Management has quite a few different aspects. Because the aim of this book is to automate the process, let's break things down into a little more detail. A Bit More on Software Build Management Essentially, the purpose of the Software Build Management process is to make sure that every build is complete, consistent, and reproducible. You should always know what you're building and why you're building it, and you should be able to build it again at any future point in time. If you can get this right, you are on your way to being much more productive, as well as having time to concentrate on other, more important things, such as developing code! The Build Management process can be broken into several distinct stages: Build Identification What to build. Build Identification can be either an informal process, in which you build just the latest changes, or a formal process, in which you build only agreed-on and complete changes. Typically, during initial coding and unit testing, when Private Builds or Integration Builds are being created, Identification is usually informal. During the later stages, or when a Release Build is to be carried out, the Identification is much more formal. Developers can usually put in changes only if project management has agreed to them. Build Definition How to build it. The Build Definition is where build scripts (makefiles, Ant build files, or other configuration scripts) are created. These scripts define how the different parts of the application should be compiled and/or linked to produce a complete system or application. The scripts may also automate other parts of the process, such as database configuration and installation. The Definition stage is where you define the guts of any automation that is to be carried out. Build Execution Invocation and running of the build. Build Execution is where the build scripts identified in the Build Definition phase are executed. Execution can be carried out in a number of ways: by direct user invocation (the good old command line, by clicking a button in an IDE) or automatically on a scheduled basis. To increase the speed of the Build Execution phase, you can use two techniques. Build Distribution distributes the build across a number of processors or machines, and Build Avoidance rebuilds only the parts of the system that have changed since the last time the build was carried out. Build Reporting The results of the build. Build Reporting is where the results of the build (success or failure) are reported. The different types and levels of reporting include basic compilation reports, unit test reports, and release reports. The mechanism via which reports are generated can be either manual or automatic. For example, automatic notification of build success or failure can be sent via e-mail or instant messaging and the results published to a Web site. Alternatively, reports can be generated on demand as inputs to reviews or status meetings. Build Auditing can also be considered part of this stage. This is where, as a direct result of the Build Execution stage, the versions of all the source files used, the compilation settings, and the environment are automatically recorded.
From this set of definitions you can see that there is quite a lot to Build Management. Of course, anyone can throw together a few scripts to build some softwareit's not that difficult. What is difficult is knowing how best to do this so as to make that build run better, faster, and right. A Bit More on Software Release Management Next, let's consider Software Release Management. A release is constructed with the intention of being made available to a customer. Customers are scary. They expect you to be able to tell them exactly what is being given to them. They expect it to be complete and easily installable. They might even want to see some evidence that what is being given to them actually works. In effect, this means that the Software Release Management process is often more controlled and rigorous. Like Software Build Management, Software Release Management can also be broken into several stages: Release Packaging Takes the output of a Release Build and bundles it to make it complete and installable. These packages are sometimes called distribution archives. In technical terms, packaging might mean bundling a set of Java classes and libraries into an archive (a JAR or EAR file) to be available to be installed on a server. It doesn't mean copying the Release Build to a CD-ROM or DVD and casually passing it around! Release Approval (or Authorization) An additional checkpoint that is required before the release is deployed. If a release is being deployed internallyfor example, to the test teamRelease Approval might be an informal checkpoint to assess whether the Release Build is suitable for testing. If a release is being deployed or made available to an external customer, the Release Approval process should be more formal, potentially involving multiple stakeholders and a list of rigorous sign-off criteria. Release Deployment After approval has been given, the release can be deployed. The exact nature of Deployment depends on how the release is to be made available to customers. If the release is essentially shrink-wrapped software (for example, Microsoft Word), Deployment might mean giving a golden master to a manufacturer for duplication. Conversely, if the release is to be deployed to a runtime environmentfor example, a Web server or a set of client PCsDeployment means carefully controlling the distribution and installation across this infrastructure. Sometimes you might want to deploy releases of different products at the same time. One way to achieve this is by defining a Deployment Unit that references the exact set of files or release packages to be deployed. (I discuss the Deployment Unit in detail in Chapter 10, "The Art of Releasing.") Finally, one important aspect of Deployment that should never be overlooked is recording what version of each release has been installed, and where.
Note that I am talking about Software Release Management as the "engineering" of a release. I am not talking about Release Management in its wider sense (typically as specified by the IT Infrastructure Librarywww.itil.co.uk). In such a context, Release Management also includes project- or program-related issues such as how to manage and assess the impact of defects against multiple release streams or platform variants (see Haas [Haas02] for more information on this subject). To summarize, Software Build and Release Management is the process of ensuring that builds and releases can be reliably constructed, their content controlled, and their outputs deployed to test or runtime environments. The breakdown of these definitions is important because it gives us a framework to discuss the issues and challenges around the process. It also enables us to start thinking about what aspects of the process can be automated. But We Do Things Differently Here Our industry has many different software methodologies. Sometimes it seems that a new one is proposed every week. However, irrespective of whether you use a waterfall, iterative, incremental, or agile software development process, at some stage you need to build and release your software. The principles in this book should be ubiquitous software development best practices. The frequency at which you build and release is obviously a factor of the environment you are working in. In general, small projects can be integrated and built much more frequently than large projects, where several development teams might be delivering into a "system" Integration Build. However, there is no reason why each of these teams can't be considered small projects in their own right, each conducting its own Integration Build as frequently as it requires. The other area that often dictates the formality or rigor of the process being used is where an organization has compliance or audit requirementseither to meet some government standard such as Sarbanes-Oxley or to meet some industry-standard process maturity model such as CMMI. In such cases, the level of detail that needs to be kept, recorded, and controlled for project builds (and certainly for releases) is far greater than for a project that does not have to meet such requirements. That said, if this aspect of information recording is automated so that it is a natural part of the Software Build and Release Management process, there is no reason why all projects cannot capture this level of detail. |
|
