A big way in which we typically measure success with DevOps has to do with integration. Your new solutions need to work with whatever products your organization has already made investments in. Because whether IT decision-makers were thinking in terms of infrastructure-as-code when they originally purchased those products or not, if the pieces of the puzzle are going to fit consistently and be adopted widely, all of these new X’s and preexisting Y’s really have to be able to talk to each other, right?
Both open source and commercial third-party solutions keep getting better and better in terms of new features and things like out-of-the-box API integration with other products and frameworks. However, the reality is that your company is unique: Nowhere else in the world has exactly the same Venn diagram of technologies, processes and people powering your specific business. Yes, it’s always good idea to benchmark as part of your evaluation and design efforts. But even if your CIO decides to run exactly the same technology stack as one of the FAANG companies or another leader in your industry segment, everything else is still going to be different. As a result, there is almost always at least a small amount of coding required to help you maximize your ROI in connecting the technologies you have with whatever you decide to build or buy next.
Jira offers a good example of how a small amount of coding can have a big impact. When Level Up’s architects are performing a standard discovery engagement with a new client, if the client is running Jira or similar, it’s one of the first services we’ll review with a laser-focus. We do this because Jira workflows tend to be at least a de facto expression of many of an organization’s change management policies and procedures. But while lots of companies are using the Atlassian suite, not as many are yet fully integrating how they use Jira with how they also deploy their infrastructure code. In our experience, the How often means as much as the What. And as a guiding principle, you want your tools to enforce your processes. Not the other way around.
If you are using Ansible, there’s a great opportunity to enforce more of your technology and governance processes without anybody having to remember to do anything except the task itself.
The Jira module has been included in Ansible for quite a while. Yet many organizations are still discovering its usefulness in helping them ensure that Jira tickets are always being created, closed or otherwise life-cycled.
In a basic functional example, it’d be a challenge to improve much on the Ansible docs. However, we do want to show how you can leverage Ansible Vault in any real world use case where protecting secrets like passwords will be crucial.
Here’s a simple Jira integration playbook to create a new Jira ticket, reassign it, comment on it and then move it to Resolved. The block to highlight includes “creds.yml”.
A jirademo.yml file:
---
- name: Jira integrator
hosts: all
vars_files:
- creds.yml
vars:
jirauri: 'https://jira.acmecorp.com'
tasks:
- name: Create issue
jira:
uri: '{{ jirauri }}'
username: '{{ user }}'
issuetype: Task
assignee: '{{ user }}'
password: '{{ passwd }}'
project: IT
operation: create
summary: Example Jira integration
description: lorem ipsum
register: issue
- name: Reassign issue
jira:
uri: '{{ jirauri }}'
username: '{{ user }}'
password: '{{ passwd }}'
issue: '{{ issue.meta.key}}'
operation: edit
assignee: 'some_other_username'
- name: Comment on issue
jira:
uri: '{{ jirauri }}'
username: '{{ user }}'
password: '{{ passwd }}'
issue: '{{ issue.meta.key }}'
operation: comment
comment: I am a comment
- name: Resolve issue
jira:
uri: '{{ jirauri }}'
username: '{{ user }}'
password: '{{ passwd }}'
issue: '{{ issue.meta.key }}'
operation: transition
status: Resolved
The creds.yml file should probably look like this:
--- user: 'your_username' passwd: 'your_password'
You can then use Ansible Vault to encrypt creds.yml as follows:
$ ansible-vault encrypt creds.yml
Finally, you can test bringing everything together by securely storing your Ansible vault password in your home directory and then running this ansible-playbook command:
$ ansible-playbook -v -i localhost -c local jirademo.yml --vault-password-file ~/.vpass.txt
Iteration and continuous improvement mean that your team can start with a single playbook immediately and then scale it until every playbook run on every host includes whatever Jira issue lifecycling is valid for that run. As an example, any failed or error playbook runs can create Jira issues. Similarly, a playbook run can comment on an existing Jira issue if that’s what you want. You can easily parameterize the issue.meta.key or anything else to align with your Jira workflows and capture the right updates. And this Jira module is flexible in terms of working with whatever your custom issue types and statuses might be as well. But hopefully as you can see, this is the type of straightforward, module-level integration that your organization can start taking advantage of to increase ROI and let the platform do the hard stuff when it comes to change management via Ansible right now, today.