Integrate FlexDeploy with Jira to validate ticket status before execution starts
Overview
Below link shall provide a good idea about CMS support(both Out of Box and custom) from FlexDeploy perspective.
We are going to use JIRA as our CMS(Change Management System). We are going to have validation on state of Jira Ticket. Say for an example, if the Jira ticket status is in “In Progress” then only FlexDeploy will continue with the deployment. Else FlexDeploy will wait till the ticket status is changed to desired state.
No human interaction is required from FlexDeploy perspective. FlexDeploy will periodically check the status of Jira ticket on a regular interval. Will trigger the relevant flow automatically once the ticket status is matched.
Configure JIRA as Change Management instance in FlexDeploy
First we have to create a new API Token(JIRA) for authentication purpose. This is needed to configure the JIRA account in next step.
You can directly paste the url as mentioned in above link, it’ll work.
Alternate option - select your user icon from top-right corner and select Manage-account option, then also you will land up on same page as shown below.
Next we would configure the Jira account in FlexDeploy as a CMS(Change Management System) account. Detailed configuration steps are mentioned here.
Once configured it should look like given below
Configure JIRA CMS validation scripts
While configuring the CMS account we can find few other essential parameters which needs to be setup-Approved Check Script, Rejected Check Script. Please refer to below link for more details.
These are basically groovy expressions which determines whether a task for a change ticket is to be approved or rejected.
If the Approved Check Script is left blank, the default implementation checks the status of the ticket as mentioned below
TICKET.fields.status.name == 'Awaiting implementation' || TICKET.fields.status.name == 'Implementing' || TICKET.fields.status.name == 'Completed'
The question which now arise - how do we identify or understand what status value(status.name) we have to add it here. Lets try to understand how exactly this is being evaluated.
Lets assume we have an ticket/issue : FLXTEST-8, we can get the relevant details of the ticket using below url:
If you are already logged in to the JIRA account, you should be able to open above url in another tab of same browser. We can make REST invocation as well to get the response.
In case you want to try it from REST client like SOAP UI/Postman you can also do the same. In that case you need to pass the username & Jira API token which we have already configured as part of CMS instance.
You can also pass the BASE64 encoded( ) value of $userName:$Token as an Authorization Header during REST API invocation as shown below. Then also it will work.
Header Key : Authorization
Header Value : Basic Base64EncodedValueof($userName:$Token)
In case you get below error, you may want to check your credentials/authorization header.
{"errorMessages":["Issue does not exist or you do not have permission to see it."],"errors":{},"reasons":[]}
Once you format the JSON response you should get response payload as given below.
If we go back analysing the default groovy script , TICKET.fields.status.name – TICKET basically signifies the entire TICKET Response object where as fields.status.name is basically the Json PATH to retrieve the Status as can easily be understood from above payload.
Now we are clear on the JSONPATH. As obvious each organization/project combination will have their own set of defined Status name. Hence the approved and rejected script can be updated based on the actual status name.
In case you are not quite sure you can navigate to the issue under respective JIRA project and navigate to status dropdown and select view workflow.
This will give a flow chart of all available status associated with the project.
Based on above status we have modified our Approve Script as given below
Based on JSON payload you can have any criteria, even based on custom fields as well, as shown below.
(TICKET.fields.customfield_10107.status == 'UATApproved' && FD_ENVIRONMENT_CODE=='UAT') || (TICKET.fields.customfield_10107.status == 'PRODApproved' && FD_ENVIRONMENT_CODE=='PROD')
Integrate Jira with FlexDeploy pipeline
One should always do deployment using Release & Pipeline maintaining the software lifecycle flow. You can add the External Approval under pipeline Gate as shown below to interact with Jira.
We are going to create the pipeline based on a realistic scenario.
As part of the development stage execution, we are going to create the ticket in Jira. On the QA stage we are going to validate if ticket status is in desired state(In Progress) or not. There will be a gate condition which once satisfied the respective stage will be executed.
We will do a little more explanation to it. Below given is our pipeline. We’ll explain each step-in detail.
Below given is the External Gate configuration step(Create Ticket in Jira) for Jira under Development stage. We are creating the ticket as well. The content of ticket can be both static, dynamic or combination of both.
The Ticket summary & Project Key property we are retrieving dynamically .
The variable JIRAPROJECT which we are passing against Project Key is a pipeline property in our case, which needs to be set at Release level.
The Jira ticket Id is accessible within Development stage only. However, we would want to store the value so that we can check the status later based on generated ticket Id. The purpose of Snapshot Variable in pipeline is exactly to address such scenario. The variable once populated can be accessed by all stages of the pipeline for that particular snapshot.
We create a new Snapshot variable at Pipeline level to store the CMS ticket id.
Next we add a custom step to populate the ticket number from External Gate to this variable as shown below.
In case you are wondering where exactly the getRelatedTicket operation is defined, please go through below link. Using this operation we are able to access Jira ticket number.
Next under QA stage, we assign the variable data again back to stage context, so that FlexDeploy has the ticket detail while executing QA stage.
As a result, when we are adding the External Gate step there is no need to set the ticket number explicitly. It’s already added to the context as part of previous step.
In case you are wondering what is the criteria for the Gate step being processed, you have to navigate back to Approval Check Script under FlexDeploy integration Change Management instance that we created. We want the QA stage to be executed when the ticket state is In Progress , hence we already updated the script accordingly.
When we now create & start a Release based on the pipeline, our pipeline will get stuck at the Create Ticket level.
However we can find the ticket successfully created. Then what could be reason behind the step getting stuck.
You need to understand the basic concept of Gate here. The purpose of Gate is to validate some criteria. Create ticket was an optional step which we selected for Development stage. Post creation of ticket, the Gate is trying to validate the created ticket status against the Approval Check script configured in Flexdeploy integration CM instance( previous step).
When the ticket gets generated, in our case by default is assigned with status “Backlog”. Which is not getting satisfied with our Approval Check Script, hence it’s waiting.
Hence ideally if the ticket is in Backlog state for Development stage it should proceed. Whereas for QA environment, we want the steps to be executed only when the ticket state is In Progress. Hence, we need to consider the scenario where approval script can vary across environments.
We modify the approval criteria as given below.
(TICKET.fields.status.name == 'Backlog' && FD_ENVIRONMENT_CODE=='DEVELOPMENT') || (TICKET.fields.status.name == 'In Progress' && FD_ENVIRONMENT_CODE=='QA')
When we change the script, we can find the Development stage getting completed and stuck with QA ticket state validation.
We can check the ticket details from Upload Execution Information option, which is assigned to the snapshot variable.
Currently our ticket was in Backlog state.
We manually changed the the status to Progress state. This can be automated as well.
Once the state is changed to In Progress, the Gate condition is satisfied and steps are executed.
Integrate Jira with FlexDeploy project
Now let’s say I want to set the approval criteria at folder level, in case someone wants to deploy directly from Project but there is a validation criteria on the ticket status. Please follow below link for detailed information.
n.b deployment using Project level should be limited to development environment only. All higher environment deployments should follow the SDLC process and be deployed using Release/pipeline.
First navigate to the parent folder of the Project and select MANAGE FOLDER option as shown below.
Under Approvals create a new Approval option and select for which environment the approval should be applicable.
Also the CMS connection instance and group who can override the approval also needs to be configured as shown below.
You can pass the Change ticket number while doing the deployment through Project.
Once the deploy workflow is executed from Project, it will show the flow is waiting for External Approval.
If you click on the Request Id highlighted above, it will open the pending task.
This can always be approved by the role in case JIRA is not available or some other issue ( not recommended though).
The external approval is in waiting state since the ticket status is under BACKLOG.
Now as soon as this is moved to In Progress state.
The Deploy task will automatically be initiated. Basically, FlexDeploy keeps on polling on a regular interval to check the status of ticket.
We can also find the Action By is fd_monitor, confirming that the approval happened automatically, not by any user. The deployment is completed.
- style