So you went out and acquired IBM® Rational® ClearCase® and IBM® Rational® ClearQuest®, and you want to design a release management strategy implemented by ClearCase UCM. In order to have the best chance at deploying a system that meets all of your goals, you will have to pay attention to four different perspectives in this challenging landscape:
- In one corner (project management), there are the project managers, who must supervise the work efforts of their development teams to meet their release deadlines.
- In the next corner (release management) is the release manager, who must work with each ongoing project and determine what functionality from each project is ready for a release. In addition, the release manager also establish what, if any, dependencies exist between projects.
- In corner number three (architecture management), there is the application architect, who must work with the ClearCase administrators to create the correct ClearCase architecture to store the various components of an application, in order to give the most flexibility in managing work efforts.
- In the final corner (workspace management), there is the technical lead, who must work with the ClearCase administrators to provide the correct ClearCase workspaces to ensure that work efforts targeting releases are isolated from other work efforts. This involves creating the necessary streams, and the appropriate UCM projects to implement this needed isolation.
At times, these four forces in the software development effort seem isolated and independent. In order to design the optimum solution to provide the flexibility to meet your release strategy goals, you must take into account each of these perspectives, and then design a solution that gives you the best chance to succeed.
Release management means different things to different people, and there are many release management strategies out there. At one end of the spectrum is the ability to release an application based on its project plan. This is an application-centered strategy, and it is assumed that the application will release when and if its project management team determines it is ready for release.
At the other end of the spectrum is a coordinated release cycle by a department or organization. Using this strategy, regularly-scheduled releases occur at predetermined intervals, and those releases encompass more than one application. Coordination must occur between application teams, the projects that govern those application team’s activities, and the release manager. This article will address this more challenging release strategy.
Definitions (as they apply to this article)
-
Application: A deployable unit. In the Java™ space this is most likely an EAR (Enterprise Archive) file. It is known that you can also deploy layers of an application separately (such as a shared library, or an Enterprise JavaBean or EJB, that are used by multiple applications), but we will not examine these challenges in this document. However, anywhere this article refers to an application, you can simply treat it as a deployable unit.
-
Project: A funded, staffed, project-managed effort. A project may encompass one or more applications, and it may span one or more releases.
- Release: A coordinated, regularly-scheduled time when a set of new functionality for one or more applications is put in production.
As mentioned previously, there are four different perspectives that each brings a different concern to the ultimate goal of effectively producing a release. Let’s examine each perspective, and see how the IBM® Rational® tools can help you achieve your objectives.
As you know, project managers are responsible for the overall project planning, resources and, typically, the budget. Each organization has its own process for creating and defining a project. However, it all comes down to managing a funded group of resources to a plan and schedule. In managing the project plan, the project manager must work with the technical leads of the project to assign work, and to assess work completion.
The good news is that ClearQuest has the ability to help you as a project manager. By implementing a change management workflow that can help you track the work efforts that are assigned, you can control the order of work being assigned, as well as understand the status of those work assignments. You can examine trends, and should be able to improve your project planning and scheduling as you learn how your projected timeframes compare to actuals.
A good ClearQuest schema design involving defects or change requests will provide all of the data necessary to know the status of an active project on an ongoing basis. The goal of ClearQuest is to produce the necessary entities so that project managers can manage the assigned work that is associated with any given project. You must work closely with the project technical leads to understand how to divide up the work, decide to whom to assign the work, and understand just how complicated or simple a change actually is.
Next, let’s take a look at release management. As the release manager, you have a very different perspective. You must assemble the binaries that are to be deployed from the portfolio of applications that you are responsible for. Each release has the potential to include many applications and involve many projects. Remember that a project may be responsible for changes to many applications. This results in the nasty fact that you may have two different projects that are touching the same application. It is your job as the release manager to help coordinate those two projects so that there is integration between them to ensure a quality release.
The release manager and the project manager must work closely together when a scheduled release strategy is used. As a release date is set, the project managers that hope to get some of their functionality into that release must work backwards from the release date. Project managers must plan their iterations and work backwards to coincide with the release date. They must plan sufficient time for transition to production, various levels of testing, documentation, and so on, as shown in Figure 1. As the release date nears, decisions must be made as to what will be included in, or excluded from, a release.
Figure 1. Projects working towards a release date
In the case of two projects that are impacting the same application (A and B in Figure 1), the project managers of these two projects must work closely together to ensure that there is enough integration time for the two projects to test their changes together. This forces these two dependent projects to be very focused on realistic status, as well as be careful about assigning new activities.
ClearQuest is a valuable tool that helps you manage this complicated landscape. At this level, project managers need to be well aware of the progress of their team’s activities, and also be very conscious of how much their project can take on in order to meet the release date. By implementing a simple set of entities that manage project change, such as change requests or defects (both subsequently referred to as a change request), you can obtain a project status that is very close to reality.
Change requests and activities
Working with the technical lead of the project, you can use the change requests to be able to document the amount of work that are necessary. These segments of work should be taken directly from an iteration plan. By meticulously creating the necessary change requests, you will know exactly how much work needs to be done to meet your project's iteration goals.
The workflow associated with a change request should enforce the process by which your organization intends to track and manage change. If change control boards are part of your organization, or if code reviews are considered mandatory, the change request workflow should reflect those steps.
A level below the change request is the actual activity assigned to an individual, as shown in Figure 2. There is most likely more than one activity for each change request. Furthermore, the workflow for an activity should be kept simple, so that at any given time you know which activities are actively being worked, which are complete, and which are not yet started. Activities are assigned strategically.
The project manager and the technical lead need to work closely to determine who to assign an activity to, as well as when. The need to pull planned functionality from a release is always a requirement using this release strategy. The closer you are to knowing what is actually done and what is left to be done, the better equipped you are to make those key decisions.
Figure 2. Relative levels for project, change request, and activity
Now let’s switch again to the perspective of the release manager. How can ClearQuest help you the release manager? To reiterate, the release manager is responsible for bringing together the collective binaries that are to be deployed to production in a coordinated fashion. This means that:
- You need a way to organize the release and associate that release with the relevant projects and applications.
- You need to understand what official builds you will be making as part of the official release.
Simple ClearQuest build and release entities allow the release manager to get a handle on these things.
This article assumes that you follow build best practices, and that only official builds are available for release to production. In this case, official means that the deployable artifacts have been built in a controlled and repeatable environment, and that all build source code either comes from version control or is created during the build process. Having a ClearQuest entity that provides the data for each and every official build gives you access to all of the build information that should be gathered by an official build process.
The ClearQuest release (Figure 3) is simply a management entity that you use to collect information. The release can be associated to projects, to indicate the projects that have release candidates. The release can also be related to builds, to indicate the official application builds that make up the release.
Figure 3. Release associations
To summarize so far, a properly designed ClearQuest schema (one that takes into account the types of data that project managers and release managers must have at their fingertips to be effective) will go a long way to managing a successful release. For the most part, this is standard thinking when designing a ClearQuest schema, as shown in Figure 4. However, tying this information to the appropriate stream strategy, as you will see later, will take your solution to the next level.
Figure 4. How ClearQuest supports both project and release managers
Moving on, let’s examine the architecture management perspective. An application’s architecture at some point can be distilled down to a series of layers (or components, subsystems, and so on) that have well-defined boundaries. Almost all modern applications will utilize something previously developed, such as a utility JAR or a class library. ClearCase provides the concept of a component, which allows you to co-locate tightly-coupled code together in a management construct so that it can be baselined as a unit.
When a software application is to be inserted into ClearCase, the software architect needs to work with the ClearCase administrator to determine how to "componentize" the application into ClearCase components (an example is shown in Figure 5). Let’s take a typical Java or Java™ 2 Platform, Enterprise Edition (J2EE platform) application. A vast majority of all enterprise applications today probably take advantage of one of the many open source solutions available, including but not limited to the following:
- Log4J for logging
- Struts
- Spring
- Hibernate
- And so on
Why reinvent when you can reuse existing solutions?
In the same way, most organizations have established some type of framework or utility code that abstracts away complexity by creating a simple API for developers to follow. There may also be departmental or business unit-specific code that spans applications, such as maybe a security solution.
Sometimes, an organization’s structure will also dictate how you insert applications into components. Suppose your organization has specialized its Java skills and separated user interface developers (HTML, JSP, JSF, and so on) from their Java/J2EE developers (EJBs, DAO, database access, and so on). In this case, you may take an application and separate the code into different components around these lines (Figure 5).
As the backend developers create EJB solutions, they are consumed by applications and front-end developers call them to get their data. This is just another example of how you must examine an application to ensure that its architecturally significant parts are properly componentized in ClearCase.
Figure 5. Components
To take this one step further, there are many alternative ways that a Java application can consume one of these common utility JARs. For example, in IBM® Rational® Application Developer, you may include the utility JAR in the WEB-INF\lib directory of a Web project, or make it a utility JAR that is part of an EAR project. Either way, these JARs become scattered across projects and you lose architectural control.
On the other hand, if you locate these common utility JARs in a component, one single copy of the JAR is under version control and you force projects to consume those JARs in ways that do not include copying them into their workspace.
The more attention that you pay to this perspective, the better off you will be in the long run. ClearCase components are provided to you as a feature that allows you to separate sections code using a version control mechanism so that you can manage that code in a consistent way. Take advantage of this feature.
Finally, let’s examine the workspace management perspective. ClearCase also provides a rich set of parallel development features. Think of ClearCase UCM as a layer on top of both ClearCase and ClearQuest that provides an out-of-the-box solution for workspace management. Streams are used to isolate work, and UCM projects are used to group the available components together for the isolated work.
By associating individual ClearQuest activities with the set of files modified to satisfy that activity, you are capturing a change set. That change set represents the collective set of files that needed to be modified to satisfy the change. Conversely, each and every version of every file can be traced back to the activity, and therefore the change request, that caused the change. UCM gives you the ultimate ability to govern the change process for your projects.
It would be nice if you only ever had to deal with one development effort for an application at any given time. But this is highly unrealistic in today’s fast-moving software development world. Emergency bug fixes are regularly needed to repair critical production problems. At the same time, new features are constantly being requested by stakeholders, so there is always a need for new development. ClearCase UCM provides the solution that allows you to manage this reality.
ClearCase streams allow you to isolate a discrete set of work from other efforts. UCM projects allow you to group the necessary components together with a stream to provide the environment needed to get work done. And UCM projects hide the complexity of view setup from the user.
UCM projects also allow you to enforce architecture management. For example, if common utility JAR files are located in a component, that component should be provided as a read-only component in UCM projects used by development teams, as shown in Figure 6. Another example involves providing build environments. By creating separate UCM projects for build efforts, you can provide all source code components as read-only, and only allow the build process to modify a component that stores build targets (if you store build targets in ClearCase).
Figure 6. Using UCM projects to enforce architecture management concepts
There are many stream strategy solutions out there, and each one has its pros and cons. At a minimum, your ClearCase administration team needs to establish a stream strategy and stick to it when working with projects. Successful ClearCase administration teams maintain a "master view" of their active streams (Figure 7) by using a simple whiteboard or plotter paper approach. By maintaining an active picture of the major streams of work in flight, you can make accurate decisions regarding if and when to deliver baselines between streams, what baselines to create new streams from, and so on.
Figure 7. One example of a master view
This article is not intended to offer detailed stream strategy approaches, but let’s rule out some of the extremes. First of all, most release managers would say that they need ultimate flexibility in being able to pull any change from a release at any time. While this is easy to say, it is incredibly hard to automate. Taken at face value, you would be inclined to then isolate each change request onto its own stream. This does give you ultimate flexibility, because:
- The change set(s) for that change request are isolated from all other changes.
- You have the freedom to deliver that change to the appropriate integration stream when and if you choose.
However, this is a UCM administrator’s nightmare. This approach creates the need for lots of deliveries to various other streams, and it is simply too hard to manage. There are just too many active streams to keep track of.
On the other end of the spectrum is a complete single-stream concept. All changes are integrated on the same stream. This obviously does not provide the flexibility needed by a release manager:
- It causes many dependencies.
- It does not give you the ability to maintain multiple work efforts.
The desired strategy is somewhere in the middle, and this article will examine one such strategy (at a high level) in the next section.
You have now examined two more perspectives that deal with using ClearCase UCM features to give you a desirable ClearCase infrastructure that helps you meet the goals of your release. By properly placing applications into UCM components, you have the ability to provide those components to work efforts in a controlled fashion. UCM projects allow you to assemble the components that are necessary to a work effort, and also to control access to those components.
A UCM project also allows you to create the necessary integration streams needed to isolate work efforts. In addition, the UCM project hides the complexity of view creation from the user. All in all, a stream strategy that is well defined, managed, and enforced gives project leaders a structure to manage work targeted for a release.
Figure 8. How ClearCase supports UCM
So far, you have examined the four perspectives that play a role in your implementation of ClearQuest and ClearCase to automate and govern a release management strategy. However, the only integration between ClearQuest and ClearCase mentioned so far is the UCM integration of a ClearQuest activity record (that has the UCM package applied to it) with the corresponding versions of elements that make up the change set.
Project managers and release managers work closely together to plan changes in their corresponding projects to meet release goals. ClearCase provides the UCM projects and streams that allow developers to isolate their work to specified target releases. However, so far your strategy does not help manage the need to specify that a particular change request is to be targeted to a specific release, and therefore to a specific UCM project.
Before presenting a solution, here is a strategy: it is recommended that for each application that is part of a project that intends to include some type of functionality in a release, you need a UCM project and corresponding integration stream to isolate that effort. This is a good compromise between a stream per change (too many streams) and single-stream development (too many dependencies).
When you create an integration stream and a corresponding UCM project to isolate work targeted at a release:
- You provide the workspace needed for developers.
- It gives you a manageable number of streams to deal with.
Project managers and tech leads still have the daunting task of strategically assigning work to the proper effort, however. As deadlines near, the project leaders must continually assess the amount of unfinished work and determine if work should slip to the subsequent release.
You always have the potential for needing to back out work to meet a deadline, but this strategy seems to provide the best environment to meet the goals of regular releases. To complete the picture, you need to provide direction to developers in using the correct UCM project when assigned an activity.
To accomplish this, create another management entity in ClearQuest to help tie this all together. For lack of a better name, call that entity a release unit. The release unit’s job is solely a management one. Its purpose is to link change requests to their appropriate UCM project. This does the following:
- It gives developers direction as to where the changes should occur.
- It allows project managers and tech leads to examine their list of unfinished change requests, and assign them to the appropriate release unit (therefore directing the developers to the correct UCM project).
The release unit is not a silver bullet, simply an organizational mechanism to help understand where things are being done. You still have the mess of reassigning a change from one release to another, and then potentially backing out a change set from one stream and moving it to another. Nevertheless, with this management mechanism, at least you have a shot at understanding just what you have and where it exists.
Figure 9. How a release unit fits into UCM
When project managers examine their iteration plans, and lay out the work needed to complete their iterations on time to meet a release target date, they can assign each change request to its appropriate release unit. The release unit is associated with a specific UCM project. Then, when a developer examines her assigned activities, each activity is tied to a release unit and therefore there is a concrete assignment to a particular UCM project.
Coordinating projects and development efforts with the goal of a regularly-scheduled release strategy is complicated at best. ClearQuest and ClearCase offer the building blocks that allow you to automate a customized release strategy, as shown in Figure 10.
Figure 10. The big picture: an automated, customized release strategy
They offer you better than a fighting chance of meeting your release goals if you remember the following:
- Pay attention to all four perspectives discussed in this article
- Use the power of ClearQuest to help manage the complexity
- Connecting your stream strategy to your ClearQuest implementation
Learn
- For more information on this subject, read Enterprise Software Release Management by David Lipien, Jennifer Haines, and Patrick Gan.
- Visit the Rational ClearCase area on developerWorks for articles and tutorials on ClearCase.
- Online documentation for ClearQuest users and administrators is available at the IBM Software Information Center.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Try Rational ClearCase V7.0. Evaluate Rational ClearCase V7.0 online without installing or configuring it on your own system. When you register for this online trial, you can access both Rational ClearCase and Rational ClearQuest installed into a combined environment.
- Read the IBM Rational ClearCase and IBM Rational ClearQuest Evaluation Guide, Part 1: Unified Change Management, as a guide to the online demo for ClearCase and ClearQuest.
- ClearQuest users and administrators can find more resources in the ClearQuest section of the developerWorks Rational zone, including hooks, Eclipse plug-ins, product documentation, articles and whitepapers.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
Discuss
- Participate in the
Rational ClearCase forum on developerWorks. Post your ClearCase questions and comments, and share your thoughts, ideas, and solutions with other users. To participate by email rather than on the Web, subscribe by sending a note to: cciug-subscribe@lists.ca.ibm.com.
- Check out the ClearQuest discussion forum on developerWorks Rational.
- Check out developerWorks blogs and get involved in the developerWorks community.
Darrell Schrag is a member of IBM Software Services for Rational (ISSR), consultants who help customers improve their software development practices. Darrell has successfully helped customers deploy Rational tools and processes accross all disciplines of the software development lifecycle. Darrell also helps customers govern their service-oriented architecture efforts as well as implement patterns-based development accellerators. Darrell also specializes in the IBM Rational Unified Service creation solution for the communications industry.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
