Skip to main content
System StatusContact Support
VersionOne Community

Continuum Flow Project Versioning


As we've learned earlier, Projects can represent several things - a source code repository, a collection of integration processes, or even just a general collection of automation.

Projects also include an extremely powerful concept - Versioning. Just like your real world software release process, Continuum Projects can have many versions, and many of these versions can be active at any time.

We realize the number of versioning schemes in the wild is only limited to the creativity and constraints of every single software shop! So, our approach to versioning is equally as flexible - ranging from 'whatever you want to do' to allowing you to utilize our own built-in scheme.

Additionally, the notion of version spans the entire application, from the top level Product, down through modules and services, even possibly individual objects.

Zen and the Art of Figuring Out the Version

As stated earlier, determining the version can be tricky - version identifiers can live in the source code, in a VERSION file, or be dynamically created by a build script, packaging script, etc. The source of the canonical version can vary wildly. So, how do we approach figuring out the version? One step at a time. :-)

The Submission

First, it's important to remember - one of the foundational features of Continuum is capturing the constant stream of change coming from source code repositories into Projects. This is our first touch point of changes, as well as the first attempt to affiliate Changes with work items from the planning/issue management system.

For example, where multiple versions of an application or service are supported, these versions are typically separated into version branches in the SCM system. This information is known in the Submission, so a first attempt at affiliating the payload (and any work items we lookup) with a Project version is done here.

For example, you may have version branches representing 1.0, 1.3 and 2.0, all of which are still currently in production for various reasons.

So, in this case when Continuum accepts a Submission from SCM, we'd use the branch identifier as the version.

But my version scheme is more complex than that!?!

Of course it is, but is your full versioning scheme known in the webhook data from Github? Maybe, but likely not.

Further refinement of the Version takes place as the change manifest progresses through it's respective Pipelines.


Let's carry on with our example. Say a new commit was made to the 1.3 branch. Continuum will assign the incoming Submission to 1.3, affiliate any work items, and kick off the first Pipeline. For simplicity let's assume the first phase is just a build.

The build process will do what you'd expect - check out code and build it! You already have this process in place, so let's presume for a moment the build number is the missing link to your versioning scheme. After this build is complete, you'd be calling this 1.3.747.

Perfect. Since the new version number is now known in the Pipeline, you can simply tell the Pipeline to Reassign it's current Manifest to the updated version scheme. Congratulations, all the Changes and work items from the Submission are now flagged 1.3.747.

Wrapping Up

This is clearly a whirlwind overview of one example of grouping your data using Versioning. While the final process may be more complex, the principle of Initial Assignment followed my multiple Refinements can easily move your payload all the way to release with exactly the numbering scheme you prefer.

  • Was this article helpful?