Atlassian’s Jira is an industry-leading tool used by Agile teams for managing many components of the software development life cycle (SDLC). Within Jira, there are many different components and types of functionality that can be leveraged to simplify processes, create automations, and streamline routine tasks. 

In this blog, we will look specifically at Jira workflows which are a set of statuses and transitions that an issue moves through during its lifecycle. We will connect the dots and share ideas on how you can manage the SDLC workflow in Jira from the perspective of a developer, release manager, and stakeholder. Using these ideas, your development team will be able to develop code on feature branches, create pull requests (PRs) that are reflected in Jira, and streamline SDLC processes. 

It’s important to understand that these recommendations may not work for every project size or team. In some cases, what we are going to share here will create new work and overhead for your team, but as you begin to apply these ideas, you can adjust them to fit your needs, your team, and your environment.

Jira Transitions and Workflows

Let’s first understand what a workflow is. Organizations have internal processes to help organize and streamline work that is repeated frequently and must be completed a certain way. For example, HR has a process for onboarding, IT follows  a process for each support request, and even in our own daily routines we follow a process. Everything has a process, and that’s what we’ll call a workflow.

Common reasons for building a workflow include situations where an entire team needs to follow specific steps in a particular order, or where we need observers to understand and have visibility into how a certain process is managed or executed.

As we mentioned above, a Jira workflow is: “a set of statuses and transitions that an issue moves through during its lifecycle, and typically represents a process within your organization”. Let’s look at how a team’s activities can fit within a workflow.

Branching Strategy

A branching strategy determines how and when developers branch, merge and release code. There are several models to choose from including mainline, trunk-based development, release branching, and more. When deciding on a method, it is important to evaluate what makes sense for your team and product.

Branching strategy will determine how the delivery team functions and how each feature, improvement, or bug fix is managed. It also reduces the complexity of the delivery pipeline by allowing developers to focus on development and deployment of relevant branches—without affecting the entire product. In our example below, we will explore feature and release branching, and we will also follow a Git branching model called Gitflow for bugfix and hotfix branches.

Release Branching Strategy

With release branching, all the code that is meant to be deployed together lives on the same branch. This makes it easy to do isolated testing of new behavior separate from the rest of the codebase or other in-progress work.

This approach helps development teams understand when it’s ‘go time’ for new features because deployments are pre-planned and concrete.

Feature Branching Strategy

The core idea behind a feature branch workflow is that all feature development should take place in a dedicated branch instead of the main branch.

This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the main branch will never contain broken code, which is a huge advantage for continuous integration environments.

In the example below, we use a release branch as the main branch from which the feature branch is created. This adds another level of isolation and makes release and feature branches short-lived as compared to dev, qa, staging, and main, which are long-lived branches reflecting the current state of each environment.