Skip to main content
System StatusContact Support
VersionOne Community

Continuum Flow Packages

Packages are used as a central object for aggregating releasable "revisions" of software.

Overview

Virtually every organization has unique and customized processes for "Release Management". This makes sense, as the release process is tightly coupled with the application architecture and organizational structure.

In almost all cases, tools for Release Management are already in place, and processes are firmly established well before an organization decides to jump on the 'agile' or 'continuous' bandwagon.

In order to accommodate the very diverse procedures for tracking releases, Continuum takes a more general approach. Rather than dictate rigid rules and procedures for identifying a 'release', Continuum instead provides several consolidation objects and mechanisms for aggregating Pipeline Manifests. One of these objects is called a Package.

A Package is essentially a persistent, named Manifest. (Recall, a Manifest is simply the payload of a Pipeline Instance.)

Why Use Packages?

As with any system, different Continuum objects are generally designed to fulfill certain roles. For example, obviously Pipeline Instances are the consolidated historical record of what happened when Changes and work items passed through a Pipeline Definition.

Similarly, since Changes come into Continuum by submission into a Project, the Project can be versioned and each version contains a growing Manifest of Changes and work items until such a time as the Version is incremented, effectively 'closing' the previous version.

While both these objects serve their purposes well, neither is quite flexible enough to accommodate all the various of 'versioning and release' scenarios we encounter.

In part, Packages are meant to close that gap. A Package essentially represents whatever you want it to represent, and this purpose can be described by the name of the Package. Depending on the design of your Pipelines and the use of Packages, they can range from as formal as MyApp Release 12.4 to as casual as Stuff Done in Branch 'foo'.

Most of the time, however, Packages are used as a central object for aggregating a 'Release Notes' manifest. Many Pipelines and many Projects can all add items to a Package, making it very useful for this purpose.

Finally, while Packages are obviously useful as a reporting mechanism, several additional features make Packages even more powerful.

Through the use of additional Pipeline functions, Packages can be loaded into a Pipeline. This is very helpful downstream, where late-stage bundling and deployment pipelines run at a lower frequency than early build/test Pipelines.

Packages also have a Globals document, and can therefore serve as a detached data registry to persist variables across Pipelines and Projects.

Creating Packages

As you know, most things in Continuum happen automatically, and the creation and management of Packages is no different. Packages are created automatically by rules within Pipelines.

Typically based on your internal versioning scheme, when Pipelines run to perform the work of building, testing, or deploying code, the Pipeline will make the decision to append it's Manifest to one or more Packages. If the specified Package doesn't exist, it will be created and start accepting additions.

Viewing Packages

Packages are first and foremost a reporting concept, and most typically used as a consolidation of the Manifests of a range of Pipelines. In Continuum, Packages can be viewed via the Perspectives menu.

Additionally, any Pipeline Instance which appends it's Manifest to a Package will have a link to that Package.

Package Globals

Similar to Pipelines and Projects, a Package has a data registry, or Globals. Yet quite different from Project Globals, Package Globals are available across all automated uses of the Package, even by different Pipelines in different Projects. Package Globals are therefore a very useful place for setting various variables necessary for complex delivery Pipelines.

The Instance Workspace key containing the Package Globals is configurable. Since an Instance can load more than one Package, take care when selecting a key to hold the Globals.

 

Workspace keys cannot contain dots, and dots are common in Package names. Be careful!

 

Package Functions

For developers, the following Package functions are available in the Flow Plugin:

Add Manifest

The Add Manifest function will take the Manifest of this Instance and add it to an existing Package. If the Package does not exist, the function will optionally either fail, or create the Package.

Adding to a Package can optionally pull Package Globals into the Instance Workspace.

Properties

  • Package Name - (required) - The name of the Package.
  • Create? - (optional) If 'true', will create the Package if it does not exist, otherwise the Instance will end in Failure.
  • Globals Key - (optional) If specified, Package Globals will be loaded into the provided Workspace key. (Dotted path notation is allowed.)

Load

The Load Package function will bring the entire contents of a Package into the Instance Manifest. Existing Manifest items will be preserved. The function can optionally fail if the Package does not exist.

Package Globals are added to the Instance Workspace when a Package is loaded, if a Key Name is specified.

 

Any Artifacts in the Package will be added to the Instance as Input Artifacts.

 

Properties

  • Package Name - (required) - The name of the Package to load.
  • Globals Key - (optional) If specified, Package Globals will be loaded into the provided Workspace key. (Dotted path notation is allowed.)
  • Required? - (optional) If 'true', the function requires the Package and will fail if it is not found.

Set Global

The Set Global function will set a value in the Package Globals. If the Package does not exist, the function will optionally either fail, or create the Package.

 

This function will NOT append to the Manifest of the Package, rather only updates the Package Globals.

Properties

  • Package Name - (required) - The name of the Package to load.
  • Key - (required) - Key name to set. (Dotted path notation is allowed.)
  • Value - (required) - Value to set.
  • Required? - (optional) If 'true', the function requires the Package and will fail if it is not found.
  • Create? - (optional) If 'true', will create the Package if it does not exist, otherwise the Instance will end in Failure.

 

Create and Required are mutually exclusive, and if Create is 'true' it takes precedence.

Get Globals

The Get Globals function will import all the Package Globals into the Instance Workspace.

 

This function will NOT load the Package Manifest, rather only imports the Package Globals.

Properties

  • Package Name - (required) - The name of the Package to load.
  • Globals Key - (optional) If specified, Package Globals will be loaded into the provided Workspace key. (Dotted path notation is allowed.)
  • Required? - (optional) If 'true', the function requires the Package and will fail if it is not found.

Close

The Close function will close the Package and update timestamps and metrics.

Closed Packages can no longer accept any additions, and any Pipelines attempting to add to a closed Package will fail.

Properties

  • Package Name - (required) - The name of the Package to load.
  • Globals Key - (optional) If specified, Package Globals will be loaded into the provided Workspace key. (Dotted path notation is allowed.)
  • Required? - (optional) If 'true', the function requires the Package and will fail if it is not found.
  • Was this article helpful?