Configure Issue Tracking Systems

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 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, the pattern of tickets is the Jira project Key, followed by a dash (e.g. "MYPROJ-"). All tickets created for this project are prefixed by this key, making it the pattern. 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 default configuration for issue tracking system on 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		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		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		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)		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.

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 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 Development 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.

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 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.