Foundations for the Release

To be able to successfully release software, first you need to know what physical form your release will take and how it will be made available to your end users. This section begins by describing exactly what should be packaged and deployed as part of your release with the definition of a Deployment Unit.

The Deployment Unit

Perhaps the most fundamental question you can ask yourself about Software Release Management is what the output will be. You should be trying to produce a self-contained, installable, documented, traceable release of software. This is often called the Deployment Unit. It is not necessarily a single artifact like a J2EE .ear file. Rather, it is a collection of related artifacts, as illustrated in Figure 10.1.

Figure 10.1. The Deployment Unit

In Figure 10.1 you can see that the Deployment Unit consists of a number of artifacts at a number of levels. At the lowest level, change requests cause the generation of new or changed Work Product Components. These are all the source code, configuration, or documentation files that you will be changing on a day-to-day basis. These files are usually built and grouped to form some type of Deployment Component; this is usually your built libraries (.jar or .dll files) or executables. The combination of all the possible Deployment Components forms a Release Build, which, together with the Release Notes detailing the change requests that contributed to the build, has formed the main part of the discussion up until now. For ease of installation or deployment, you might decide to package the output of the Release Build into a Release Package. (I will discuss various mechanisms for creating this Release Package in the next chapter.) Finally, bringing all this together at the top level is the Deployment Unit, which together with its Bill of Materials (detailing its exact contents) and Supporting Artifacts (such as installation documents) defines exactly what the Software Release Process should be trying to produce. In effect, a Deployment Unit is a reference to the set of files to be deployed, whether they are packaged as part of a Release Package or simply the outputs of a Release Build.

The exact form that a Release Package takes and how it is physically deployed as part of the Deployment Unit depends on the type of product you are developing and the environment you are deploying to. Table 10.1 lists a number of typical approaches.

Table 10.1. Approaches to Deployment

Product Type	Release Package Format	Method of Deployment
Thick-client application, such as Microsoft Office or Eclipse	Compressed archive (.zip, .gz) Self-installing executable (.exe) Installation file (.msi, .rpm)	Simple file extraction Distribution via media (CD or DVD) Distribution via tool (Microsoft SMS or Tivoli Configuration Manager)
Java web application	Web archive file (.war)	Manually installed via web or application server
J2EE application	Enterprise archive file (.ear)	Automatically via Ant tasks
Database application	Database scripts (.sql or .ddl)	Distribution via tool (Microsoft SMS or Tivoli Configuration Manager)

For example, if you are developing a thick-client application that is to be installed on a user's desktop (think Microsoft Office or Eclipse), your Deployment Unit might refer to a set of packaged .exe (executable), .rpm (RedHat Package), or .msi (Microsoft Installer) files. However, if you are developing a Java web or J2EE application, your Deployment Unit will refer to a single .war (Web archive) or .ear (Enterprise archive) file. In both of these examples the Deployment Unit might also consist of any supporting artifacts such as database configuration scripts that need to be deployed alongside the product.

How Many Products Can You Deploy?

Some organizations prefer to deploy a single, complete product that maps to a single Release Build of an application. Other organizations prefer to deploy multiple or partial products. In reality, your deployment process and the definition of your Deployment Unit need to be flexible enough to cater to both of these needs.

The type of product that you are developing also dictates the method of deployment. For example, thick-client applications often are distributed shrink-wrapped to customers on CD/DVD media. In large organizations (such as in financial services), they might be distributed using a software distribution tool such as Microsoft System Management Server (SMS) or IBM Tivoli Configuration Manager. In both of these scenarios, the deployment process usually has defined limits or boundaries; these need to be managed or crossed for deployment to occur successfully. I will discuss the deployment boundary next.

The Deployment Boundary

If you are developing shrink-wrapped products, it is clear where the limit and boundary of the deployment process exist. Once you have made a golden master available to manufacturing, it is up to the customer who obtains the distributed media to worry about the deployment or installation process. However, if you are developing applications for a line of business in a large organization, such as an Internet banking application as in this book, the situation is often not so clear. In such a scenario there is often a distinction between the IT Development and IT Operations teams, and there is usually some form of controlled handover between them to progress the deployment, as shown in Figure 10.2.

Figure 10.2. IT Development and Operations environment

This handover necessitates that there is a boundary or gap between these teams. Often this gap is there for a reason; large organizations usually have audit or compliance regulations, and it therefore serves as a gate or checkpoint to ensure that the IT Development team is not allowed to deploy to the final or production environment.

Sarbanes-Oxley

One current example of compliance that is affecting IT software development and deployment is the Sarbanes-Oxley Act, Section 404, which has a requirement for "segregation of duties." This essentially reinforces the position that developers should not be allowed to deploy to the production environment.

To bridge this gap while ensuring compliance, you need some method of guaranteeing that the Deployment Unit is identical in both the IT Development and Operations environments. This is usually carried out by signing or sealing the Deployment Unit and by ensuring that the deployment process is fundamentally identical in both environments. I will describe some practical methods to achieve this in the next chapter. Next, however, I will look in more detail at a typical deployment life cycle.

The Deployment Life Cycle

To execute any deployment, you typically go through a controlled life cycle. This life cycle includes all aspects of defining the Deployment Unit and what Release Packages or files it should reference, testing it, approving its deployment, and finally actually deploying it. Figure 10.3 shows a typical deployment life cycle.

Figure 10.3. Deployment life cycle

In theory this life cycle would be the same whether a complete application, maintenance release, or patch were being deployed. However, the deployment of critical or emergency fixes might be preapproved. In some organizations, deployment occurs in a number of "environments"typically Development, System Test, User Acceptance Test, and Production. The deployment life cycle simply iterates for each of these environments, with the level of approval required being dependent on the environment that was being deployed to.

Essentially, the deployment life cycle defines a work flow, and ultimately you probably will want to automate this work flow. Since ClearQuest models entities with work flow, you can use it to automate the deployment life cycle to a large extent. If used correctly, ClearQuest can also be a great communication enabler for bridging the gap between the IT Operations and IT Development teams. The next chapter discusses the use of ClearQuest in more detail. In particular, it covers ClearQuest's Build and Deployment Tracking capability, which allows you to automate the process of deploying software releases. Next, however, I will discuss the typical project or organization roles that are involved in the build, release, and deployment process.

Deployment Roles

As you have seen, a number of roles are affected by the deployment process. These have different names, depending on your environment, but essentially the two main roles are as follows:

• Build engineer (or release engineer) Executes builds, creates Release Packages, and stages the outputs.

• Deployment engineer Takes the staged outputs, creates a Deployment Unit, provisions servers so that they are ready to deploy to, and executes the deployment itself.

The relationship between these roles is illustrated in Figure 10.4.

Figure 10.4. Sample deployment roles

A number of other roles affect the release and deployment process; this is just a typical and common set. As such, it will serve for when we discuss how to automate some of these steps in this and the next chapter. In particular, the release management aspects of the overall processcontrolling the content of what is built, packaged, and subsequently deployedaffect a number of project roles.

Now that I have discussed the physical form a release might take and how it can be deployed, I will move on to discuss how to actually construct a release, starting with how to create an environment for conducting a Release Build.