Software changes are often delivered by way of releases, where one or more components are bundled together and delivered to the end user as a collection of features or capabilities. Typically these software changes are promoted across a series of environments, before ultimately being delivered to the production environment where they are consumed by the end user. This software delivery life-cycle generally requires approvals, resolution of conflicts within shared environments, and utilizes testing quality metrics when determining when the changes are ready to be promoted into the next environment. The planning, collaboration, and execution of these activities, while required, often slow down delivery rates and add significant cost to IT projects.
FlexDeploy helps facilitate rapid change using four key components:
Release – a software delivery milestone, containing a collection of related or unrelated projects enabling new or updated features/capabilities.
Release Snapshot – build versions (project versions) of the release's projects which are sent sent through the pipeline.
Pipeline - a workflow which orchestrates the delivery of snapshots across pipeline stages.
Pipeline Stage - an environment within a pipeline which contains gates (optional) and steps.
When a snapshot (versioned project builds) is created it is sent to the pipeline for execution.
A pipeline defines a set of stages (also known as environments), which contain a series of gates and steps. Each gate blocks entry into the steps until some condition is satisfied (e.g. an approval, schedule, or test results meeting some quality metric). The steps define the implementation of delivering the snapshot into the stage. After a stage successfully completes execution, it is sent to the next stage and begins executing its defined gates.
Many snapshots may be executing within the pipeline in parallel, however, only one snapshot can execute the steps within a single stage at a time. Multiple snapshots may be within the gates for a single stage. If a snapshot makes its way through the gates for a stage, any snapshot in the gates created prior is set to out of date. For example, if three snapshots are executing gates within the DEV stage above, if the latest one makes its way through the gates first, the other two become out of date. If the snapshot created second makes its way through the gates first, the one created prior is set out of date, but the one created after it is still eligible to continue its way through the gates and on to the steps. If a snapshot has completed the stage gates, but another snapshot is executing the steps in the same stage, the snapshot completing the gates is held in queue until the executing one completes.