Automate Everyday Tasks in Jira E-Book

Gareth Cantrell

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 315

Veröffentlichungsjahr: 2021

Beschreibung

Atlassian Jira makes it easier to track the progress of your projects, but it can lead to repetitive and time-consuming tasks for teams. No-code automation will enable you to increase productivity by automating these tasks. Automate Everyday Tasks in Jira provides a hands-on approach to implementation and associated methodologies that will have you up and running and productive in no time.
You will start by learning how automation in Jira works, along with discovering best practices for writing automation rules. Then you’ll be introduced to the building blocks of automation, including triggers, conditions, and actions, before moving on to advanced rule-related techniques. After you’ve become familiar with the techniques, you’ll find out how to integrate with external tools, such as GitHub, Slack, and Microsoft Teams, all without writing a single line of code. Toward the end, you’ll also be able to employ advanced rules to create custom notifications and integrate with external systems.
By the end of this Jira book, you’ll have gained a thorough understanding of automation rules and learned how to use them to automate everyday tasks in Jira without using any code.

Leseprobe

Automate Everyday Tasks in Jira

A practical, no-code approach for Jira admins and power users to automate everyday processes

Gareth Cantrell

BIRMINGHAM—MUMBAI

Automate Everyday Tasks in Jira

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Aaron Lazar

Publishing Product Manager: Richa Tripathi

Senior Editor: Storm Mann

Content Development Editor: Nithya Sadanandan

Technical Editor: Rashmi Choudhari

Copy Editor: Safis Editing

Project Coordinator: Francy Puthiry

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Aparna Bhagat

First published: January 2021

Production reference: 1200121

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80056-286-8

www.packt.com

To my best friend and husband, Shaun, without whose support I would not have been able to complete this book. To my mom and the memory of my dad, who have always believed in us and encouraged us to be the best we can be.

– Gareth Cantrell

Packt.com

Subscribe to our online digital library for full access to over 7,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.

Why subscribe?

Spend less time learning and more time coding with practical eBooks and videos from over 4,000 industry professionalsImprove your learning with Skill Plans built especially for youGet a free eBook or video every monthFully searchable for easy access to vital informationCopy and paste, print, and bookmark content

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at packt.com and, as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.

At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.

Contributors

About the author

Gareth Cantrell is currently working at Square Enix as an ITSM Solution Architect. He has a software engineering background, having spent at least 15 years of his 25-year career developing various software solutions for clients.

For the past 10 years, Gareth has been involved in designing, implementing, and integrating solutions with Jira and other Atlassian tools, most of which involve automation to varying degrees.

He has worked on projects including end-to-end ITSM solutions with Jira/Slack and other third-party tools, Agile and DevOps implementations in Jira, and integrations with various CI/CD tools.

About the reviewers

Grant Andrew Finnemore qualified as an electrical engineer in the 1990s, but his passion is for building software, focusing on business empowerment. He also readily imparts his knowledge and experience.

Grant owns, and is the CEO of, a boutique software company – GuruHut. This company has been in operation since 2000, and has a reputation for quality and delivery. In 2014, Obsidian Systems took an interest, and together they became an Atlassian Platinum Partner.

Grant is married to Ania. Fast-forward 20 years and they manage a household comprising 4 young children – Liam, Rory, Sean, and Ewan, and 3 energetic labradors. When not working, he is often to be found on his bicycle, either riding the hills around home or virtually.

This is Grant's second book. The first was entitled Views from the Southern Cross.

I'd like to express my thanks to the diligent staff at Packt who guided my input to this project – not always an easy task. My sincere gratitude to the author, who I had the pleasure of working with at GuruHut, and who roped me into this project. Finally, to my wife and family for their support over so many years – thank you. I'm so much better for having you all in my life.

Ravi Sagar is an Atlassian consultant, Drupal expert, and author of several Jira books. He currently works for Adaptavist, an Atlassian partner company headquartered in London. In 2010, Ravi founded Sparxsys Solutions Pvt. Ltd., a start-up company that provides consultancy and training services on Atlassian tools and Drupal.

In his spare time, he loves blogging and publishes free online courses on his website, ravisagar.in, covering Jira, Drupal, Linux, Emacs, Org Mode, and programming. He also has a popular YouTube channel, Ravi Sagar, where he produces free content on these topics with a focus on ScriptRunner for Jira and Automation.

I would like to thank my wife, Shelly, who has always stood by me and helped me achieve my goals, and my daughter, Raavya, for allowing me to spend time reviewing this book. Finally, I also wish to thank my parents for their endless support.

Packt is searching for authors like you

If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.

Table of Contents

Preface

Section 1: Getting Started – the Basics

Chapter 1: Key Concepts of Automation

Technical requirements

Getting started with rules

What is a rule?

Understanding scopes

Owners and actors

Audit log

Working with triggers

Understanding Jira events

Rule triggers

Working with conditions

Working with actions

Issue actions

Notifications

Jira Service Management

Software

Advanced

Creating your first rule

The rule editor

Creating a rule to assign the highest priority to VIP users' issues

Summary

Chapter 2: Automating Jira Issues

Technical requirements

Understanding conditions

The Issue fields condition

JQL condition

User condition

Related issues condition

Advanced compare condition

If/else block

Working with branch rules and related issues

Branch rule/related issues

Editing issue fields

Assigning issues

Edit issue fields

Advanced field editing

The advanced field editor

Understanding the JSON object

Creating a rule to demonstrate the advanced field editor

Transitioning issues

Transitions and workflows

Creating a rule to automatically escalate requests to the correct team

Scheduling tasks

Scheduled trigger

Creating a rule to close out stale issues

Creating a rule to generate recurring start-of-week tasks

Summary

Section 2: Beyond the Basics

Chapter 3: Enhancing Rules with Smart Values

Technical requirements

Understanding smart values

Finding and using smart values

Smart value functions

Using smart value date functions

Formatting dates

Manipulating dates

Using smart value text functions

Creating a rule to auto-close an issue

Using smart value list functions

Creating a rule to sum up sub-task story points in a parent story

Using smart value math expressions and functions

Creating a rule to keep an original estimate for an epic in sync with its child issues

Summary

Chapter 4: Sending Automated Notifications

Technical requirements

Sending email notifications using automation

Creating a rule to notify customers when a new version is released

How to send notifications to Slack

Integrating with Slack

Creating a rule to notify open issues in a sprint

How to send notifications to Microsoft Teams

Integrating with Microsoft Teams

Creating a rule to notify a Microsoft Teams channel when a high-priority issue is raised

Sending SMS notifications with Twilio

Integrating with Twilio

Creating a rule to send an after-hours notification via SMS message

Summary

Chapter 5: Working with External Systems

Technical requirements

How to send requests to external systems

Creating a rule to publish release notes to Confluence

Working with data returned from requests

Creating a rule to add incident managers as watchers

How to receive requests using incoming webhooks

Creating a rule to resolve open issues using an automation webhook

Working with data in incoming webhooks

Creating a rule to raise new issues using an automation webhook

Summary

Section 3: Advanced Use Cases with Automation

Chapter 6: Automating Jira Service Management

Technical requirements

Processing incoming requests

Creating a rule to triage email requests

Creating a rule to automatically route requests

Monitoring SLA compliance

Creating a rule to monitor SLA breaches

Automating common and repetitive tasks

Creating a rule to automatically reset passwords

Summary

Chapter 7: Automating Jira Software Projects

Technical requirements

Managing versions across projects

Creating a rule to keep versions in sync across projects

Ensuring epics and stories are aligned

Creating a rule to keep epics and stories synchronized

Managing the scope of a sprint

Creating a rule to add a linked issue to the sprint

Creating a rule to notify the team when the scope changes

Summary

Chapter 8: Integrating with DevOps Tools

Technical requirements

Synchronizing issues and Git commits

Creating a rule to transition issues on code commits

Keeping track of pull requests

Creating a rule to track new pull requests

Creating a rule to manage merged pull requests

Automatically releasing versions using GitHub

Creating a rule to synchronize version releases to GitHub releases

Synchronizing deployments with sprint completion

Creating a rule to start a deployment build

Summary

Chapter 9: Best Practices

Technical requirements

Planning your rules

Planning your automation strategy

Scoping your rules

Thinking about rule design

Creating a rule to synchronize high-priority bugs

Thinking about performance

Using project-specific rules

Using the appropriate triggers

Choosing the right conditions

Optimizing a rule for performance

Organizing your rules

Using naming conventions

Labeling your rules

Naming and labeling a rule

Using a checklist

Summary

Chapter 10: Troubleshooting Tips and Techniques

Technical requirements

Debugging automation rules

Understanding the audit log

Using the audit log for debugging

Understanding service limits

Getting to know service limits

Dealing with service limit breaches

Working with queued item limits

Gaining insights on performance

Summary

Chapter 11: Beyond Automation; an Introduction to Scripting

Technical requirements

Introducing advanced automations with ScriptRunner

Introducing Groovy

Understanding ScriptRunner

Exploring scripting in Jira Cloud

Understanding the Jira Cloud API

Creating a scripted automation in Jira Cloud

Exploring scripting in Jira Server

Understanding the Jira Server API

Creating a scripted automation in Jira Server

Summary

Other Books You May Enjoy

Section 1: Getting Started – the Basics

In this section, you will be introduced to automation rules and learn about the best practices around defining and managing rules.

This section consists of the following chapters:

Chapter 1, Key Concepts of AutomationChapter 2, Automating Jira Issues

Chapter 1: Key Concepts of Automation

Atlassian Jira is a popular workflow management system that allows teams to track their work in various scenarios, the most common of these being software projects, followed closely by service desks. Over time, most teams come to realize that there are many repetitive and time-consuming tasks that need to be performed to ensure project tasks and requests are tracked accurately and in a timely manner.

Since Atlassian recently acquired Automation for Jira and incorporated it as a native feature in Jira Cloud, it is now even easier to create complex and powerful automation rules using an intuitive if-this-then-that approach without having to write any code. Automation for Jira is still available as an add-on app for Jira Server and Jira Data Center and we'll cover both use cases where they diverge in this book.

If, like me, you find yourself saying I'm sure there is a way we can automate this somehow when confronted with yet another monotonous and time-consuming task in Jira, then you've picked up the right book.

In this chapter, we are going to cover the following main topics:

Getting started with rulesWorking with triggersWorking with conditionsWorking with actionsCreating your first rule

By the end of this chapter, you will have a good understanding of the key concepts of automation rules in Jira and how the various components of rules work together to enable you to write rules that will help you to automate any repetitive and other time-consuming tasks in Jira so that you can focus on what really matters: getting things done!

Technical requirements

The requirements for this chapter are as follows:

Jira Cloud environment: If you don't already have access to Jira, you can create a free Jira Cloud account at https://www.atlassian.com/software/jira/free and ensure that you have both Jira Software and Jira Service Management selected; orJira Server environment: If you are using Jira Server (available from https://www.atlassian.com/software/jira/download), ensure that you have licenses for both Jira Software and Jira Service Management. In addition, you will also need to ensure that you install the Automation for Jira app available from the Atlassian Marketplace.

In both instances, you will need to have at least Project Administrator access to a Jira project.

You can download the latest code samples for this chapter from this book's official GitHub repository at https://github.com/PacktPublishing/Automate-Everyday-Tasks-in-Jira.

The Code in Action videos for this chapter are available at https://bit.ly/38POLVA

Getting started with rules

To understand automations, we need to first take a look at some of the basic concepts associated with them, the foremost of which is the rule.

In this section, we will examine the following concepts:

The definition of a ruleRule scopesOwners and actorsAudit log

These will give us a foundation on which to build in the following chapters, so without further ado, let's get started.

What is a rule?

A rule, in its basic form, is a list of steps required to be executed in a specific order to achieve a desired outcome that is both repeatable and auditable.

By this, we mean that a rule should have the exact same outcome each and every time it is executed, and we should be able to examine the actions applied by the rule chronologically.

Specifically, a rule in Jira allows you to perform actions against issues based on criteria that you set.

Every rule is comprised of three basic components:

Triggers: The entry point for a rule.Conditions: These refine the criteria of the rule.Actions: These perform the actual tasks.

In addition to these, a rule also contains some other basic information:

The rule nameThe rule descriptionThe rule scopeThe rule owner and actorOptions to notify the rule owner in the case of rule failuresOptions to allow other rules to trigger this ruleThe rule audit log

Together, these form the building blocks of automation rules. By combining these basic components, you are able to create rules that can be used to automate many time-consuming and repetitive tasks.

The following screenshot shows an outline of the basic components of a rule in Jira:

Figure 1.1 – Visualizing the basic components of a rule

We will cover each of these components in more detail in this and the following chapter.

Understanding scopes

Rules in Jira have can be applied in one of four scopes:

Global rulesMulti-project rulesProject type-specific rulesProject-specific rules

The following table shows how these rule scopes are defined and which Jira permission is required in order to create and manage a rule that is applied in that scope:


Figure 1.2 – Rule scope permissions

As we can see, most of the rule scopes require you to have Jira Global admin permissions in order to manage them, and this is expected, as these rules span multiple projects and cannot therefore rely on project-specific permissions.

Project rules, on the other hand, can be created and managed by project administrators in addition to Jira global administrators.

Having this distinction allows Jira administrators to delegate the project-specific automations and gives project administrators more flexibility in managing their own project rules, whilst Jira Global admins can focus on automation rules that can be applied across a much wider audience.

Rules can also be moved between the global and project scopes by Jira administrators. If, for example, it is determined that a project-specific rule could be reused across multiple projects, a Jira administrator can adjust the scope of the rule. The reverse is also true. If a particular global rule is only ever utilized by a single project, a Jira administrator can adjust the scope to that specific project and by doing so, transfer administration of the rule to the project administrators.

Owners and actors

Every rule requires both an owner and an actor.

The owner of the rule is generally the user who created the rule and is responsible for maintaining the rule. The rule owner will also receive email notifications from Jira if the rule fails while executing.

The rule actor is the user the rule will execute as. This user must have the correct permissions in the project for both the trigger and any actions the rule will perform. For example, if you create a rule that needs to add a comment to an issue, the rule actor will need to have the Add Comments permission in the project.

Important note

In Jira Cloud, the default rule actor is always the Automation app user and will belong to the atlassian-addons-project-access project role. This project role is assigned every permission in a project and can be changed in the Project settings | Permissions section. Removing permissions from this role could potentially cause add-ons not to work correctly, so it is generally advised not to change these permissions.

Audit log

Every rule has its own audit log, which tracks the execution of a rule chronologically and allows you to examine the outcome as well as the actions applied to the affected items for each execution.

This functionality is not only necessary to be able to track the outcomes of a rule execution; it also gives us the ability to be able to debug rules when things don't go as planned.

We will examine the role of the audit log in debugging rules in more detail in Chapter 10, Troubleshooting Tips and Techniques, when we will explore techniques for debugging rules and solving common issues.

Working with triggers

The starting point for every rule is a trigger. A trigger defines how the rule will activate and will generally listen for events in Jira, such as when an issue is created or when values in fields within an issue change.

In this section, we will begin by looking at Jira events as this will help you to understand when and why rules are triggered, after which we'll explore the available rule triggers, what each of them are, and how they can be used.

Understanding Jira events

To better understand how triggers work, it is worth taking a brief look at how events in Jira work as these are the driving force behind most of the triggers available in the automation rules.

Jira, like many applications, incorporates an event-driven architecture. In essence, this means that every time an action is performed within Jira, an event is fired that allows interested components to listen to and perform additional actions based on those events.

There are two main types of events that affect issues in Jira. The first of these are workflow events. These events are fired when an issue is created and any time an issue is transitioned to a new status in its underlying workflow, and are responsible for causing the Issue created and Issue transitioned triggers in an automation rule to fire.

The second type of event is issue events and these are responsible for the majority of the remainder of the issue triggers and are fired whenever a user (or app) makes a non-workflow-related change to an issue, such as updating a field or linking two issues together.

Rule triggers

Jira automation provides us with a number of triggers that we can use to kick off the execution of our rules.

These triggers are grouped into categories to make it easier to identify which type of trigger you will need when creating your rule, and these categories are as follows:

Issue triggersDevOps triggersScheduled triggersIntegration triggers

We will take a look at each category in turn and the available triggers in each.

Issue triggers

As we mentioned in the Understanding Jira events section, the majority of triggers relate to events occurring on issues, such as when an issue is created or edited.

Most of the triggers are self-explanatory and single purpose. However, there are some that can be further configured to make the trigger more specific without needing to use additional conditions.

Let's take a look at the issue triggers available at the time of writing and what each one does:

Field value changed: This rule will run when the value of a field changes. You configure this trigger by selecting the fields you want to monitor or by using a regular expression that matches the field names you want to monitor. You can also optionally narrow which issue operations will trigger the rule.Issue assigned: This rule will run when the assignee of the issue changes.Issue commented: This rule will run every time a new comment is added to an issue. Note though that this does not include when comments are edited or deleted.Issue created: This rule will execute every time an issue is created. This trigger listens for the issue-created event that is always fired as the first step in a workflow.Issue deleted: This rule will run when an issue is deleted.Issue link deleted: This rule will run when an issue is unlinked from another issue. You can optionally configure this trigger to only execute for specific link types.Issue linked: This rule will execute when an issue is linked to another issue. Like the issue link deleted trigger, you can optionally configure which issue link type the trigger will execute for.Issue moved: This rule will execute when an issue is moved from one project to another. You can optionally specify that the trigger only executes if an issue is moved from a specific project.Issue transitioned: This rule will execute every time an issue transitions through the workflow from one status to another. You can optionally configure this trigger to listen for a specific transition or multiple transitions to or from a specific status.Issue updated: This will trigger the rule when details on an issue are updated, except when changes are made by linking, assigning, or logging work on an issue.SLA threshold breached: This rule will get triggered for issues in a Service Management project when the SLA threshold has breached or is about to breach. You can configure which SLA to monitor as well as the time before or after it has breached.Work logged: This rule will run when a worklog is created, updated, or deleted.

There are a few specialized issue triggers worth taking note of and these are the following:

Manual trigger: This trigger is not dependent on any underlying events. Instead, triggers of this type are presented to the user in the Issue view and require the user to manually activate them.Multiple issue events: This trigger allows you to listen to more than one event for an issue. For example, this is useful when you need to perform the same automation when a ticket is both created and updated, rather than having to create a separate rule for each event.Sprint and Version triggers: These triggers are not directly associated with underlying issues, and instead they allow you to perform actions against the related issues when something happens to the containing Sprint or when the versions pertaining to a project are created or changed.Service limit breached: This is a specialized trigger that allows you to monitor and manage your automation rules themselves.

DevOps triggers

DevOps triggers are specific to Jira Cloud and allow you to create rules that are linked to events in your connected development tools, such as Bitbucket and GitHub.

Let's take a quick look at these triggers and what they do:

Branch created: This rule will run when a branch in a connected source repository is created.Build failed: This rule will be executed when a build in a connected build tool fails. You can optionally configure this to trigger on specific build names, branches, or tags.Build status changed: This rule will be run when the build status in a connected build tool changes, for example, from failed to success, or vice versa. This can optionally also be configured to trigger on specific build names, branches, or tags.Build successful: Similar to the previous triggers, this will cause the rule to execute when a build in a connected build tool is successful. This can also optionally be configured to listen for specific build names, branches, or tags.Commit created: This rule will run when a commit is created in a connected source repository.Deployment failed: This rule will execute when a deployment against a specified environment fails.Deployment status changed: This rule will run when the deployment against a specified environment changes status from failed to success, or vice versa.Deployment successful: This rule will run when the deployment against a specified environment is successful.Pull request created: This rule will execute when a pull request in a connected source repository is created.Pull request declined: This rule will execute when a pull request in a connected source repository is declined.Pull request merged: This rule will execute when a pull request in a connected source repository is merged.

Important note

DevOps triggers are not available in Jira Server, although these triggers can be emulated using the Incoming webhook integration trigger.

We will explore these triggers in more detail in Chapter 8, Integrating with DevOps tools.

Scheduled triggers

Scheduled triggers allow you to configure rules that run at defined intervals. These can be simple fixed-rate intervals or more complex schedules.

Scheduled triggers are perfect for automating clean-up processes or to create recurring tasks that need to be actioned and we'll look at these in more detail in Chapter 2, Automating Jira Issues.

Integration triggers

The final type of trigger is the incoming webhook. This trigger provides a way for third-party applications to trigger automation rules.

An incoming webhook trigger can specify the exact issues to act on or even provide real-time data that you can use to update issues.

Chapter 5, Working with External Systems, is dedicated to exploring the ways in which we can integrate our automation rules with external systems.

Working with conditions

Once a rule has been triggered and in order for it to continue to run, it will need to meet the criteria that you have specified.

Conditions, therefore, narrow the scope of a rule and if a condition fails, the rule will stop running and no actions following that condition will be performed.

Automation provides a number of conditions that can be applied to a rule, most of which can be applied either in isolation or chained together to form more complex conditions.

The set of conditions available to automation rules is as follows:

Advanced compare condition: This condition allows us to compare two values using smart values, functions, and regular expressions. This condition gives more flexibility for when the Issue fields condition is not sufficient.If/else block: This condition allows us to perform alternate actions depending on whether the conditions in each block match and you can have as many conditions as you need.Issue attachments: This condition checks whether attachments exist for an issue.Issue fields condition: This condition checks an issue field against a particular criterion that you can specify.JQL condition: This condition allows you to check an issue against any valid JQL query.Related issues condition: This condition allows you to check whether related issues exist for the triggered issue and whether they match a specific JQL query.User condition: This condition allows you to compare a user to a set of criteria.

We will cover conditions in more detail in Chapter 2, Automating Jira Issues.

Working with actions

The final building block in the rule chain is actions. Actions are the components that allow you to make changes within your projects and can perform many tasks, including editing issues, sending notifications, creating tasks, and much more.