Skip to main content
System StatusContact Support

Documentation related to the following products will soon be moved to a new portal: ( Agility, Agility Connect and Agility Integrations Continuum and ALM Connect
Links from the site will automatically redirect to the new site.
If you have any questions, please contact Support. Agility Community

Continuum Flow Introduction


Continuum Flow provides a flexible user interface that supports pipeline modeling and real-time reporting of pipeline status, past and present. Flow can be used to marshal software commits through the build, test, system all the way to deployment in production.


In Flow, all work on a specific project or initiative 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.

For example:

  • Phase One
    • Stage Alpha
    • Stage Delta
  • Phase Two
    • Stage Omega

A Pipeline is simply a definition of a workflow. An implementation of a Pipeline Definition to consider work submitted to a specific Project is called a Pipeline Instance. A Pipeline Instance is is the record of the automation initiated by the submission of work, and the history of what happened to that submission.
A Pipeline Instance can execute work, gather information, or both at each Stage of the Pipeline.

A new Pipeline Instance is created each time the Pipeline is initiated. This initiation is typically an API call from an external system such as GitHub or VersionOne Lifecycle.

For the sake of discussion, let's consider a very simple pipeline representing the potential process of a change:

  • build
    • run a build job
  • deploy
    • install code in an environment
  • test
    • perform automated testing
  • deploy
    • install code in a more production-like environment
  • regression test
    • perform more comprehensive testing
  • deliver
    • deliver code to another environment, for more formal QA, or even into production

In this example, the initiator would be a git commit hook that tells Flow to kick off a new Pipeline Instance. The first Phase will send a signal to a build tool (such as Jenkins) to build the recently committed code. Once the build is successful, the second Phase will take the artifact (binaries, installer, etc) created by the build and deploy it to an environment. (This environment may be pre-defined but in most cases is provisioned on demand then torn down after use.)

If automated testing is successful, code is deployed again into a more formal production like environment, and more comprehensive testing is performed. When all steps complete satisfactorily, the change is published.

That's a very basic and quick introduction to the concepts of Continuum Flow. Look at the Tutorials, and other pages in this documentation for more in-depth details.


The Groups page shows the current disposition of each Pipeline Group, and is most often used as a the de facto 'dashboard' for the current health of the delivery process overall. The 'Activity' tab shows all Groups in a table format, and the Status tab shows the details in vertical good/bad slices to give a different perspective of the health and history of a specific Group. (The Status tab is the "everything is green ... I can go home" view.)

A Group is one of the terms in Continuum that often takes more than a moment to understand, so I'll recap.

The terms Pipeline Instance Group, Pipeline Group, Pipeline and Group are all basically synonymous, which understandably lends to the confusion, but the definition is simple:

A Group is a unique object with a three-way key - a Project, a Pipeline Definition, and a Group label. This allows for Definitions to be used across projects, as well as for content (from different branches for example) in the same Project to use the same Definition.

The simplest example is one Project, one build pipeline, but multiple active branches. In this case, each branch would be a different Group and can be separated accordingly, even though commits from any branch belong in the same Project and are build by the same Definition.

With that explanation, the Groups page in Continuum shows the overall status for each Group - including the last Instance and it's status. If there are active instances in a Group, the row can be expanded to see at least the top 10 active Instances.

Group Detail

Drilling into a specific Group will open the Group Detail page. This page has several tabs:

  • Summary. A Summary dashboard of various metrics for the Group, the most popular being a visualization of which Phase takes the most time averaged across all Instances, as well as various success/fail percentages.

  • Staged Data. One of the features of a Group is it's ability to allow other pipelines to 'stage' data for a future Instance in this group. Staged data can either be placed here by upstream pipelines, or may represent data from previous Instances that ended in failure. This tab shows any data waiting for the next Instance.

  • Instances. Shows the Instances within this Group.


The Instances page is the most commonly used page in Continuum. Here's where you'll see every Pipeline Instance, it's end status and duration. Filters allow you to customize the view, to find those Pipelines you're interested in monitoring. (Filters are sticky - whatever you select will remain on future visits to the page.)

Target audience is those who are interested in watching all the pipelines, monitoring for failures, and following up to reconcile those failures.

Instance Detail

The Instance Detail is probably the most robust detail page in Continuum. This page shows all the information gathered by a single Instance - which plugins it used, the custom responses of those plugins, the Workspace data, and the Manifest of items considered by the Instance.

The Instance Detail page is segregated by Tabs:

  • Summary. Left side of the page is the Pipeline Progress, presented as a vertical stack of Phases and their duration. Clicking on one will show what happened in that Phase (Stages and Steps), and various plugins will often present links to even deeper detail.

    Right side of the page are additional summaries that may appear based on exactly what the Instance did.

    Global Summary may display customer-defined data such as additional hyperlinks, or details from the Workspace.

    Plugin Summary will show plugin-specific details all in one place. (The same information is presented in the Pipeline Progress in the context of when it was gathered, whereas in the Plugin Summary all the data for a specific plugin is consolidated.

    Labels are often set by plugins. Labels can be used for advanced and customized reporting.
  • Manifest

    The Manifest tab shows the set of Changes, Workitems, and Artifacts that were "in" this Instance alone. In cases where a Pipeline is initiated by a change submission, such as a GitHub push, the Manifect will reflect the contents of that submission. For downstream or manually initiated Pipelines, the manifest will contain all items since the last successful Instance in that Group.

    There are a few rules that apply to Instance Manifests:
    • If an Instance fails, the contents of the Manifest remain, and are included in the next Instance.
    • When an Instance succeeds, the Manifest is cleared of all items, and the next Instance will start fresh.
    • If a Pipeline Group is set up to be initiated by, or receive input from, an upstream Pipeline, the Manifest will accept 'staged' input data until the next Instance runs. (Staged data for a future Instance can be seen by looking at the Group Detail page.)
  • Workspace
    An Instance Workspace is the container of all data collected by the Instance. It starts with data passed in when the Instance is initiated (for example a GitHub webhook payload). Each Plugin that executes as the Instance progresses can both read and write to the Workspace. In the actual code of a Pipeline, when [$ variables $] are used, they read their values from the Workspace.

    When an Instance is completed, inspecting the Workspace is used in conjunction with the Logs to determine the cause of a failure. The Workspace also represents a powerful audit mechanism - it's basically a snapshot of the state of things when this Instance ran.
  • Actions
    A developer might have defined ad-hoc Actions that can be executed in the context of an Instance. This is most commonly used to kick off 'after the fact' automation using the Instance as a starting point. Additionally, for Instances with Manual Interactions, Actions are very useful for allowing users to perform manually initiated automation routines as part of the validation workflow required for that manual step.

If no Actions are defined, the Actions tab will be hidden.

  • Phases
    The Phases tab is a different view of the complete workflow of the Pipeline. Where the Summary tab shows Phases as a vertical, accordion style list, the Phases tab shows everything expanded, in a more traditional 'pipeline' style view.
  • Log
    The Log tab is the most useful data available on the Instance detail page when an Instance fails and the reason isn't immediately apparent. The Log tab has data in two sections:

Progress Log

The Pipeline engine, as well as some Plugins, write high level log entries here, basically tracking along the progress of the Instance. Depending on the plugin, if there are failures, the cause might be indicated here. (This varies, as each plugin is different and may or may not be able to present information at this level.)

Log File

Each Instance has a very verbose log file as well. This file also contains detailed information from the Pipeline engine for each Phase, Stage and Step, as well as Plugin specific details.

The Log file includes a basic keyword parser and highlighter. Terms such as 'Error', or 'Failure' are highlighted, and navigation buttons can jump between these markers, making it easier to find the reason the Instance failed.


The Pending page shows a list of all Instances awaiting an Interaction. Links on this page will direct to the Instance Detail page, or the Interaction can be addressed directly.


The Projects page shows a list of all Projects defined in Continuum. While a Project is quite often a one-to-one relation with a source code repository, 'Integration' or 'General' Projects are also very often used to aggregate data, especially in environments where code and configuration lives in multiple repositories.

Click here for a more in-depth look at Projects.

The Projects page has two tabs, similar to the Groups page:

  • Activity. The Activity Tab shows a list of all Projects, and their current 'status'. Since Projects are actually parents of many different Pipelines and Groups, the 'status' of a Project is calculated differently. A Project is only 'green' if all Groups in that Project are also green. The Activity tab also shows a selection of important metrics for each Project.
  • Status. The Status Tab is a vertical view of the status changes of each Project over time, and the amount of time spent in each condition. Allows you at a glance to see which Projects are the worst performers and need attention.

Project Detail

The Project Detail page provided additional information about the overall health and activity in a Project. The page is segregated into several tabs:

  • Summary. A summary dashboard displaying various metrics about the Project
  • Activity. Since a Project will contain many different Pipelines, the Summary tab shows the current condition of each Group it contains. (Selecting a Group will jump to the Group Detail page.)
  • Status. The Status tab shows vertical status changes of each Group in the Project, allowing you to quickly identify which Group is the worst performer.
  • Actions. A developer might have defined ad-hoc Actions that can be executed in the context of a Project. Actions defined at this higher level typically invoke automation that acts on the Project as a whole. Examples could be manually kicking off a Pipeline that "closes out" the current version of a Project, or perhaps manually deploying the current state of a Project to an environment.

If no Actions are defined, the Actions tab will be hidden.

  • Manifest. While at a glance the Manifest on a Project seems the same as the Manifest on a single Instance, this is far from true. A Project Manifest represents the consolidation of many different Instances over a range of time. This range of time is determined by the concept of a Project Version.

Project Version is an optional feature. If Project Versioning is not used, the Manifest represents everything that's happened in a Project since it's creation.

Click here for details about Project Versioning.

On the Manifest tab, by selecting a value from the Version dropdown, the Manifest will change to reflect the aggregate set of all items that were seen by Instances in that Project Version.

Additionally, if interested, a range of versions can be selected to see a Manifest representing all the change across several Versions.

Project Versioning is a very customer-specific decision, and can be managed either manually or automatically. When managed manually, an administrator will occasionally edit the Project and increment the version, basically resetting the Manifest and 'closing out' the previous version. This works for environments where the delivery process is on a manual release schedule, or the process is evolving but still includes waterfall style procedures.

In more dynamic scenarios, Pipelines themselves make decisions about Project Versions. In these cases, Pipelines are defined with code that determines the canonical version of the software being managed (commonly either read from a VERSION file in the source, or using the Continuum versioning system). When an Instance makes the decision to increment the Project Version, the Manifest is reset and the new version begins aggregating data.

A Project can have many 'active' Versions at one time. This is most commonly used where a single Project is supporting multiple official versions of the software.


The Perspectives menu provides alternative views on data collected by Continuum.


A progression is a defined set of one or more Phases through which package revisions move in order to be delivered to end users. As revisions move through the progression phases, activities may be executed and controls may be evaluated. This very important concept is defined in detail in the "Progressions" page.


The Workitems perspective is a complete list of all Workitems ever encountered by Continuum. Filterable by several dimensions, and can show the last Instance a Workitem went through.

It's a common misunderstanding that a Workitem is "in" a single Instance - this is not true. Work items appear in VersionOne Continuum when they are first mentioned in a commit message. In it's life cycle, a Work item can be touched by a number of Instances, cross many Projects, be in many artifacts, and be deployed to many environments.

When looking at the detail of a specific Work items, all these affiliations are shown, and where possible sorted with the newest affiliations at the top.


The Packages perspective is a complete list of all Packages created by Continuum automation. Packages are custom-created containers of a consolidated Manifest, and receive additions via rules in Pipeline definitions. Packages are most commonly used to represent the concept of a 'release', or for separating out 'what happened' for work items that span multiple Projects.

Click here for a more in-depth look at Packages.

When looking at the detail of a specific Work items, all these affiliations are shown, and where possible sorted with the newest affiliations at the top.


Artifacts are simply containers of specific Changes and work items. Artifacts can only be created by an Instance, and serve as another view of the Manifest of an Instance.

Artifacts will always include only the items from the Manifest of the Instance that created them. The contents of an artifact do not span instances nor versions. They are not an aggregation container, rather a simple container.

Viewing an Artifact will show it's included Changes and work items, as well as the creator Instance, and any Environments to which it was deployed.


The Find perspective is simply a way to search for a 'custom Manifest'. Find has several modes:

  • Basic. Provide a simple text string, and select an object type from the dropdown, to find items where the search parameter exists in any of the core properties.
  • Pipeline Instance Range. Provide the Name of a From and To instance, in the same Group, to see a list of items that were seen between those two Instances, inclusively.
  • Project Version Range. Provide the Name of a Project, and From and To Version numbers to see a list of items that were seen between those two Project Versions, inclusively.
  • Created Between. Provide From and To dates to see a list of items created between those two dates, inclusively.
  • Advanced. Enter a valid MongoDB query to filter the items using custom criteria. Useful for finding very precise results where the other filters are insufficient.

Hooking Everything Together

In almost every software development organization, there is a complex dance established for a) committing changes, b) building code, c) setting up a test environment, d) performing tests, e) dealing with issues and f) recommending the change for publication to production.

In almost every case, each organization has nuances that are unique. Finally, in almost every case, the organization has invested in a number of common and respected tools to assist with this process.

The power and usefulness of Continuum Flow is it's ability to work in unison with the established tools and processes, optimizing the software development pipeline by capturing data, connecting disparate tools, and unifying the end-to-end process in a single visualization.