Streamlining Deployment Workflows with Jira Webhooks and GitHub Actions
Automation is a game-changer when it comes to managing software development workflows. It liberates us from performing manual, repetitive tasks and allows us to focus on what truly matters – delivering quality software. Jira, a powerful project management tool, offers a versatile rule builder that empowers us to automate even the most complex scenarios.
In this article, we will dive into the world of automation, exploring how Jira's webhook capabilities can trigger GitHub Actions workflows to streamline the deployment of Spring Boot microservice artifacts to different environments, such as DEV, QA, and PROD.
The Goal
Our objective is clear: Whenever a user updates a Jira issue's status to a specific environment (DEV, QA, or PROD), we want GitHub Actions to kick in and deploy the corresponding artifacts to that environment. Let's break down the workflow:
User updates Jira issue status to Dev → GitHub Actions deploys artifacts to the DEV environment.
User updates Jira issue status to QA → GitHub Actions deploys artifacts to the QA environment.
User updates Jira issue status to PROD → GitHub Actions deploys artifacts to the PROD environment.
Creating the Jira Automation Rule:
To achieve this automation, we start by defining an automation rule within Jira.
Here are the key points to note:
- The rule is triggered when an issue transitions to a different status.
- if/else conditions to specify the rule's behavior's based on the new status.
- If the status is DEV, a webhook call is triggered, sending a repository dispatch event to GitHub Actions for DEV deployment.
- If the status is QA, the same process applies but for QA deployment.
- If the status is PROD, GitHub Actions handles the PROD deployment.
Please note that only users with administrator privileges for the specific Jira project can create such rules.
Webhook Configuration:
The webhook configuration in our rule is critical. It essentially makes a REST API call to GitHub's repository dispatch API. A few points to consider:
The endpoint requires write access to the GitHub repository.
The Header section must include an Authorization token (Bearer <github token>) for authentication.
Using this feature, we can either manually trigger GitHub actions using repository dispatches or set up an application like JIRA to trigger the action by sending a web request.
GitHub Environments:
GitHub Environments provide a structured way to define deployment targets like DEV, QA, and PROD. They can include environment-specific secrets that overwrite repository secrets
Additionally, environment protection rules, especially for PROD, can be configured to ensure proper approvals before deployment.
GitHub Actions Workflow:
The GitHub Actions workflow is where the actual deployment magic happens. Some key points in the workflow YAML file:
name: Build and deploy ASP.Net Core app to Azure Web App
on:
push:
branches:
- main
- UAT
pull_request:
branches:
- main
- UAT
workflow_dispatch:
jobs:
build-prod:
runs-on: ubuntu-latest
if: ${{ github.ref == 'refs/heads/main' }}
steps:
- uses: actions/checkout@v2
- name: Checkout Repository
uses: actions/checkout@v2
- name: Build Steps
run: echo "Build Steps Here"
build-qa:
runs-on: ubuntu-latest
if: ${{ github.head_ref == 'refs/heads/release'|| github.ref == 'refs/heads/release' }}
steps:
- uses: actions/checkout@v2
- name: Checkout Repository
uses: actions/checkout@v2
- name: Build Steps
run: echo "Build Steps Here"
build-dev:
runs-on: ubuntu-latest
if: ${{ github.head_ref == 'refs/heads/develop'|| github.ref == 'refs/heads/develop' }}
steps:
- uses: actions/checkout@v2
- name: Checkout Repository
uses: actions/checkout@v2
- name: Build Steps
run: echo "Build Steps Here"
deploy-prod:
# The type of runner that the job will run on
runs-on: ubuntu-latest
needs: build-prod
environment:
name: 'prod'
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-2
- name: initalize cluster
id: install-aws-cli
uses: unfor19/install-aws-cli-action@master
with:
version: 2
- run: aws eks --region us-east-2 update-kubeconfig --name eks-prod
- run: kubectl apply -f argo.yaml
deploy-qa:
# The type of runner that the job will run on
runs-on: ubuntu-latest
needs: build-qa
environment:
name: 'qa'
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-2
- name: initalize cluster
id: install-aws-cli
uses: unfor19/install-aws-cli-action@master
with:
version: 2
- run: aws eks --region us-east-2 update-kubeconfig --name eks-prod
- run: kubectl apply -f argo.yaml
deploy-dev:
# The type of runner that the job will run on
runs-on: ubuntu-latest
needs: build-dev
environment:
name: 'dev'
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-2
- name: initalize cluster
id: install-aws-cli
uses: unfor19/install-aws-cli-action@master
with:
version: 2
- run: aws eks --region us-east-2 update-kubeconfig --name eks-prod
- run: kubectl apply -f argo.yaml
The trigger defined in the webhook must match the event type defined in the custom data to initiate the workflow.
Final Result:
With this automation in place, the deployment process becomes seamless:
- Developers work on Jira-assigned tasks, and the Jira-GitHub integration takes care of deployment based on status updates.
- The status changes from DEV to other values or back to DEV can trigger re-deployment, facilitating bug fixes.
- Jira reports provide visibility into the status of all open tickets and their deployment stages.
- This streamlined workflow minimizes manual intervention and ensures a smooth path from development to production.
Conclusion:
In this article, we've explored the powerful synergy between Jira automation rules, webhooks, GitHub Environments, and GitHub Actions workflows. The possibilities for automation between Jira and GitHub are vast, offering endless opportunities to optimize your software development processes. So go ahead, experiment, and discover the automation magic that can elevate your development workflow to new heights!
Was this helpful?
Thanks!
Teja
3 comments