Release and Deployment ¶

Table of Contents

Release and Deployment

Introduction ¶

Fuze provides the release and deployment mechanism for all digital assets. A release is simply a state change (with metadata) appled to a universal FuzeID. A new FuzeID is not generated for a release operation.

The terms release and deployment are used interchangeably.

When the release operation is called, the FuzeID gains 2 important metadata values:

Version

Stage

Note

Delivery requires that a FuzeID has a release status.

Version ¶

The version is a free-form string provided either by the build map, or interactively on the command line by the user. If the build map contains version information, Fuze will confirm with the user interactively whether it should use the build map version information, or whether different information should be used.

When version information has been assigned to a FuzeID (ie, it has been released), the search term version can be used to find it.

Stage ¶

The stage is the status that has been assigned to this release. You are free to define what these states mean to your release workflow. Presently, the following stages or release states are supported:

sit: System Integration and Test – You may freely transition from sit to any other state.
qa: Quality Assurance – You may freely transition from qa to any other state.
release: Released – A permanent state. Once Released, the only transition available is to Decprecated.
deprecated: Deprecated – A permanent state. Once Deprecated, the build release state cannot be changed.

Warning

The Decprecated state disables the delivery features of a released build. Plus, it is a one-way state transition.

Metadata ¶

The following shows an example of all of the current metadata captured and available for a FuzeID that has been released.

If a build has been Deprecated, the following metadata will be shown:

Release Stages ¶

This section describes the stages, or state machine for release metadata.

Requirements ¶

You may release any build with a universal FuzeID and has attached packages, i.e., created by Fuze with either the --add-packages or --update-packages option. Local FuzeID’s cannot be released.

State Machine ¶

The following describes the state machine for release stages:

A FuzeID has no release status before it has been released. Once given release metadata, it cannot be “unreleased.”

How Do I Create a Release?¶

Releasing is an interactive process that can be accomplished via the command line or from the WebUI. A FuzeID may be released multiple times and moved through the different stages with this same procedure.

Command Line ¶

To promote a FuzeID to release stage, use the following command:

fuze --release <stage> <FuzeID>

Example:

fuze --release qa 123456-123-12345

WebUI ¶

The WebUI allows you to choose automation options while guiding you through the release process. For example, creating or updating a JIRA release ticket. The procedure below guides you through the minmum process, but see Release Automations for a description of the available automations.

Choose your build with a universal FuzeID.
Click the “Create Release” button:
Select the stage and click “OK”:
Fill in the requested information for release automations and click “OK”. See the Release Automations section for a further description of available automations. If you have a workspace.ini file that contains some of this information, you may feed it in via the “Choose File” button and some fields will autopopulate.
A status window will tell you the results of the release automations. For example:

Note

The above is an example which indicates that a) no automated testing occured, b) a JIRA release object for FPtools-V0.1 doesn’t exist, and c) no automated release notes were created because that JIRA release object doesn’t exist.

Release Automations ¶

Fuze includes a plugin interface for automation. When the release function is called, Fuze looks in the workspace.ini for a <product> specification associated with the FuzeID to be released. If found, Fuze will use the configuration items specific to guide any automations that are available.

Note

Release automation configuration items are optional. If not found, or set to NULL, the release process continues without that particular automation.

Available Release Automation Configuration Items ¶

The release process includes the following automations, specified by <product> in the workspace.ini file:

Automated test suites via ATF to be executed for each stage of release
The Jira project that contains the release object and set of tickets to be included in the release. The automated release notes are generated from this information.
The Jira RELEASE project
A local release notes file in markdown to be merged with the automated release notes.
Where in confluence the release notes are to be published.

The following shows an approximate sequence of automation events that we have built for our internal use.

Release Automation Section Specification ¶

The release automations is a plugin interface. Therefore, the automation section is highly dependent upon the plugin implementation. Each product requires its own separate section in the workspace.ini file.

The generic specification:

[<product>]
<release_automation_config[0]>=
...
<release_automation_config[n]>=

How Do I Download the Packages/Artifacts from a Release?¶

Any packages that were created and released are accessible to the entire Fuze universe. All you need to know is the FuzeID of the release. Use the instructions here for getting those artifacts.