So far, in this DevOps for Jira series, we’ve discussed deploying changes the right way by manually or automatically deploying configuration changes from a sandbox test environment to production and connecting to a code repository to bring source code management, collaboration, and change documentation to Jira and Jira Service Management. Next, let’s discuss leveraging a CI/CD pipeline, meaning a defined deployment process.

Here are some terms to know:

• CI/CD — Stands for continuous integration and continuous delivery/deployment. A strategy to automate the deployment process. Continuous integration (CI) means frequently merging, building, and testing small batches of code. Continuous deployment (CD) means automating the release and rollout of a change.
• Pipeline — A process that contains a standard and repeatable set of steps, like moving code from a development environment to a pre-production environment to a production environment. Each step serves as a gate to verify that a specific part of the process occurred as a change moves closer towards final deployment.

‍

‍

By adopting a standard deployment process, application management is easier, changes can be made faster, and the risk of error is reduced. Again, we’ll borrow from software development best practices to bring a CI/CD pipeline process to Jira administration.

‍

What is your Jira release process?

Before we continue, take a moment to consider the environments and steps in your Jira release process. Eons ago, when I first started developing web software, my process was straightforward: Make a change in my local development environment, test it using a copy of production code, and then manually transfer the files to production. (Yikes  - a little too simple!) As I gained experience, I improved my release process to include additional environments and testing steps. I added an integration environment to perform some initial tests (like code review, unit testing, or integration testing), then deployed a change into a pre-production environment and then performed more tests (like functional, system, load, user acceptance, regression, or end-to-end testing), then deployed a change to production. After performing a final subset of tests, I marked the release contents “deployed” and prayed that I wouldn’t get a phone call at 3:00 AM because something important was broken. Back then, there were fewer opportunities to automate the release process, and deployment errors were frequent. These days, releasing software is more complex and robust, but there are more opportunities to compartmentalize change and more tools to improve and automate the process. Jira deployments are no exception, and we can use pipelines to move changes between multiple environments easily.

Setting Up Pipelines in Salto

In Salto, pipelines provide a centralized view to track the status of your release process. Use the pipelines feature to identify where changes currently are and easily promote them forward or backward as needed. Let’s create a pipeline so you can see how to manage your release process within Salto. The setup process is fast, and if you’ve followed along with this DevOps for Jira series, some of the steps are probably already in place.

‍

First, you’ll need to add a Salto environment for each Jira environment. I’ll create three: Jira Dev, Jira Pre-Prod, and Jira Prod. In Salto, click the plus icon in the left sidebar under the “Environments” header. Then, use the wizard to name the environment, link it to its related Jira application, and allow users to fetch, deploy, and edit environment settings. After the authentication step, fetch the Jira application’s configuration data. Then, repeat the process for any additional Jira environments. Step-by-step instructions for adding environments are available here.

‍

‍

Next, link each Salto environment to its corresponding Git branch, as we did in the previous article. 

Finally, we’ll create a Salto pipeline. Click the plus icon in the left sidebar under the “Pipelines” header and give the pipeline a name. 

‍

‍

Next, use the drop-down menus and the plus icons to add your Jira development environments in their desired deployment order. In my example below, changes from Jira Dev flow to the right into Jira Pre-prod, which terminate in Jira Prod. Once all environments are added, click the “Save pipeline” button at the top right.

‍

You can add, remove, or reorder environments in the pipeline at any time. You can also create multiple pipelines for multiple business applications (E.g., Jira Service Management, Confluence, Salesforce) or deployment scenarios.

Now that a pipeline is set up, you can see exactly where a particular change is in the release process. In the last article, we created a new Jira status called “Waiting for Vendor” and deployed it from a sandbox environment to production. In a Salto pipeline, use the search box at the top of the page to see precisely which environment that change is currently in and the path it took to get there. You can search for changes by keyword, Jira issue ID (E.g., CONFIG-1), the deployer’s name, or other information associated with the change.

In the example, a search for the keyword “vendor” found the Jira issue CONFIG-1. CONFIG-1 is currently in the Jira Prod environment. Click on the change for additional information like its deployment details or the related pull request in a Git-based repository. 

‍

‍

‍

If you have many changes, use the menu at the top right of the page to filter the view. For example, if the “Show promoted” toggle is off, you’ll only see the change named CONFIG-1 in the Jira PROD environment. If you turn the “Show promoted” toggle on, you’ll see it in all environments it’s traveled through. 

You can also hover over any change to see the precise path it took to get where it is today. Click any change to take action, like deploying it to a higher environment or promoting it backward to a lower environment. You can move or stage one change at a time or multiple changes simultaneously.

‍

‍

Salto pipelines gives you a visual deployment trail for every change. It helps you understand the current state of all Jira configuration modifications and enables you to move them between multiple environments.

Activities to Try

Now it’s your turn! Add all your Jira environments to Salto, connect them to a Git-based repository, and create a pipeline to manage the release process. The setup process is quick, and the result is always knowing where your changes are.

Resources

• Introduction to Salto Pipelines — https://help.salto.io/en/articles/10325724-introduction-to-salto-pipelines 
• Creating an Environment in Salto — https://intercom.help/salto-io/en/articles/6845026-creating-an-environment 
• Building an Efficient Release Process with Salto Pipelines - Demo — https://www.youtube.com/watch?v=gf_VjsDoUNs&t=3s