Cloning a Release

Owned by Kevin Pham (Deactivated)
Last updated: Jan 23, 2018

Description

In Zephyr Enterprise, projects consists of releases that assist in organizing your testing. By default, when a project is initially created, there will always be a default release. This default release is labeled as "Release 1.0". Users can clone releases which completely copies a release from within the current project selected or a different project altogether. Users are able to clone the Testcase Repository, Requirement Repository, and Cycles for the release including further cloning options for each category. To learn how to clone releases, please view the steps below.

Terminology

 Click to view more information on terminology regarding this page
TermDescription
ReleaseA release is an iteration or version of testing within a project. Releases can house requirements, test cases, and defects for a project.
CloneTo copy a release and make an exact copy of the release with the additional copying options.
Testcase RepositoryA centralized location where all the test cases for the release are stored and managed.
Requirement RepositoryA centralized location where all the requirements for the release are stored and managed.
CyclesA period of time of when the tests are to be executed by QA testers.
PhasesA period of time includes what test cases are being executed by QA testers.
Start DateThe date that the release starts.

Table of Contents

The steps below describe in detail the general process of adding, editing, deleting, and cloning a release within a project for Zephyr Enterprise. To view further instructions for each individual function, please click the links provided below. By clicking on a link, you will be redirected to the page with the steps corresponding to the function selected. 

Cloning Releases

Prior to Cloning a Release

Prior to cloning a release, there must be an existing project that has been created in Zephyr Enterprise. The project must be selected and the user must have selected the manage release button explained in the Release Setup section. There needs to be at least 1 release created in the system whether it be in the project you're working on or a different project to able to clone a release.

Scenario: You are a testing manager that just created a project called "Mercury" and you are managing your releases within project Mercury. As a testing manager, you want to clone the existing release in project Mercury. You will be cloning "Release 1.0" and cloning both the Testcase Repository and Requirement Repository associated with "Release 1.0" but not the Cycles.

If this is your first time cloning a release, we highly recommend that you create and work in a test project that doesn't affect another project, and work out any issues you might have with cloning a release before you work in a live project. 

The following items can be cloned and can be selected for the cloning process:

  • Test Repository
    • Attachments
  • Cycles
    • Cycle-phase assignments
    • Execution Results
      • Comments
      • Defect Mapping
      • Attachments
      • Step Results
        • Comment
        • Attachments
  • Requirements Repository
    • Mapping between requirements and test cases
    • Attachments
  • Documents


Additional Notes on Cloning a Release

  • If you only need the Cycles, Phases, and Assignments, exclude cloning the execution results.
  • Pick the user who should be assigned test cases and their executions in the cloned release if a particular user in the original release is not a part of this project (e.g. if "Joe" was on release A and is no longer a part of the project that contains release B (which was cloned from release A), then all test cases and executions assigned to him in release B will now be assigned to a new user that is picked here.)
  • The Release Start Date is important.
    • The cloned release will have the same offset for all cycles and cycle-phases as in the original release (e.g. if cycle A started 1 week after the Start Date on the original release, then the cycle A-clone will start 1 week after this Release Start Date and so on. The length of the cycles remain the same.)

Steps to Clone a Release

1. In 'Manage Release',  icon at the top-right side of the interface or click on the  icon at the right side of the table for the release that you want to clone. (In our scenario, we'll be cloning "Release 1.0")

  • If you clicked the  icon, a module will pop up asking you to either "Create new release" or "Clone existing release" and after selecting, you will click on the "Continue" button. (In our scenario, we'll be selecting "Clone existing release")


The Release clone process can take a significant amount of time to complete depending on release size. During the process, the original release will not be available. It is strongly recommended that this feature be used during off-peak hours and for you to notify the users. Once the process has begun, it cannot be stopped, paused or cancelled. Any attempt to have data created in the original release during the cloning process will be lost.

2. A warning module will pop up and you can click the "Yes" button.


3. Select the Project and Release to be cloned as well as a user assigned to the release. (In our scenario, we'll be selecting project "Mercury" and "Release 1.0")

4. Use the checkboxes to select if you want to clone the Testcase Repository, Requirement Repository, and the Cycles.

5. Choose the Start Date for the cloned release.

6. After you have your options selected, click the "Clone" button at the bottom right of the interface.


7. A module will pop up asking you to confirm and then you can click the "Yes" button to confirm the cloning.


8. From here, you will see the cloning progress and once it is complete, you can click "Ok".

You have officially cloned a release!

You are now able to edit the cloned release to change the name and start/end dates. Please refer to Editing a Release for further instructions on how to edit the release.


Back to Top ^