Previous Topic: ReleaseNext Topic: Package Distribution Report UDP

Predefined Lifecycle Templates › Release › How Release Works

How Release Works

The flow through the Release lifecycle is as follows:

  1. Create a package in the Development state or move a package into the Development state from a Problem Tracking project using the cross project merge process. To create a request in the Development state, select the Create Package process. This process creates a package with an associated Modification Request form named MR-n (n is an incremental number for each new form). This package moves the Modification Request through the lifecycle. For modification, check out an item for update and associate it with the appropriate package. After modifications are finished, check the file in with the associated package. When development is complete, promote the package to Test.
  2. In Test, verify this package with its new version of the item. If errors occur during testing, demote the package to Development. After Development resolves errors, again promote the package to Test. When testing is complete, promote the package to Release.

An alternative scenario follows:

  1. The Project Lead receives the design document and creates one package for each function that needs to be modified. At the same time, the Review Board decides which new problems need to be worked on. Developers are assigned specific packages.
  2. Developers check out the items for update associated with the appropriate package. Developers modify files and compile new changes. If no compiler errors exist, basic unit tests are performed on the code and the completed code files are checked in. Development continues until the files are ready for integration testing. If errors occur during integration tests, the items are again checked out with the appropriate package, modified, and checked in. When integration testing is complete, the Project Lead promotes the packages to the Test state.

    Note: You can use the concurrent development to place each package on a separate branch. After modifying the branch versions, use the concurrent merge process to create one version on the trunk. Then you can run the interactive merge process to integrate changes between two versions and remove the merge tag. After the interactive merge is complete, you can promote the packages to the Test state.

  3. When the Test group is notified of the promotion, all the items are checked out to create the Test build. Testers use this build to perform verification and validation tests. If problems occur during testing, the Test group works with the Developers to determine if the package needs to be demoted to have the fix incorporated or if a new package needs to be created. After testing is complete, all packages in the Test state are promoted to Release.
  4. When the Release view contains the versions that should be used as the starting point of another release lifecycle, a snapshot is taken with the current date and time and Visible to Other Projects enabled. This snapshot can be attached to the baseline view of the new project that begins with the versions captured by the snapshot. In addition, these snapshots can be viewed in the View Snapshots state. Users can also check out old releases from this state using the snapshot.
  5. The Release group creates the release media by checking out the executable items from CA Harvest SCM. Release code can also be distributed using a software distribution package such as the Safer program.

Example: Flow in Release

An example of the flow through the Release lifecycle follows:

  1. A file modification is required and a package for it is created in the Development state.
  2. This package has an associated modification request form that details the changes that are needed.
  3. The items are checked out for update, associated with the package, and are modified by Development.
  4. The modified files are checked in to CA Harvest SCM.
  5. The package is promoted to the Test state.
  6. When testing is complete, the package is promoted to the Release state.
  7. To begin work on the next release or if an emergency fix needs to be implemented, a snapshot is taken of the Release view.
  8. This snapshot is attached to the baseline view of a new project where additional development is isolated.
  9. Changes made for one project can be implemented in another project by performing a cross project merge. A cross project merge lets you select the changes that you want to implement in both projects.