Build and Release Branching Strategies

When used effectively, Base ClearCase branches or UCM streams can significantly accelerate the development process. This is particularly true for Software Build and Release Management, where you must often control the integration and promotion of changes and establish separate environments to manage different releases or bug fixes. This section discusses three branching strategies that are directly related to the build and release process:

• Active Development Line Typically a project's integration branch containing the latest development baseline.

• Release-Prep Line A branch created for the purpose of conducting or stabilizing a release (while also allowing delivery to the Active Development Line to continue).

• Promotion Line A branch created for a distinct level of assembly or integration, such as to integrate a system's components or to allow a site to integrate before executing a remote delivery.

Each of these strategies can be used in isolation or in combination, depending on your environment's needs. They also typically form part of an overall branching strategy to support your integration, release, and maintenance processes. A general discussion of branching patterns can be found in Brad Appleton's seminal paper [Appleton98]. Some of these patterns were later refined in Software Configuration Management Patterns [Berczuk02]. In the descriptions of the strategies that follow, I use the names of the patterns as identified in these two documents. For more details on how branching patterns can be implemented using ClearCase, refer to Bellagio and Milligan [Bellagio05].

Active Development Line

The two main Software Configuration Management patterns that developers typically use on a day-to-day basis are the Active Development Line branching strategy in combination with a Private Workspace. A Private Workspace is an isolated environment where developers can control the versions of code they are working on. In ClearCase the Active Development Line is represented by either a Base ClearCase integration branch or a UCM project integration stream, as illustrated in Figure 3.8.

Figure 3.8. Active Development Line

Connected to the project integration branch are the Private Workspaces, which in Figure 3.8 are represented as private branches, but which also include the ClearCase view that is being used to work on the branch. However, a Private Workspace does not necessarily have to be realized by a new branch. In some small development projects, developers work directly on the Active Development Line. In this case, their Private Workspace is realized via the ClearCase view check-in/check-out mechanism. In ClearCase, this mechanism of working is often called branch/LATEST development and is often reinforced by the practice of continuous integration.

The strategy of how your Private Workspaces are realizedwhether to create a branch per developer or per team or to work directly on the Active Development Lineis an important one. It depends on a number of factors, such as the size of the development team, its experience, the development methodology it is following, and the environment in which it is working. ClearCase can support any of these practices. It is important to remember that just because it can, there is no need to implement more process and structure that you actually need. The strategy that you choose for your Private Workspaces also has a direct impact on when and how Integration Builds are carried out. The more you integrate your Active Development Line, the more Integration Builds you need to carry out. Finding the appropriate frequency of deliveries, integration, and builds is what I call finding your "project rhythm"as discussed throughout the book.

Release-Prep Line

During active development, Integration Builds are typically carried out using a specific ClearCase build view on the project's Active Development Line. If these builds are timely and successful, this single line might suffice for day-to-day development work. However, perhaps the build has serious problems that will take time to address (and that will prevent deliveries to this line). Or maybe, more importantly, you simply require more control and isolation when conducting Release Builds. One strategy is to create a Release-Prep Line. This typically is created directly off the Active Development Line, as shown in Figure 3.9. Note that this particular implementation is also sometimes called build stabilization.

Figure 3.9. Release-Prep Line

With UCM you can set up this environment by creating a new child stream off the project's integration stream. Then, when you want to engineer a release, you can simply rebase to a particular candidate integration baseline from the integration stream. Note that you can also implement this environment by creating a UCM "release" project and delivering candidate integration baselines into it. Base ClearCase has no rebase functionality, but you can achieve the same effect by setting the config spec for the Release-Prep view to

• Point to the candidate integration label (RATLBANK_01_INT in Figure 3.9).

• Automatically create the Release-Prep branch if any changes are made.

On the Release-Prep Line you also can roll out any changes that are not required in the release or implement quick fixes.

The need for a Release-Prep Line is particularly relevant where branch/LATEST development and/or continuous integration is being used, because the Active Development line needs to be available to the developers at all times. Chapter 10, "The Art of Releasing," illustrates in more detail how to create a Release-Prep Line to execute a Release Build.

Promotion Line

The Active Development Line and Release-Prep Line strategies just described should suffice for a large number of projects. However, a build and release process typically must meet other requirements:

• The integration of multiple development components into a system build

• Remote (multisite) development

• Staging (or check-in) of build objects for further development or deployment

Each scenario is basically a variation of the same pattern, a Promotion Line that assembles, migrates, or merges a set of source or object files from one branch to another. The physical implementation of the Promotion Line for each of these scenarios is different, however.

Complex systems that consist of a number of development teams or components contributing to a system build typically have many levels of integration, as illustrated in Figure 3.10. Here, rather than having a single Integration Build, Component Integration Builds build a single software component, and System Integration Builds build multiple components.

Figure 3.10. Promotion Linecomponent integration

Note that from a system point of view there is a notion of an Active Development Line and a Promotion Line. However, from the component development team's point of view, the Promotion Line is in fact their own Active Development Line. From a build and release point of view, the differences are as follows:

• Multiple levels of Integration Builds are required.

• System integration might consist not of rebuilding the complete set of component source code, but rather of reusing and building against a set of staged (or checked-in) prebuilt objects.

Chapter 10 describes in more detail how to stage prebuilt objects for system integration or deployment.

Development projects that work across multiple sites can use the ClearCase MultiSite capability. This allows ClearCase data to be replicated on a regular basis between sites. However, when MultiSite is implemented, users have to contend with the additional issue of mastership, in which a particular branch or stream can be "owned" by only one site at a time. In such a scenario, Integration Builds typically are carried out at the site where the integration stream is mastered. However, there is no reason why multiple levels of Integration Builds can't exist. For example, a remote site could execute a regular (and automated) Integration Build on its own site-based Promotion Line, as illustrated in Figure 3.11.

Figure 3.11. Promotion Lineremote integration

However, with such an environment, changes still need to be delivered to the master site. Essentially, two mechanisms achieve this:

• With "push" delivery, integration typically is initiated and completed by a developer at the remote site (the site without mastership to the Active Development line).

• With "pull" delivery, integration typically is initiated and completed by an integrator at the master site (the site with mastership to the Active Development line).

With Base ClearCase, developers can use the request for mastership capability to execute a "push" delivery. This ensures that they have permission to merge onto the integration branch. This is the recommended approach because it places the onus of the delivery process on the developer. Since the developer making the delivery should have more context about the changes being integrated, any merge conflicts should be resolved more efficiently. The disadvantage is that it can lead to a significant amount of mastership "churn" as mastership is passed back and forth. To execute a "pull" delivery in Base ClearCase, an integrator role is required at the master site. This integrator pulls all the changes from the remote site and carries out any merges. This approach has the advantage of introducing more control, but it can significantly increase integration times and slow down the overall development process.

In UCM it is not possible to execute a request for mastership for a project integration stream; therefore, any remote delivery is a two-stage process. To carry out a delivery, developers at the remote site first "post" their activities. Then, at the master site, an integrator finds and completes these deliveries. This is by necessity a "pull" delivery and has the same implications as a "pull" delivery in the Base ClearCase example just described. An alternative approach (to mimic a "push" delivery) is to allow developers at the remote site to "post" their activities as normal. However, rather than an individual finding and completing the changes at the master site, an automated script is used. This script runs on a scheduled basis, finds any posted activities, and attempts to complete them. If only trivial merges are required, the script can complete the delivery successfully. However, if more complex (and manual) merges are required, the script sends an e-mail to an integrator, stating that manual intervention is required. This approach works well if developers typically don't affect the same files and if the "rebase before delivery" UCM policy is enabled. For more information on MultiSite and "push" and "pull" deliveries, see Bellagio and Milligan [Bellagio05].