Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To edit an existing pipeline, click on the Pipeline Name column of the target pipeline in the list of pipelines. Creating or Editing a pipeline should open up the Pipeline Definition where Stages/Environments and their constituent Gates/Steps can be added

...

Pipeline Info

The Pipeline Info provides general details about the current pipeline and a list of all the Releases using the pipeline. The releases in the Used By section can be accessed directly by clicking on them.

...

Definition

The Definition tab provides the definition of the pipeline stages, and their constituent steps and gates.  Changes to the pipeline, like a workflow, are versioned so that changes can be published to consumers or previous versions can be reverted.

...

Anchor
pipelineteam
pipelineteam

Roles

The Roles section in the pipeline defines a set of roles that will participate during the execution of the pipeline.  Roles assigned to the pipeline may then be used within the defined gates and steps (e.g. an approval step).  A role contains default members, which can be FlexDeploy Groups, FlexDeploy Users, or email addresses (used for notifications only).  A release that consumes the pipeline inherits the roles and default members from the pipeline and can override those members.  For example, the Release Manager members can be different across releases.

Tip

Tips

  • Pipeline role is generally used in gate or step configurations, but FlexDeploy 7.0 allows use of Groups directly in gate or step as well.  Hence creation of pipeline role is optional. If you need to provide specific permissions for skip, replay, abort, override etc. then pipeline role is required.

  • As a best practice, avoid assigning users directly to pipeline roles.  Instead, create a group with assigned users, and assign the group to the role.  This allows managing users in a centralized location, and avoids management across potentially many pipelines and releases.

  • Establish defaults in the role definitions of the pipeline, especially if team members are common across releases, to eliminate the need to configure the team on each and every release. 

...

Click the Done button to save the changes to the role (be sure to also save the pipeline, or changes will be lost).

Properties

Pipeline Properties are used to decorate a release with some context.  Values for the properties are provided on each release, or as inputs for each snapshot based on the value set for Property Type and may be used in various groovy scripts within the pipeline definition. Properties with the type set to “Property“ can be set through the properties section of the release, whereas with the type set to “Input“, the user is prompted to enter a value for the property during snapshot creation.

...

Click the Done button to save the changes to the property (be sure to also save the pipeline, or changes will be lost).

Variables

Variables provide a state for the life of a snapshot execution.  Such a state affords the ability to store some data as part of a step or gate in one stage, and consume it or make decisions in a later stage.  One classic example is to store a Change Ticket that was entered or created in one stage and feed it into another stage which will use the same ticket.  The pipeline defines the metadata for any snapshot variables that are available, and values can be set or retrieved using Custom Gates or Custom Steps.

...

Field

Description

Code

The identifier which is used to access the variable from Groovy scripts.

Description

A description for the variable.

Data Type

The data type of the variable.  Allowed types are Boolean, Integer, Double, Long, or String

Project Groups

Project Groups provide categorization for release content.  As such, pipelines define the project groups, and deploy segments of the content based on it.  Releases consuming the pipeline can then define its content as belonging to those groups.

...