Does this sound familiar to you? You’re using Jira to manage your project and Scrum processes and GitHub for source code management, code review, and branching strategy. You figure, these tools are the best in the biz, they must work together. And they do. Well, kind of. You set up the DVCS Connector provider and voila, Jira and GitHub are connected. You connect your project to your repositories and implement a branching strategy to associate branches with user stories. Things are looking great! Stories now have a Development section with branches. You can see the status of each branch, pull request, and code review. Wow! What more could you ask for? You click on a code review in Jira and get redirected to GitHub. Wait, what!? That’s weird. You thought the DVCS Connector synced branches, pull requests, code reviews comments and approvals with Jira. Unfortunately, it does not provide the level of deep integration I expected. But I have a problem, I need Code Review Comments, Approvals, and Rejections recorded in Jira since Jira is my source of truth. Here is my plan for what I’m going to do about it.

Problem Statement

I’m sure most of you are wondering why I want code review comments, approvals, and rejections in Jira since GitHub has a record of it already. You’re absolutely right! The thing is, I am trying to design the complexity out of a GCP compliant Software Development Life Cycle. I can imagine all the confused faces, so let me try to explain.

(I plan to write more about building software for the Healthcare industry but in the spirit of brevity for this post, here goes.)

To be compliant you have to prove a code review occurred by creating evidence of the action and activity. Furthermore, you have to prove the code review process is effective and fulfills its purpose, i.e. catching bugs, improving maintainability, and the changes solve the intended problem before it’s released to production. GitHub creates the evidence of the pull request, review comments/discussions, review approval, and rejection. The challenge is in creating a report to give auditors all the evidence. Manually creating this report is straightforward but time-consuming. I want to automate the generation of the report. To generate the report my team and I have researched a Jira plugin, Xporter, to copy data from fields to a template document. The plugin is limited to data in Jira and unable to copy evidence from GitHub. Which brings us full circle.

High Level Plan

At a high level, I need to know when new code review comments are created. GitHub will send an event payload with the comment when I register a Webhook URL to the repository. Next, I need a URL and application to receive the event. The application will need logic to determine the type of event, although when I register the Webhook I can control which events are sent to it, and process the information in the message body. A little digging on the GitHub Developer REST API v3 gave me a pretty good idea to what’s included in the event payload. At the moment, I know I need the comment itself, the date/time, and the user who wrote the comment. Last, I need to append the comment to a custom field in Jira and, again, with a little digging on the Jira Cloud Platform Developer REST API documentation, I learned I can update system and custom fields with API calls.

Stretch Goal: Jira Add-On

As I thinking about the effort and mapping out a rough plan, I also started thinking about how this should be easy to set up for myself or anyone who wants this deeper integration between Jira and GitHub. While it’s not a criterion of success, in my mind, I think it would be great to configure everything from within Jira. I might be able to develop a Jira Add-On to configure the needed settings like GitHub authentication, registering a Webhook, and customizing fields. I know I’ll uncover more details and complexities as I start implementing.

At the end of the day, this is a rare problem. Unfortunately, it’s rare because few teams face these regulatory obligations. Also, this is just one of an infinite number of solutions. I like it because I want to automate any and all manual, time-consuming steps required to be compliant. If you’re in a similar situation, I want to hear your story. I feel like we’re a small community, we should band together and learn from each other. I’m excited to hear from you in the comments below.