How to keep your repository straight with version control

Managing Application Evolution

March, 1992

You've just installed a brand-new application that has consumed your life for the last year. Users love it because it satisfies all their requirements and requires no enhancements to meet the demands of your users' volatile business environment. It has no bugs and integrates effortlessly into your corporation's application portfolio. You're ready to face the challenge of developing yet another flawless application for your adoring business users. Ah, life is good.

Then the phone rings, jolting you back from your daydreams of happy users and finished systems. Your user begs you to include just one more little enhancement in the release that is currently being tested and wonders if the subsequent release could possibly be installed a month sooner. Welcome back to the wonderful world of applications maintenance.

An application seems to take on a life of its own when the first release is installed into production. Users are quite adept at identifying additional data and functions that need to be supported. New technology and design concepts become available so fast that they've often become obsolete before you've even had a chance to integrate them into your systems.

The need to develop evolutionary applications that are architected for flexibility and change is obvious. As Amdahl Corp. states when marketing Huron, its applications-development product: "An application is always complete, but never finished."

Techniques must be established to support the maintenance phase of the applications life cycle. Supporting change and version control may not be as fun and exciting as enterprise modeling and application design, but they are just as essential for successful information resource management.

Maintenance is the process of implementing changes and enhancements throughout the life of an application. Version control is a set of procedures and techniques that let multiple incarnations of the same application component exist simultaneously as the application evolves over time.

Version control has two levels: application component and application release. An application component is an identifiable constituent of an application. Examples include entity, business function, program, database, data element, and test case. In addition, an application component is documented as a repository object.

An application release, on the other hand, is an identifiable package of related application components that has been or is intended to be implemented. Multiple releases of the same application may be in development and production at the same time.

Application version control starts at the application component level. When an application component is created, its corresponding repository object is assigned a version or revision number of zero. Whenever a change is made to the repository object, the version number increases by one. The unique name of the repository object consists of the name assigned by the repository user plus a specific version number. When the repository object is referred to by name only, the version with the highest version number is automatically accessed. However, a specific version can be identified by simply including its version number with the repository object name.

Consider the application component, customer, which describes an entity in the application's information model. Upon creation, it is assigned a version number of zero. As the definition of the application component evolves, new versions are created, as illustrated in Figure 1. The name "customer" identifies CUSTOMER-REV.2. However, the other two versions can be accessed by specifically identifying CUSTOMER-REV.0 or CUSTOMER-REV.1.

GUIDE refers to this type of version control as "serial." Each subsequent revision of a repository object creates a new object based upon the prior version. Each revision exists independently of the others, and the repository ensures that users access the correct version based on the version number included with the name.

The second level version control is used to manage application releases. Release version control is nothing new to applications developers. Techniques have been implemented in most environments allowing new releases to be based upon prior releases, but evolve independently of them. The illustrations of this function in this column apply to the IBM mainframe environment, using Manager Software Product's DataManager repository. However, the concepts apply regardless of the technology used to implement the  applications-development environment (ADE).

When the development of a new release commences, an environment is established through which the new versions of the application components are maintained. In the IBM MVS environment, a set of related libraries is created, as shown in Figure 2. Normally, application components are managed through libraries established for a specific purpose; that is, program source code and proc job control language (JCL) are maintained in separate libraries. As Figure 2 also illustrates, when the ADE is controlled through the repository, a repository partition must be created to house the repository object versions specific to the application release. With DataManager, the repository partition is implemented as a "status."

While the application component resides in the appropriate library, the corresponding documentation is maintained in the corresponding repository partition. When the repository is used actively in production, the documentation in the repository is used to generate the actual application component, as illustrated in Figure 3. For example, a CASE tool uses the data structure Group Y, which is documented in the release's repository partition, to generate Y's COBOL data definition. The COBOL statements are stored as a member in the release's Copylib.

Likewise, the ADE's code generator should use the logic documented in Module X's minispec, which is maintained in the repository to generate X's COBOL source code. This source code is stored in the release's Sourcelib. Additional CASE tools should be available to generate database data-definition statements, proc and JCL, and other application components. The libraries in a library set evolve through the development life cycle as a unit.

So far, we've only defined the library set of one application release. Let's expand the concept to handle multiple releases. Most applications are developed to support serial releases. The changes of the prior releases serve as the basis of a given release. Each release is intended to supersede the prior one. When application releases are serial, their library sets can be arranged into a library stack, as shown in Figure 4. The base library set contains all the application components for the entire application. Initially, the base is the library set for the first release of the application, but as the application evolves, it corresponds to the library set for the application components currently installed in production.

The library sets are placed in the stack in release order. A release library contains only those application components that have changed from the prior version. A repository must maintain repository object versions across release partitions by identifying which versions are referenced by a specific release. For example, when a change is made in the second quarter release of Module X, a new version (X_ 1) is created that is based on the production version.

Module X is modified again in the third-quarter release. Therefore, version X_2 is based on version X_1 from the second-quarter release. The library sets are concatenated, which allow a release to "see-thru" the library set stack and find the correct version of a repository object and its corresponding application component. For example, the third-quarter release references X_2 and Y_1 plus Z and B_1 from the first-quarter release and the production versions of A and T. DataManager's Advanced Status Facility provides support for the concatenation of repository partitions.

In an active ADE, application components are always generated from a repository partition into another library in the same release library set. Code is never generated from the third-quarter release repository partition into the first quarter release Sourcelib.

When a release is installed into production, its library set is merged with the current production libraries. At this time, the version of the application components and repository objects maintained in the release's library set replace the older versions residing in the production-equivalent libraries. Likewise, new application components introduced into the new release are added to the base set. For fallback purposes, it's prudent to retain a copy of the production equivalent library set as the archive version before merging it with the current release.

Parallel version control allows several versions of a single application component to exist simultaneously. However, these versions aren't meant to supersede one another. In the ideal world (in which the application is developed from an enterprise model), this type of version control probably isn't necessary. However, few corporations maintain this ideal application portfolio. Rather, legacy applications must also be managed and quite often manifest the following complications:

• The same name is used to refer to entirely different application components;

• The same application component uses the same name, but has been implemented differently in separate applications. For example, ACCT-STATUS-CD may use numeric codes in one application, while another uses alphanumeric codes;

• Applications implement the same corporate definition for a repository object, but must stage the implementation of enhancements to that object independently;

• The same application has been customized to meet the needs of different customers;

• Enhancements are being made to the corporate definitions, which are not yet ready to be implemented.

These situations require parallel version control in which independent library stacks can be maintained, as shown in Figure 5. Interrelated applications that integrate their release plans can share the same stack. A release stack can see-thru its own stack, but can't see-thru to other application's stacks.

Version control is an important management tool that provides the flexibility necessary to manage the application portfolio's evolution. A repository must provide support for versioning at both the repository object and release levels. Without version control, a repository's ability to control the ADE is severely limited.

Next month, we'll explore the role the repository plays in change management.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. Her common business models have been used as the basis of customer models for companies within the financial services, telecommunication, software/hardware technology manufacturing, and retail consumer product industries. You can reach her at terry@inastrol.com