Release CI/CD Deployment through JIRA
Introduction
In this article, you’ll get to know how we are tracking Development and Production Deployment in Airtel by following DevOps Principles and Practices, for which we are using customized Jira workflow which is implemented and integrated with Jenkins to track the visibility and features of tasks which makes easy for Project Manager or Leads to monitor about the deployment in Production or other Environments and to provide clear visibility about the progress of Features and Stories.
This solution caters to one that is using Jira Data Center (Server).
To implement this solution, Airtel suggested using Jenkins and Jira as tools and Golang and Groovy Scripts as algorithms to deploy end-to-end Processes from the lower Environment to Prod Environment.
Use Case
Airtel makes life easy for JIRA Technical Project Managers to achieve and track different multiple projects deployment through CI/CD Pipelines on component bases in Jira Field form, where multiple LOB’s components depend on single JIRA Ticket, which is given as build arguments in Jenkins stages for CI/CD Process.
Pre-Deployment Actions
Enter or fill the project-specific fields or components in the Jira form (Jira Ticket) that are required to be filled by recipients/leads/developers, e.g. component/s, Deployment Decision, Services, etc.
While moving from one environment to another environment, get the approval from relevant stack holders for Deployment, this enables a clear view to the JIRA project manager. It saves hours of work in JIRA and keeps everything in one place for traceability.
Post-Deployment Actions
Jira Comments will be posted and the status will be auto-changed on JIRA Tickets reflecting the status of the deployment, with relevant information.
Jira Workflow Design
We have designed the workflow more structured into our working process. In DevOps Principles we have customized issue types to match the method of project management needs.
Development
A parent issue (feature type) is an epic that sits above another issue (story and bugs type).
Integrated different tools based on our objectives i.e., SonarQube, and Elasticsearch.
SonarQube, Scan the repository and tests to figure out the bugs, smug, code smells, code coverage, etc. After scanning store results on Elasticsearch on the basis of Jira Tickets, updating the data, Searching the data, Analyzing the data, Searching with Relevancy
For every successfully Deployed Story, the release score will be posted on comments or field forms regarding total code coverage, total test cases passes/failed, bugs, etc.
{"_index": "jira-trigger","_type": "doc","_id": "d1ac2a39f21b37104a99c59b7fe9129f978d3f03","_version": 36,"_score": null,"_source": {"git_commit_id": "d1ac2a39f21b37104a99c59b7fe9129f978d3f03","component": "xyz""rfc_created": "true","jiraID": "xyz-83","jiraURL": "","jira_unique_id": "2524381","total_test_cases": 74,"passed_test_cases": 9,"passed_test_percent": 12.162162162162163,"sonar_tag": "xyz","code_coverage_old": 68.2,"current_bug": 11,"current_code_smells": 296,"current_vulnerability": 12,"code_coverage_new": 0,"overall_code_coverage": 68.2,"unit_test_cases": 141,"release_score": 69}}Production Release
A parent issue (Release type) is an epic that sits above another issue (feature, story, and bugs type).
As soon as Release Jira Ticket is created, it’s mapped all Features and Stories results are consolidated and get reflected on that Release Ticket on their fields and as well on their comments.
We will track every Jira Story that is mapped under that Release as a package. Until every Story is Closed, Release Ticket cannot be Closed. Every Story results will be posted under Release comments like QA Sign Off, Operations KT handover, Change Request (CR), etc. If any Story is not closed and TPM is requested for Prod Deployment in Release Ticket, the relevant Status will be displayed or changed to Prod Pre-requisite failure and comments will be posted mentioning the cause of the failure.
For Monolithic: As the lowest level environment is fully tested, the Build Change Request is passed to Jenkins for tracking purposes or to get an understanding that the build's artifact is ready for upper environments or Production Environments. That Change Request that got generated contains all the packages in it which will be finally deployed to Production.
Jira Workflow Integration with Jenkins
1) Fill the Jira template or form with appropriate fields describing business requirements.
2) Some Jira fields are specifically for providing Trigger to Jenkins CI/CD Pipelines if that Story is ready for Deployment or CI/CD Process. These fields are to be selected only when Story is ready for CI/CD, else these should be empty till the work is going on in it.
3) As soon as the Story is ready for DEV or any other environment Testing, selected the mandatory fields and fill them as required and select the appropriate Jira Status for triggering CI/CD Pipelines.
4) As Jira Status is changed, a mapped post-script will be executed for that status change or transition change which will inherit all the required fields which you have entered in the Jira and perform the CI/CD Process accordingly depending on those inputs.
5) Now, after analyzing these fields from Jira, the post-script will trigger the Generic Jenkins Pipeline named “PIPELINE_EXECUTION_CONTROLLER” which will take those fields information that you have stored in Jira Form along with JIRA ID as build arguments of Jenkins Pipeline.
Pipeline Structure
We have designed the pipeline in 3 Factors:
Working of PIPELINE_EXECUTION_CONTROLLER Jenkins Pipeline [Parent Pipeline]
1) In the first stage, this Pipeline will try to find the Environment for which its Jira CI/CD Process needs to be followed by checking the Jira Ticket Status. For Instance, if the selected Jira Status is Ready for DEV Deployment, then Environment which will be dynamically calculated in this stage will be DEV.
2) In the Second stage, this pipeline will try to analyze those parameters which got feeded from user input Jira fields or components. Analyzing those parameters will try to help or create build parameters for next-level Jenkins pipelines or for Upstream pipelines which will perform actual CI/CD Processes for those environments which we figured out in the first stage.
As every Project CI/CD Process is different and required different build parameters to run, thus the above-mentioned second stage is to create relevant build parameters for every project Jenkins CI/CD Pipelines using the build parameters of PIPELINE_EXECUTION_CONTROLLER Pipeline which got stored or feeded from user input Jira fields in its Jira Form.
3) In the Third Stage, this will trigger the Project Specific Pipelines for CI/CD passing relevant build parameters required for those pipelines trigger. It will be on hold till it will be fully executed. Depending on these Upstream pipeline’s status, further action will be taken by PIPELINE_EXECUTION_CONTROLLER Jenkins Pipeline.
In case the pipeline fails in the third stage due to CI/CD Build Failure of upstream pipelines which got triggered in the third stage, PIPELINE_EXECUTION_CONTROLLER will change the Jira Status to DEV Failure, if deployment is for DEV Environment, etc.
In case of pipelines success in the third Stage due to CI/CD Build Success of upstream pipelines which got triggered in the third stage, PIPELINE_EXECUTION_CONTROLLER will change the Jira Status to READY for DEV Testing, if deployment is for DEV Environment, etc.
Stage 1: checkout [Groovy Scripts]
Stage 2: Find who is triggering the build.
Stage 3: Get Environment from Jira Status.
Stage 4: Analysis of the JIRA component got from the JIRA ticket as arguments and manipulation/modify them to support the upstream pipelines.
Stage 5: Triggering upstream project-specific pipelines.
Stage 6: Changing JIRA relevant status.
Working on Upstream CI/CD Pipelines which will trigger application-specific Jenkins Pipeline [Child Pipeline]
1) These Pipelines will perform the CI/CD Process or logic that is implemented in it for that Project and Environment.
2) After completion of this CI/CD Process or logic, this will auto-trigger JIRA_MANAGER Jenkins Pipeline for posting the relevant Jira Comments on Jira Ticket stating the build details or results.
Working of Jira Manager [Sub-Child Pipeline]
1) This Pipeline will take build parameters as Environment, Application Change Relevance, Downstream CI/CD Pipeline Build status, Jira ID, and Jira transition Status.
2) Depending on these build parameters, this pipeline will execute a Go Lang code which will read and analyze these build parameters and try to create a payload for posting relevant Jira Comments on Jira and post it.
Stage 1: Checkout Groovy Script
Stage 2: Find who is triggering the build.
Stage 3: Calling Go Lang Script to analyze downstream build status and posting relevant JIRA comments on JIRA Tickets.
Library Directory Structure
The specific directory structure that tells JIRA and Jenkins how to load your code and make it available to pipelines.
Extending with Shared Libraries
(root)+- Project_Specific_Folder| +- JIRA_MANAGER.groovy | +- PIPELINE_EXECUTION_CONTROLLER.groovy. # used to call lang script and Analysing the JIRA component field and passing those to project specific pipeline for CI/CD.Jira Deployment in Go Lang
(root)+- client # Function to call JIRA Rest APIs.| +- client.go| +- rest.go| +- structs.go+- issues # Function containing JIRA Operations.| +- issues.go| +- structs.go+- vars # All variables| +- vars.gogo.mod # Go Modulesgo.sum # Go Packagemain.go # Control to drive flowSummary
Now that you’ve read how easy it is to get started with both JIRA and Jenkins integration, put them to work for trackability from the lower environment to the production environment.
Moving Forward
At Airtel, We are taking DevOps to the next level and constantly solving new problems and challenges, please stay tuned.
Continuous day-to-day enhancements are happening on this Jira Methodology in order to ease it more.
The Team Building Great Things Together
This wouldn’t be possible without hard work and outstanding contributions from the team to build impactful systems that help our business forward, bringing engineering solutions.
Special Thanks to the members of various teams: Nathan Phipps and Anubhav Yadav
Author of this whole implementation and DevOps Practices/System Design for DevOps: Abhinav korpal
Special Thanks and credits should go to stunning colleagues and direct collaboration: Gaurav Walecha, Praveen, Anshika Mishra, and Arzaw Tiwari
