Skip to main content
System StatusContact Support
VersionOne Community

Setting Up Your First Continuum Project

Overview

This guide will walk you through setting up a full end-to-end software development project in Continuum; it is meant to serve both as a starter to setting up AND understanding its data model. It will additionally cover some core concepts in Continuum.

Goals

Continuum's primary goal is to provide visibility and insights into the way you develop and deliver software. It achieves this by modeling the value-stream you use to deliver software to end users and by measuring the value that is flowing through the value-stream. It additionally serves as a full Release Management and Orchestration platform, serving as a single pane of glass to both manage and orchestrate all the tools in the toolchain.

Using Continuum should not initially signify any change to your existing process, it will simply collect data about the way you currently develop software and enable you to automate as little or as much of that process as you like. The more it is used, the more data and business intelligence it will provide, allowing you to identify areas of opportunity where change will be beneficial; it will help you learn to get better.

Stack

In order to obtain the full value of Continuum, the following components are considered:

  • ALM System: An Application Lifecycle Management platform, such as VersionOne Lifecycle
  • VCS System: A Version Control System, such as GitHub
  • CI Server: A Continuous Integration solution, such as Jenkins
  • CD System: A Continuous Delivery or Deployment solution, such as Octopus

High-Level Workflow

Continuum aims to bring you unparalleled visibility into the value that is flowing through your value-stream. It achieves this by affiliating code commits to business value, generally in the form of workitems (stories or defects). Once the affiliation is made, the value is then transported through the value-stream in a "package revision". Moving through the value-stream means going through a set of activities and controls that have been previously defined for each of its phases, with the ultimate goal of delivering the value to the end user. We will elaborate on each of these concepts throughout the guide.

Navigating Continuum

Continuum navigation has two main components:

Top Navigation Bar

topnav.png

The top navigation bar enables you to access the following components:

  1. Home button
  2. Search bar
  3. Administration
  4. My Account
  5. Information

Note the the "Administration" button is how we access all configuration aspects of Continuum.

Taskbar

taskbar.png

The taskbar enables you to access data and information that has been generated by previously configured items. Here you can access the following:

  1. Home Button
  2. Projects
  3. Progressions
  4. Pipelines
  5. Tasks
  6. Perspectives
  7. Insights
  8. Canvas

Configuring Plugins

Before Continuum can communicate with each of the tools in your stack, you will need to configure the relevant plugin. To do so:

  1. Click the administration icon administration.png on the top navigation bar
  2. From the middle column, select "plugins"
  3. On the left hand side of the screen, select the plugin you wish to configure
  4. Fill in the relevant data for the selected plugin

Plugins will generally require the following values:

  • Name
  • token (or username/password)
  • URL

You can name instances of your tools whatever you like, but it is important to remember the names you have assigned when you are working with multiple instances. Additionally, some plugins will require the base URL for the API for the particular plugin. For this particular guide we will setup ALM (VersionOne Lifecycle), CI (Jenkins), CD (Octopus). and VCS (GitHub).

Creating a Progression

A progression in Continuum is a digital representation of your value-stream; 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). As software moves through the value-stream it undergoes a number of activities which make it more mature as it goes through the phases until it is finally ready to be delivered. Once software is delivered it will no longer appear in the progression.

Phases are serial in nature and follow the assumption that you will not move to the next phase until all the activities in the present phases have been satisfied. Phases should be defined by a group of common activities that may be heterogeneous in nature; for example a "testing" phase may include all manual and automated testing activities for the particular revision.

Different products or services may follow different progressions. For the purpose of this guide we will create a single progression.

  1. Click the administration icon administration.png on the top navigation bar
  2. From the middle column, select "Progressions"
  3. On the left hand side of the screen, click "Add New"
  4. Provide a "name" and a "description" and click "create"

Once the progression has been created it's time to add the relevant phases. To do so:

  1. Click the "Add Phase" button on the right hand side
  2. Provide a phase name and description, click "Add"
  3. Repeat as necessary for all relevant phases

For the purpose of this guide we will create the following phases for the "E-Store" progression:

progression.png

You will notice that each phase has a radio button to the left of its name. This is the "code complete" designation, that is, when a package revision arrives at this phase, we consider the software to be "code complete" and ready for user consumption. This is later used for reporting purposes.

Name phases with care as they cannot be renamed.

Creating a Package

A package in Continuum represents a discrete product or service being delivered; for example if you use a micro-services architecture, a package would represent each micro-service. Conversely if you use monolithic products, a package would represent each application or each tier of the application (i.e. database, server, front-end). A package is then assigned to a "Progression" which will define what phases it flows through.

  1. Click the administration icon administration.png on the top navigation bar
  2. From the middle column, select "Packages"
  3. On the left hand side of the screen, click "Add New"
  4. Provide a "name" and a "description" and click "create". For the purpose of this guide we will name the package "mobile"
  5. Click the "Progression" tab and select the "E-Store" progression from the drop-down

We won't be creating any activities yet as we have to define the process our package goes through and create the matching pipelines

Creating a Project

Projects in Continuum are generally mapped to a repository in your VCS. This is where Continuum receives change from your VCS (via webhooks) and decides what to do as commits are received for a particular repository. The webhook payload contains information about the commit that Continuum will use to start tracking the changes and to initiate your pipelines. Continuum will identify the work items that were referenced by these commits. The affiliation of commit to workitem is what enables Continuum to track the flow of value; finally, the resulting package revisions created from these submissions are what flow through the value-stream.

  1. Click the administration icon administration.png on the top navigation bar
  2. From the middle column, select "Projects"
  3. On the upper right hand side of the screen, click "Add New". You can either use the wizard or select "manually", for this guide we will create the project manually. Click "next"
  4. Provide a "name" and a "description" and click "create". For the purpose of this guide we will name the project "mobile"
  5. Click on the new "mobile" project on the left hand side of the screen, from the "Type" dropdown, select "Source"
  6. Click on the "Artifacts" tab and click "Add New". We'll use "mobile app" as our first artifact
  7. Click the "Source" tab, on the "Changes From" drop-down, select your VCS. For this guide we will use "GitHub Webhook"
  8. Copy the "Webhook Endpoint" URL and create a webhook in your repository using this URL (be sure to replace the <api token> tag with the actual token which can be obtained by clicking on image.png My Account >> Account Details)

By default, the "use as group" value is set to "source branch" which we will leave as-is for this exercise. The "group" value indicates how to group the commits that are coming in. The default value of "source branch" is indicating that our commits are grouped by the Git branch that is related to the change.

Creating Project Directives

Project directives tell Continuum what to do with the submissions (commits) that it receives. We will create one directive to identify Lifecycle workitems related to the incoming commit and another to create a package and put it in our first phase so that activities can start. The same process could be followed for looking up workitems in other ALM systems such as TeamForge or Jira.

1st Directive - Identify Lifecycle workitems:

  1. With the "mobile" project selected, navigate to the "source" tab
  2. Click the "Add" button on the lower right hand side of the screen
  3. Expand the newly created directive by clicking anywhere on the row
  4. Under "Action" select "VersionOne Lifecycle Lookup" and leave all the default values

We are working with the assumption all commits will follow this process, however, if you wanted commits only for a certain branch (say master) to follow this process, you could change the "when" parameter to "evaluate" and state the conditions to follow.

2nd Directive - Create a package revision and put in the first phase:

  1. While on the project "source" tab, click the "Add" button on the lower right hand side of the screen
  2. Expand the newly created directive by clicking anywhere on the row
  3. Under "Action" select "Package Into Phase"
  4. Under "Package Name" type in "mobile"
  5. Under "Start in Phase" type in "Building"

Let's assume we only want to build from commits coming from our "master" branch, and thus we only want to "package into phase" when branch = master. To do this, click on the "When" drop-down and select "Evaluate" and insert the following:

ref in ["refs/heads/master"]

Create Project Globals

Creating project globals allows you to reuse Continuum objects in multiple projects. We will setup the following globals for this project:

  1. While on the "Manage Projects" screen, click the "Globals" tab
  2. On the "empty object" row, click the box icon and select "Append". Do this once for each global and enter the following globals:

    buildJobName   :  JenkinsBuild
    buildJobServer :  Jenkins
    artifactName   :  mobile
    version        :  1.0

Continuum auto-detects the type of data you enter. For the version value it will want to treat it as a number but we want it to be a String so that the value is stored as “1.0” and not “1”. If you click on the icon next to the key name, a menu pops-up and you can click on Type and change it from Auto to String.

Be sure to click the "Save" button once you are done.

Set Project Version

In order for all activity to be properly grouped we will assign a starting version to our project. This can be changed later as you work on new versions and close out old ones.

  1. While on the "Manage Projects" screen, click the "Versions" tab
  2. On the "Current Version" textbox, enter "1.0" and click "Update Version"

Creating the Artifact

The Continuum artifact definition will be the representation for the counterpart produced by the CI server.

  1. While on the "Manage Projects" page, with the "mobile" project selected, click on the "Artifacts" tab
  2. Click "Add New"
  3. Name the artifact "mobile"
  4. Click the "Add Artifact" button

Creating Pipelines

Most of the automation work in Continuum is managed by a high-level concept called a Pipeline. A Pipeline consists of a series of synchronous Phases, and each Phase can contain one or more asynchronous Stages. Pipelines carry out automated activities such as running a build process or changing the status of a work item after a successful deployment. Pipelines are also used to create and manipulate the objects in Continuum such as setting a version number on a package based on a build result or promoting a package in a progression.

Each automated "activity" in your value-stream should have a matching pipeline; this means that we will need to create multiple pipelines for our test project. Additionally, each activity will have a matching "control" which is the mechanism that will determine if your software can move on or stop.

Before you dive in and start creating pipeline, it will be useful to model your process to get an idea of the pipelines you will need. For the purpose of this guide we will think of the following activities:

Phase: Building

  • Activity 1: Build (Auto)

Phase: Testing

  • Activity 1: Automated Testing (Auto)
  • Activity 2: Manual Testing (Manual)

Phase: Staging

  • Activity 1: Staging Tests (Auto)

Phase: Ready for Delivery

  • Activity 1: Release Notes (Manual)

As you can see we have some automated activities and some manual activities. We will only create pipeline for the automated activities; manual activities will be assigned to individual users when we configure the package progression.

Another important concept to know is that when a Pipeline runs it has something called a Workspace which is a set of json data with information about the running pipeline instance. The workspace contains data that might have been passed into the instance as part of initiating it and it can also be used to store data as the pipeline runs, so you can pass along information from one step to the next. The data in the workspace is referenced using a syntax like this:

[$ keyname[“subkeyname”] $]

When you view a pipeline instance, either while it is running or after it runs, you can see the workspace data and explore the json structure. This is useful for getting an idea what data is available and what the key names are, etc.

Now let's create pipelines for each of our automated activities:

Build Pipeline

Step 01 - Jenkins Build

  1. Click the administration icon administration.png on the top navigation bar
  2. From the middle column, select "Pipelines"
  3. On the upper right hand side of the screen, click "Add New"
  4. Enter "Build" on the name field and click "Create"
  5. On the pipeline editor you will notice the initial "phase" and "stage" has been created for you
  6. On the "Phase" textbox enter "Build"
  7. On the "Stage" textbox enter "Jenkins Build"
  8. Click on the Jenkins plugin on the left hand side and then click and hold the "Build" directive and drop it into your stage. Use the following parameters:
    • Execute: Always
    • Job Name: Mobile App
    • Parameters: (leave blank)
    • Wait: True: (leave blank)
    • Inherit Job Status: False
    • Regular Expression: (leave blank)
    • Value to Set: (leave blank)
    • Jenkins Instance Name: (leave blank)
    • Result Key: BuildResults (This parameter allows you to store information about the job in the workspace, using the key name that you specify here)

Your configuration for this stage should look as follows:

Jenkins_Build.png

Step 02 - Create Artifact

Creating an artifact allows Continuum to track it and refer to it when necessary. This could generally be a binary artifact like a .tar, .jar, .exe, etc. This does not involve uploading an actual instance of the artifact but simply entering its definition.

  1. While on the pipeline editor page, Click on the "Flow" plugin on the left hand side of the screen
  2. Click and drag the "Artifact - New Revision" function onto to the pipeline editor, use the following values:
    • Execute: Conditionally
      We are only going to execute this step if the build is successful. Enter the following expression to evaluate:
      BuildResults['details']['result'] != "FAILURE"
       
    • Project: __PROJECTNAME
      We using a global constant as specified in Continuum Plugin Arguments and Variables
    • Artifact Name: [$ projectglobals["artifactName"] $]
      We are using the project global variable we previously created.
    • Package Name: [$ initiator['package_revision']['name'] $]
      Here we will reference data from the workspace as our pipeline will be executing in the context of a package (and we want to add the artifact as data to the package).
    • Package Revision: [$ initiator['package_revision'][‘revision’] $]
      Here again we will reference data from the workspace as our pipeline will be executing in the context of a package (and we want to add the artifact as data to the package).
    • Branch: __GROUP
      We are using a global constant to specify the branch this artifact is associated with.
    • Location: (leave blank)
    • Version: [$ projectglobals['version'] $].[$ BuildResults['build'] $]
      We are combining the project global with the build number to generate the version number.
    • Build Identifier: [$ BuildResults['build'] $]
      We are referencing the build number from our variable.
    • Build URL: [$ BuildResults['url'] $]
      We are referencing the URL from our variable.
    • Build Details: (leave blank)

Your configuration for this stage should look as follows:

Flow_Artifact_NewRevision.png

Step 03 - Rewrite Revision

Each time the build runs we will update our version number so that the package matches the version of the build.

  1. While on the pipeline editor page, Click on the "Flow" plugin on the left hand side of the screen
  2. Click and drag the "Package - Rewrite Version" function onto to the pipeline editor, use the following values:
  • Execute: Conditionally
    We are only going to execute this step if the build is successful. Enter the following expression to evaluate:
    BuildResults['details']['result'] != "FAILURE"
  • Package Name: [$ initiator['package_revision']['name'] $]
  • Revision: [$ initiator['package_revision'][‘revision’] $]
  • Full Version: (leave blank)
  • New Version: [$ projectglobals['version'] $]
  • New Full Version: [$ projectglobals['version'] $],[$ BuildResults['build'] $]

Your configuration for this stage should look as follows:

Flow_Package_RewriteVersion.png

Step 04 - Set Activity Control

When we specify the flow of a package through our progression, we will need both activities and controls. Each activity will reference an existing pipeline or a discrete manual interaction; the ones that reference a pipeline will need a dedicate control to indicate to Continuum whether this package can move on down the progression or if the process should stop because our conditions have not been met. In this particular case, the control will identify if the build was successful and only move on if that condition is true.

  1. While on the pipeline editor page, Click on the "Flow" plugin on the left hand side of the screen
  2. Click and drag the "Package - Set Activity Control" function onto to the pipeline editor, use the following values:
    • Control Name: Build Successful
    • Result: [$ "pass" if "[$ BuildResults['details']['result'] $]" == "SUCCESS" else "fail" $] 
    • Details: (leave blank)

Your configuration for this stage should look as follows:

set activity control

For the purpose of this guide we will skip creating the "testing" pipelines as they will be very similar to the above. They will basically call a Jenkins job and perform some form of automated testing and move forward only if the testing is successful or meets the conditions we've specified. After all testing and manual activities have passed, it is time to deliver our package revision to production.

Deliver Pipeline

The delivery pipeline will execute the actual delivery job into the production environment via Octopus and if successful, it will mark our package revision as "delivered" as well. This will cause the package revision to no longer show in progress (will not show on the progression board) and will appear in the list of "deliveries".

Step 01 - Octopus Deploy

  1. Click the administration icon administration.png on the top navigation bar
  2. From the middle column, select "Pipelines"
  3. On the upper right hand side of the screen, click "Add New"
  4. Enter "Deliver" on the name field and click "Create"
  5. On the pipeline editor you will notice the initial "phase" and "stage" has been created for you
  6. On the "Phase" textbox enter "Deliver"
  7. On the "Stage" textbox enter "Deploy"
  8. Click on the Octopus plugin on the left hand side and then click and hold the "Deploy" directive and drop it into your stage. Use the following parameters:
    • Environment Name: production
    • Project: mobile
    • Release: [$ projectglobals['version'] $]
    • Additional Arguments: (leave blank)
    • Wait: true
    • Inherit Build Status: true
    • Octopus Instance Name: (leave blank)
    • Result Key: DeployResults

Your configuration for this stage should look as follows:

OctopusDeploy.png

Step 02 - Deliver Revision

  1. While on the pipeline editor page, Click on the "Flow" plugin on the left hand side of the screen
  2. Click and drag the "Package - Deliver Revision" function onto to the pipeline editor, use the following values:
    • Execute: Conditionally
      We are only going to execute this step if the deploy is successful. Enter the following expression to evaluate:
      DeployResults['details']['result'] != "FAILURE"
    • Package Name: [$ initiator['package_revision']['name'] $]
    • Revision: [$ initiator['package_revision']['revision'] $]

 Your configuration for this stage should look as follows:

Flow_Package_DeliverRevision.png

Configuring the Package

Now that our pipelines have been setup we are ready to setup the activities and controls that our package will go through when it enters the progression. Because each automated activity must reference a pipeline, they must be created first.

Activities and Controls have categories and estimates in order for Continuum to gather metrics. You can read more in Package Activities and Controls.

Each activity for the packages will map to a previously created pipeline or a manual activity that will be created on the spot. The "definition" value of an activity refers to a "pipeline definition".

  1. Click the administration icon administration.png on the top navigation bar
  2. From the middle column, select "Packages"
  3. On the left hand side of the screen, select the "mobile" package
  4. Click the "Progression" tab and create the following activities & controls for the corresponding phase by clicking the activity_button button to add an activity and the controlbutton.png button to add a matching control to each automated activity. Note that the "control" button will only appear after you've added an activity.

Phase: Building

Activity Name: Build
Description: Run Jenkins Build
Category: Value Added
Estimate Touch Time: (leave blank)
Type: Initiate Pipeline
Definition: Build
Group: (leave blank)
Project: mobile
Initial Data: {}

Control Name: Build Successful
Description: The build has finished successfully

Phase: Testing

Activity Name: Automated Testing
Description: Run Jenkins Testing Job
Category: Value Added
Estimate Touch Time: (leave blank)
Type: Initiate Pipeline
Definition: Automated Tests
Group: (leave blank)
Project: mobile
Initial Data: {}

Control Name: Automated Tests Successful
Description: Automated tests finished and are 100% passing

Activity Name: Manual Tests
Description: Run all manual tests
Category: Quality
Estimate Touch Time: 4
Type: Manual Activity
Assign To:Administrator
Tags: (leave blank)
Title: Manual Tests
Text: Please enter manual tests results
Notes Required: (leave unchecked)

Control Name: Manual Tests Successful
Description: Manual tests performed and score is greater than 95%

Phase: Staging

Activity Name: Staging Tests
Description: Run Jenkins Staging Test Job
Category: Value Added
Estimate Touch Time: (leave blank)
Type: Initiate Pipeline
Definition: Staging Tests
Group: (leave blank)
Project: mobile
Initial Data: {}

Control Name: Staging Tests Successful
Description: Staging tests finished and are 100% passing

Phase: Ready for Delivery

Activity Name: Release Notes
Description: PM to produce release notes
Category: Non-Value Added (necessary)
Estimate Touch Time: 4
Type: Manual Activity
Assign To:Administrator
Tags: (leave blank)
Title: Release Notes
Text: Please paste release notes below
Notes Required: (checked)

Control Name: Release Notes Delivered
Description: PM has entered release notes

Check the "Promote Automatically" checkbox so that your package revision moves through the progression automatically.

Your progression for the "mobile" package should look as follows:

mobile_progression.png

Submitting Change (Code Commits) to the Progression

Once all the configuration for the software project is in place, we are ready to start putting package revisions through our progression.

Note: It is imperative that all code commit comments for your project mention the workitem that they are related to; if code is not affiliated to workitems, your package revisions will appear empty. As long as your code commit contains the workitem, artifact, or issue Id somewhere within it, affiliation should work property. For example:

S-12345 new method to support tap payments

Make a change to any file on your project and push it to the remote, this is all that is needed to kick off the process. Once your have pushed your changes click on the "progression" tab in the navigation bar. The package revision on the board should look something like this:

revision.png

Since we configured the progression to automatically promote if the activity is successful, your package revision should be on the "Testing" phase of the progression. You will now have pipeline instances available for auditing under "Pipelines >> Instances". The package revision will not be waiting for manual activities to be executed.

Executing Manual Activities

Our Package has now moved to the "Testing" phase. Note that the version number of the Package was changed to match the value we configured which was a combination of a version number we entered in our Project Globals and the build number.

If you configured your package to assign this step to a specific user(s), they will have received an email notification and the link would take them to a screen where they can manually confirm the action is completed. We can get to that same screen by clicking on the Package revision number in the bottom right corner of the Package card. 

Package Revision Link

Clicking on the activity name title (Manual Testing) will bring up the manual steps related to this activity. A tester could come to this screen and click the Start Working on This button to signal that they are the one doing the testing, so that someone else does not bother to "take" this activity. Other than that, the controls that we entered show on this dialog. A user can click the check mark if they have completed the task, or the X if the control failed. There is also a Mark as Failed button to indicate the failure. This would generally mean that this revision of the package has failed and is not going to go any further in the progression. Presumably, a new commit will happen that fixes the problem and this will trigger a new build that creates a new version of the package.

Assuming all the tests pass and the user clicks the check on all of the controls, the dialog will look like this:

Manual Activity Dialog

The "Mark as Complete" button is now enabled and can be clicked. The way we have configured our Progression it means the package will be promoted to the next phase.

The same process is followed for the manual activities in subsequent phases until the package is ready for delivery.

Delivering the Package Revision

Once both manual and automated activities have completed, the "deliver revision" directive will take place. Once the package is "Delivered", it will be removed from the board.

There are multiple ways to execute the delivery directive, both automated and manual. Because most companies like to be 100% in control of the timing of releases, we will create a manual activity called "Deliver to Production" in our "Ready for Delivery" phase. We will then create an automated activity that will perform the actual production deployment using our deploy tool (in our case, Octopus).

Create a manual activity as follows:

Phase: Ready for Delivery

Activity Name: Deliver to Production
Description: Signals the production delivery pipeline
Category: Non-Value Added (necessary)
Estimate Touch Time: 
Type: Manual Activity
Assign To:Administrator
Tags: (leave blank)
Title: Deliver to Production
Text: Delivery the package revision to production environment
Notes Required: (leave unchecked)

Control Name: Deliver to Production
Description: (leave blank)

 

We will now create an automated activity that calls the previously created "Deliver" pipeline, as follows:

Phase: Ready for Delivery

Activity Name: Deliver
Description: Deliver the release to production
Category:
Estimate Touch Time: (leave blank)
Type: Initiate Pipeline
Definition: Deliver
Group: (leave blank)
Project: mobile
Initial Data: {}

Since we configured packages to automatically promote, once you package reached the "Ready for Delivery" phase and both manual activities on this phase are completed, you can see all deliveries for this progression by going to the progression and clicking the "deliveries" icon.

Deliveries Icon

If you need help along the way please don't hesitate to reach out to us at support@versionone.com

 

Happy hacking.

  • Was this article helpful?