Jira Azure DevOps Integration: Business grounds, and the setup Guide
Regarding Enterprise Agile Planning Tools, it usually comes to Microsoft vs Atlassian (according to Gartner, those 2 are usually taken into consideration).
Since both are great, do we have to choose just one? In this case, 1+1 can equal 3 if we combine the power of two solutions.
How?
Jira is usually preferred by frontend developers, and business units (Product Owners, Project Managers), due to working great with Confluence, which is an awesome tool used as a knowledge base, or intranet, to keep all information, plans, strategies in one place. Jira is also a better choice for Support teams, thanks to their Jira ServiceDesk software.
Azure DevOps on the other hand, is loved by backend developers since it is developed in a way that makes it easier for developers to manage tasks and code repositories.
So instead of forcing developers to use one over the other, how about we let them use the one that works best for them? As agile principles are calling, let’s allow the development teams to be self-organising, allowing them to choose the tech stack that is the most efficient.
In April of 2021, Gartner published a well-known Magic Quadrant for “Enterprise Agile Planning Tools”, where they evaluated 16 vendors, including Atlassian, and Microsoft.
“Gartner defines enterprise agile planning (EAP) tools as products that enable organizations to scale their agile practices to support a holistic enterprise view. These tools act as a hub for the definition, planning, and management of work.”
Magic Quadrant for “Enterprise Agile Planning Tools”, Gartner
In their Magic Quadrant, Atlassian was named a leader, mostly because for now, Atlassian has one of the largest installed bases globally with its team-level Jira Software tool. Its Jira Align provides end-to-end visibility, traceability, and insight into the flow of all product delivery processes. But… Atlassian is forcing their loyal clients using Jira Server, to switch to Jira Cloud or Jira Data Center. Atlassian is also constantly rising prices, bringing a lot of complaints all over the world.
Microsoft is a Challenger in this Magic Quadrant. The Azure Boards, which we’re talking about here, integrate with GitHub Enterprise, giving GitHub developers an EAP alternative to the developer-focused Issues and Projects capabilities native to GitHub. Azure Boards leverages other products in the Azure DevOps suite to connect the planning aspects well with the whole “ideation to deployment” value stream.
So when reading carefully, the same image is presenting itself – Jira is best for project management, especially in enterprises (is SAFe friendly), while Azure DevOps, with Azure Boards, is designed to add power to tech teams.
That’s why integrating them, rather than choosing one over the other can be the best option of all.
Benefits of Azure DevOps Jira integration for enterprises
Bi-directional (there is also a possibility to integrate Jira Azure DevOps only one-way) helps you keep the teams in sync. You may use it for internal purposes (integrating two different teams), or for external purposes – integrating with contractors, service providers, or with a company you acquired.
Thanks to that, there are no communication gaps or miscommunication between project management and development teams, you don’t risk losing any data which can happen when tasks are transferred manually, or using native tools (those are usually very limited, it may not be possible to integrate statuses, custom fields, attachments, or users). What’s more, the integration can be done even in real-time, so there is no risk of losing time for transitioning issues (especially important when the fast reaction is a business-critical issue).
A good integration tool doesn’t require you to prepare exactly the same workflows or types – it allows you to do the mapping that works for you, in your unique case.
The Project Owner logs a new “feature” in Jira (with attachments), getint.io integrates it instantly to Azure Boards,
The Development Team can add comments, which are synced,
When everything is clear, The Development Team breaks down this feature into “user stories”, which are being integrated back into Jira. They can add story points to estimate their work,
The Development Team completes the work in Azure Boards, and mark “user stories” as complete – the status is synchronised back to Jira,
Bonus option:
The Project Owner can use the getint.io platform, to connect his Jira, to the Zendesk or ServiceNow instance of the Support Team, so when a new support ticket is created due to customer complaints, he sees it in his Jira board, or can configure the tool, that when a support team adds a label “dev-team” the ticket is being synced directly to Azure DevOps instance of the Development Team.
If we’re agreed, that integrating Azure DevOps with Jira can bring meaningful results, how to proceed to choose the best tool for integrating them?
When you need reassurance, that everything simply works, choose the tool that has reporting built-in – so you’ll be able to check if everything is ok with just one glance. Or, it enables you to connect it to monitoring tools like Prometheus, PagerDuty, NewRelic, or other ones.
There are plenty of tools to integrate software. There are even free, native ones. They may be good for some basic integrations. But… almost no integration is that basic. Some are there for business people, with basic drag and drop builders – if you’re not technical, it may be interesting. When evaluating the tool, look for the ones that are technically very mature, so if anything will pop out, you will be covered. Make sure, it is able to integrate attachments, comments, statuses, assignees, labels/tags, or custom fields. Check, if the tool can support you to integrate only some tasks/issues, f.e. by filtering them out with custom JQL. Check if it’s possible to integrate hierarchical relationships. Or, if it supports post creation updates and custom scripting.
The dashboard of an integration platform is not Facebook, TikTok, or Instagram. It’s not even LinkedIn 🙂 You don’t want to log in there daily, to check the latest updates. You want it to work in the background. The good, reliable tool is synced once, and then simply works without the need to spend time managing it.
Even the most advanced tools should be easy to start working with. Everything starts with a Proof of Concept, isn’t it? First, you just need to check if you can use it, what’s the logic, what effect can you expect.
What happens, when a basic case will become a complicated one? You may want to start with just title, and description sync of Jira, and Azure DevOps, and end up integrating 10 types, 15 fields, and need to add integration with ServiceNow, Zendesk, or Asana. Can your tool help you if it happens?
Most Enterprises, FinTech companies have big security expectations. And that’s OK!
In the end, you’re integrating the data that can be sensitive. Can the tool of your choice work behind the firewall? Can it be installed on your own infrastructure, without anyone accessing it?
On the other hand, if that’s not the case – can it be simply deployed, as an out-of-the-box solution, that can be up and running within minutes? Or… can it do both?
Jira Data Center or Azure DevOps instances deployed by companies having thousands of users may have hundreds, thousands of tasks/issues created within minutes. Syncing those data cannot affect the performance of both Jira, and Azure DevOps. At the same time, it has to integrate quickly. Check if the tool supports parallel threads, and if the tool is installed in Jira, or in ADO – if yes, it can affect the performance of those applications, which should be avoided.
The best tools offer you the choice – you can either install it from the dedicated marketplaces (like Atlassian Marketplace, or Azure DevOps Marketplace) and can be installed outside of those. Why? Sometimes it takes several approvals to install the application in Jira, or ADO. It takes time – so it’s good to have a choice, and sometimes mix the two. F.e. to test out the tool quickly, while waiting for approvals to install the production version via the Marketplace, and pay via the Marketplace. In either case, it should not affect those applications.
When it comes to integrations, and migrations, you deal with a delicate matter. It’s good to have direct access to an experienced team that can guide you through when needed. Check the reviews, before buying – but not just the amount, the emotional level of it. The more positive, and descriptive, the better.
Let’s be honest. When it comes to integrations, or migrations – usually it’s not something that you need to do once a week. Some admins or DevOps managers are doing it a few times in a lifetime. When it’s complicated, it’s good to be able to get a full-service approach, the team that can simply agree to the scope and does it for you. Instead of just selling you a license and a link to the documentation, or redirecting you to some other, external partner company that may not be interested in helping you, if you won’t buy more of their services.
Last, but not least – the price vs value ratio. How much in total do you have to pay? Is it really worth it? Do you need to pay once, or for both Jira, and Azure DevOps installation? Check it carefully… There are some ridiculously overpriced applications on the market.
Do you know what you want to integrate?
Open an excel file, and think it through. What types do you need to integrate? What fields? Are those fields created in both Jira, and Azure DevOps? How would you like to map the statuses (especially important, when workflows differ)?
Do you need SaaS or an OnPremise version? If OnPremise, how quickly can you have the machines ready? Finally, who are the decision-makers that will make the decision of buying the app? It’s good to keep them in the loop from the very beginning. In some cases, the business unit of the Vendor needs to work with your Buying Department to add the Vendor, as a Contractor.
Do you need to install the application in Jira, and in ADO?
Do you have the required level of permissions to perform the installation?
What are the requirements for OnPremise installation?
Can you meet them?
When it comes to getint.io platform – it’s easy. You can, but you don’t have to install the application in Jira, and in Azure DevOps, and the infrastructure required for an on-premise installation is easy to meet.
Go to the Atlassian Marketplace, click “Try it free”, and test it out for 30 days 🙂 As simple as that. Or, reach out directly, if that’s not possible.
Play with the tool, read the documentation, watch video tutorials to learn how to use the platform. If you will have any questions, open a support ticket, or reach out to us on chat.
Do you need full-service support? Premium SLA? Custom development services? We’re here to help you succeed. Simply send us an email [email protected].
Would you like to pay via Atlassian Marketplace? Do you need an annual subscription or a monthly subscription? Can you buy the app directly from us, or do you need to buy it via Atlassian Partner?
In this part of the blog post, I’ll guide through step by step installation of the getint.io platform.
**
Go to the Atlassian Marketplace, and look for “Azure DevOps for Jira integration, sync, migration.[New app]”
or go to the “apps” menu in your Jira view, then “explore more apps” -> “find new apps” and type “Azure DevOps for Jira”.
Click “Try it free”.
If you’re using Jira Cloud, and if you have required permissions, the free trial will start right away.
If you’re using Jira On Premise, Jira Data Center (DC) or Jira Server, which works behind the firewall, you will have to install the application in your own infrastructure (you will get a file from us, ready to be installed. It’s very easy, and quick :)).
Important: Getint.io is not installed on your Jira, it’s not affecting the performance of it.
Then reach out to us directly. You will receive credentials (to getint.io SaaS version), or a file to be installed for OnPremise versions.
When you have access to the trial version, go to “integrations”, and… start building your own scheme, thanks to our 3 – minute setup, with video tutorials, QuickStart guides, documentation, and chat – it’s very easy.
Select the first application, let’s say Jira. Create New Connection – all you need is a login, and API Token for Jira Cloud, or a password for Jira Server, and Jira Data Center.
When the connection is established, select the Jira Project to integrate (in getint.io integrations are project-based). Provide Custom JQL if needed (You can provide JQL which will be appended to the one generated when searching for issues in Jira (eg: labels = sync)).
When this step is completed, time to connect the Azure DevOps instance. The flow is the same, select Azure DevOps from the dropdown menu, establish a new connection (a token will be needed), select the project, provide additional queries if needed.
When the connections are established (as you see, all you need are the credentials of a user with edit rights, no need for installation – that’s especially nice when you want to work with another company, which wants to do almost no effort to make the integration possible), time for mapping the types. Types are for example: Bug, Issue, Task, Work Item, Feature, Risk, User Story, Sub-task.
When the types are mapped, the next step is mapping out the fields, within the types. Those fields can be anything you need, from basic ones like ‘title’, ‘description’, ‘labels/tags’, ‘assignees’ to custom fields (drop down, select, radio, or regular text field). You can map them as you wish, they don’t need to have the same names, or even the same types (we have a workaround for that case).
When types, and fields are set up, you can proceed to statuses configuration (‘State’ field in Azure DevOps, “Status” field in Jira). This part matters for companies that wants to track the progress of work. You can map statuses one to one, or one to many, depending on the workflows, and your use case.
If you want to synchronise comments, and attachments – it’s just one click away :). Actually, comments are automatically turned on, and if you want to add attachments integration – just mark the checkbox shown below.
You have the options, to set up the integration only one-way, or to add comments as private (maybe important if you’re integrating ADO with Jira Service Desk).
In some, usually pretty advanced cases – you may want to add custom scripts (f.e. to add the values of some fields from Azure DevOps directly to the ‘description’ field in Jira). You can do it on Getint.io.
In the settings tab, you can specify the time when the integration should work, how it should behave, and how often the runs should happen.
A good tool for integrations doesn’t require you to log in daily. It should simply work. But, it’s still good to check how are things – from time to time. To make it easy, we added a dashboard with graphs. And if plenty of options for support, if you will need our assistance.
Also published here: https://getint.io/jira-azure-devops-integration-2022-guide/