FlexDeploy issue tracking systems integration (out of box or custom) can be configured globally for use by various Projects. Configurations can be overridden at Project level as well as necessary.

Click on a particular issue tracking system to configure it.

You can update name, description and ticket pattern.

Field Name	Required	Description
Id	Yes	System generated identifier (read-only).
Name	Yes	Name of the issue tracking system. (read-only for out-of-box integrations)
Description	No	Description of the issue tracking system.
Ticket Number Pattern	Yes	Pattern of the issues within the issue tracking system, used to associate FlexDeploy builds with particular issue(s). If not specified here, the pattern will need to be defined on each project which associates to your issue tracking system. For Jira, Azure Boards, GitLab, and GitHub, the pattern of tickets must be the project Key, followed by a dash (e.g. "MYPROJ-"). In Jira, all tickets created for this project are prefixed by this key. For other providers, this key isn't part of the ticket id in the external system, but is necessary in FlexDeploy for identifying the project name. For Redmine, the pattern can be whatever you like. Recommended is 'refs #, references #, and IssueID #', as these match the defaults for referencing issues in commits defined by Redmine. You can provide more than one pattern as comma-separated values.
Java Implementation	Yes	Implementation class issue tracking system integration. (read-only for out-of-box integrations)

Default Configuration

You can provide the default configuration for the issue tracking system on the Default Configuration tab. You can still override these settings at the project or environment/project level.

The configurations available are as follows.

Field Name	Required	Description
Update Tickets on Build	No	Check this box if you want to globally update any tickets associated to FlexDeploy builds. Can be overridden at the environment, project, or environment/project level.
Build Update Comment Pattern	No	Applicable only if Update Tickets on Build is checked. The value of this property is a groovy script which evaluates to the comment you wish to update associated tickets with when a build completes successfully. Groovy variables available to the script are provided in the (x=) dropdown to the right. Can be overridden at the environment, project, or environment/project level.
Update Ticket Status on Build	No	Applicable only if Update Tickets on Build is checked. Check this box if you want to globally update the status of any tickets associated to FlexDeploy builds. Can be overridden at the environment, project, or environment/project level.
To (Build)	No	Applicable only if Update Ticket Status on Build is checked. Any associated ticket will be updated to this status whenever the build completes successfully. Can be overridden at the environment, project, or environment/project level.
Update Tickets on Deploy	No	Check this box if you want to globally update any tickets associated to FlexDeploy deployments. Can be overridden at the environment, project, or environment/project level.
Deploy Update Comment Pattern	No	Applicable only if Update Tickets on Deploy is checked. The value of this property is a groovy script which evaluates to the comment you wish to update associated tickets with when a deployment completes successfully. Groovy variables available to the script are provided in the (x=) dropdown to the right. Can be overridden at the environment, project, or environment/project level.
Update Ticket Status on Deploy	No	Applicable only if Update Tickets on Deploy is checked. Check this box if you want to globally update the status of any tickets associated to FlexDeploy builds when they are deployed. Can be overridden at the environment, project, or environment/project level.
To (Deploy)	No	Applicable only if Update Ticket Status on Deploy is checked. Any associated ticket will be updated to this status whenever the deployment completes successfully. Can be overridden at the environment, project, or environment/project level.

Issue Tracking System Variables

The list of Groovy variables available to use. Can be used at the project level on the Issue Tracking Systems tab or global level under Administration → Integrations → Issue Tracking Systems.

Variable	Description
EnvironmentName	Name of the environment selected when build or deploy is created.
PackageName	Name of the current project package.
ProjectName	Name of the project.
ProjectVersion	The version of the project to submit for deployment.
ReleaseLink	Applicable only for build and deployments on the release level else link will just go to last visited release. FlexDeploy link which redirects to this snapshot on the release dashboard.
ReleaseName	The release name selected when build or deploy is created.
ReleaseId	The id of the release selected when build or deploy is created.
ServerBaseURL	The FlexDeploy server base URL defined in Administration → System Settings → Server Base URL
SnapshotId	Applicable only for build and deployments on the release level. Internal id value of Snapshot.
SnapshotName	Applicable only for build and deployments on the release level. Name of the snapshot (auto-generated by date and time when created).
StreamName	Name of the SCM stream selected when build is created.
WorkflowRequestor	FlexDeploy user that created the build or deployment request.

Environment Configuration

FlexDeploy can be configured with global environment rules which will apply to all projects unless overridden at the project level. Environment Configurations done for specific environment will be applicable only for that specific environment (i.e. overrides for Default Configuration)

The selected ticket status for the Auto-approve Tasks on Status field, is for any External Approval Task that gets created for the environment. The task is automatically approved when the associated ticket, in the Issue Tracking System, reaches or exceeds the desired status. For more information on the setup of the External Approvals and configuring Issue Tracking System at the Project level, refer to the Project Issue Tracking System Configuration section of the Projects page.

Properties

Issue Tracking System Properties provide the definition of configuration parameters that are required to integrate with specific instance of issue tracking system. Values for these properties will be provided when Issue Tracking System Instance is configured. Properties are read-only for out-of-box integrations.

Status

Issue Tracking System Statuses table defines status details for specific issue tracking system, and allows FlexDeploy to update your issues to those values at build or deployment time. Statuses are also used when you choose to enable external approvals with your issue tracking system.

Each status is represented by Id and Name. Click the Save button to apply any updates.

Finding Jira Statuses

In case of Jira, you will add the statuses from the Jira workflow(s) associated to your Jira project(s). Click the andbuttons to add or remove statuses from the list. Similarly for other issue tracking systems, provide similar status details here.

To identify the statuses to add, from within your Jira system, view the workflow(s) associated to your Jira project(s). Switching to the Text view of the workflow editor/viewer you can identify the workflow statuses and transition ids.

It is critical that the ids entered match the transition ids within your Jira workflows, otherwise, FlexDeploy will be unable to provide the desired updates.

Finding Redmine Statuses

In Redmine, issue statuses are global and can be found in the administration settings. Generally, statuses start with 1 and are sequential in the same order as listed in Redmine settings. However, sort order could have been changed, so it's recommended to use Redmine's Issue Statuses REST API to verify status ids. It is critical that the ids entered match the status ids in Redmine, otherwise, FlexDeploy will be unable to make the desired updates.

Finding Azure Boards Statuses

In Azure Boards, issue statuses can be retrieved from the column names in the individual Board itself. It is critical that the status names entered in FlexDeploy match the column names in the Azure Board. Otherwise, FlexDeploy will be unable to make the desired updates. Status ids aren't relevant for Azure Boards, so the only requirement for entering them in FlexDeploy is putting them in the order they appear in your workflow. (e.g. 1-New, 2-Active, 3-Test, 4-Resolved, 5-Closed)

Finding GitLab Statuses

For GitLab, you will need statuses for both getting the current status and making any desired transitions. For the current status, it should match statuses as they're shown on the board. For example, in this image the statuses would be 1-open and 2-closed.

Finding GitHub Statuses

At this time, GitHub only supports open and closed for statuses. Statuses should match as they appear in GitHub. Status with id 1 should be the initial status and the status with the highest id should be the completed status.

Browser not supported