Skip to main content
System StatusContact Support
VersionOne Community

Continuum Progressions

A progression is a defined set of one or more Phases through which package revisions move in order to be delivered to end users. Each package revision contains one or more workitems (stories or defects) with associated changes (commits).

Once phases are defined for a progression, Package Revisions may be promoted through the phases. Each package can have a discrete set of Activities and Controls defined which will be executed as the package revisions arrives at that particular phase.

Creating a Progression

  1. From the homepage, click the administration menu Admin Menu, under"Flow" select "Progressions"
  2. Click "Add New"
  3. Provide a name and description for your progression and then click "Create".

New Progression

Provide a relevant name for your progression so it can be easily identified at a later time. If different categories of software (ie products or micro-services) go through a different process in order to be delivered, create different progressions for each.

Defining Progression Phases

Once the Progression has been created its phases may be defined. Each phase represents a discrete step in the software delivery process through which value (workitems) is moved as software gets closer to delivery for end users.

  1. Click the "Add Phase" button
  2. Enter a "Phase" name and "Description" then click "Add"

New Progression Phase

  1. Repeat steps 1 and 2 for each additional phase in your Progression.
  2. Click "Done" once all the phases have been defined

Defining the "Code Complete" Phase

Given all phases in a progression have been defined, one of the phases must be designated as the "code complete" phase; this is defined as the phase where work arrives in its final state and no further changes will be made to the contents (workitems) of the relevant package revision. That is to say, when work arrives at this phase, it is considered ready to be delivered to the end-user.

This threshold is defined so that Continuum can track the time it takes for a workitem to become "code-complete" and provide code commit reporting around risk and quality.

To define the code-complete phase, tick the radio button to the left of the phase name. In the below example, the "Ready for Delivery" phase is defined as the code-complete phase for the "Authentication Service" progression.

In the above example, code commits that appear on or after this phase should be considered out of process and thus high-risk. This is further detailed in the Progression Metrics section.

Once Progression and Phases have been defined, you can start moving package revisions through it by using the Flow plugin "Package - Promote Revision".

Interpreting the Progression Board 

The progression board allows selection of a specific progression and shows all phases along with their contents.

ProgressionBoard.png

As package revisions are moved through the progression board, each revision will show the following:

Package Revision

  • Package + Version Number: Package name whose revision has been promoted and major version number.
  • Version Range: Range of minor version numbers included in this package revision.
  • Revision Range: Range of package revisions included in package revision.
  • Total Number of Workitems: Total number of stories and defects included in this package revision. 
  • Number of Rogue Commits: Total number of commits that are not associated to a workitem and thus are "rogue".

Hovering over each of the squares in the progression board will show the relevant workitem ID. Clicking on a square will take you "Workitem Perspective" view.

The following types of units are shown on the board:

 Stories (Green)

A green square represents a "story" workitem. These are workitems preceded with an "S" in VersionOne Lifecycle (S-12345) or issue type "Story" in Jira.

 Defects (Yellow)

A yellow square represents a defect. These are workitems preceded with a "D" in VersionOne Lifecycle (D-12345) or issue type "Bug" in Jira.

 Trailing Commits (diagonal split)

The light shaded square split with a diagonal line represents an "undeliverable" workitem which contains trailing commits. This means there are additional commits for this work item in a package located in an earlier phase that are not contained in the package revision you are currently viewing. Effectively all the work that has been committed against this item is not in the current package and thus is not deliverable.

Summary Tab

Summary Tab

The upper right hand side of each package revision will offer a "summary" tab with the following data:

Forecast Delivery Forecast

A forecast (in days) of when this package revision will be delivered. This number is calculated based on the past delivery performances for this particular package.

Rogue Commits Rogue Commits

Amount of commits in this package revision that are not associated with a workitem (story or defect).

Completed Activities Completed Activities

Percentage of activities that have been completed for this package revision (both automated and manual).

Delivered Package Revisions

In order to view a list of "delivered" package revisions, click on the "Deliveries" icon on the upper right hand side of the screen.

Deliveries Icon

A list showing details of all deliveries across package will be shown.

Deliveries

  • Was this article helpful?