CI/CD with Bitbucket and Jira Workflows: How to

Infrastructure & DevOps Modernization
Cloud Technology

Master Jira workflows for efficient software development lifecycle (SDLC) management and leverage it in combination with Bitbucket pipelines to optimize your CI/CD process.

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.


Workflows and Boards

When building a product, there are multiple actors and processes involved. Typically there isn’t much need to split those flows in Jira, so we will show an alternative that provides a workflow and board for each stakeholder, whether they are a Developer, QA, Release Manager (RM), Scrum Master (SM), Product Owner (PO) or Business Owner (BO).

Business Workflow

You won’t see a business workflow in Jira because, in most cases, it’s managed with other Project Management tools like Wrike or Asana. However, having everything in one place makes it easier to manage.

The workflow tries to help with documenting business requirements throughout the cycle without introducing noise to the scrum team.

This is how it works:

  1. A new requirement is created and assigned to the business for review to ensure that it makes sense and that it will add value to the product.
  2. Once the business accepts the requirement, the PO will review it and contribute to the requirement definition with additional information as needed.
  3. With all the details in place, implementation can begin. This step is a translation from the business workflow to the sprint workflow (described in more detail below), where new Jira elements are created and added into the sprint workflow for the scrum team to estimate and add to their backlog.

This workflow can be related to a Kanban board in Jira with a mapping for each status. The main actors in this board are Business and Product Owners.

Sprint Workflow

A sprint workflow is the most common and important flow, and it “belongs” to the scrum team. This flow will dictate how the team works, how the code flows, and how the code is released. This flow is also tightly coupled with the chosen branching strategy because transitions can trigger actions to Bitbucket which is a Git-based code management tool tightly integrated with Jira.

The workflow can split in two as shown in the diagram below:

  1. The left-hand side can be associated with an Agile SDLC, which is directly related to the Continuous Integration (CI) practice which integrates all your code changes into the main branch of a shared source code repository early and often. The CI should also automatically test each change after commit or merge, and automatically kick off a build. Another benefit of the CI process is that errors and security issues can be identified more easily and fixed much earlier in the development process.
  2. The right-hand side will be related to Release Management and a Continuous Delivery (CD) practice that works in conjunction with CI to automate the release process. CD can cover everything from provisioning the infrastructure to deploying the application across multiple environments.

This workflow can be related to two different boards - the Sprint Board and the Release Management Board (type: Kanban). The main actors will be the Scrum Team for the Sprint Board and PO, SM, RM for the Release Management Board.

It is important to know that the Release Management Board is not meant to manipulate Jira tickets. Instead, it’s an informational board that can be used to answer questions like “Where is this feature?” and “Have we deployed this yet?”.

Bitbucket Pipelines

As described above, the CI/CD process includes application deployment automation. To create that process, we need to set up a pipeline that can compile, test, package, and deploy the application into our server with minimum human intervention.

Each pipeline relies on a Docker image to be able to execute. Most of the time, the default Docker images used by Bitbucket are sufficient, but in some cases, a specific configuration or file is needed. This scenario calls for a custom image.

Using custom build images

To be able to use custom Docker images, we need to set up a repository. For this example, we will use Amazon ECR, which is where we will push our custom build image that will then be used by the pipeline during execution.

Bitbucket already provides a few default images that can be used in your pipeline, but we will use the custom image hosted in ECR, which has two methods of accessing listed below.

Using AWS Keys

One option is to provide the access key and secret key via secure variables under an additional "aws" section in the YAML image configuration:

Using OpenID Connect (OIDC)

An alternative is to avoid storing AWS_ACCESS_KEY and AWS_SECRET_KEY in Bitbucket and instead make use of OpenID Connect functionality to allow your workspace builds to access your image only:

OIDC connect to AWS

To avoid having to manage AWS access keys in the pipelines, we use Bitbucket OIDC to assume an IAM Role in the AWS account. This is much more secure than using access keys since the role can only be assumed by a trusted entity, which in this case is Bitbucket.

Trust Relationship

To ensure that only Bitbucket can assume the role, the following trust policy is added to the role. Notice that the name of the workspace is part of the identity, which means that no other Bitbucket workspace will be able to assume the role.

It is important to note that we must use the Bitbucket API to get the workspace-uuid as it is a value that might not be visible. 

Assuming the Role during the pipeline execution

  1. It is required to enable OIDC for the step, as seen in line 4.
  2. Lines 6-8 set up environment variables used by the AWS CLI, including the role that you want to assume. You will only be able to assume the role that has the Trust Relationship mentioned above.
  3. Line 8 writes the Bitbucket OIDC token that is going to be used by the AWS CLI. This token is what will identify the pipeline to AWS and is what the trust relationship is tested against.

Additional information on OIDC configuration can be found in BitBucket documentation.


With this new setup and configuration we have created, the team will be able to develop code on feature branches, create PRs that are reflected in Jira, and streamline SDLC processes. This configuration also opens the door to begin utilizing more Jira components and functionality to further simplify pieces of the SDLC.

If you’ve been looking for ways to begin using Jira functionality and Bitbucket pipelines, following the steps above will be a great start. Begin by applying the ideas that are most beneficial to your team, or even the ideas that would be easiest or quickest to implement, and use that foundation to grow your usage to fit your needs and help your team.

Infrastructure & DevOps Modernization
Cloud Technology
Gastón Gamietea

Gastón Gamietea

Gastón Gamietea is a Delivery Manager in Caylent’s Cloud Native Applications practice. He has more than 25 years experience working with customers across a variety of verticals, technologies and platforms, including cloud. Much of his experience has been in leading distributed teams to consistently deliver high-quality outcomes. Gaston is highly skilled in the AWS ecosystem and is always eager to learn new technologies and help Caylent’s customers succeed.

View Gastón's articles

Related Services

Caylent Services

Infrastructure & DevOps Modernization

Quickly establish an AWS presence that meets technical security framework guidance by establishing automated guardrails that ensure your environments remain compliant.

Accelerate your cloud native journey

Leveraging our deep experience and patterns

Get in touch

Related Blog Posts

Optimizing Media Management on Amazon S3

Learn how we helped a media company optimize the management of their video assets on Amazon S3.

Infrastructure & DevOps Modernization

Optimizing AWS Data Pipelines for Compliance in Digital Advertising

Learn how we helped an advertising customer setup automated, cost-effective pipelines to ensure compliance for sensitive data in their existing processes.

Infrastructure & DevOps Modernization

re:Invent 2023 AI/ML Session Summaries

Get up to speed on all the GenAI, AI, and ML focused 300 and 400 level sessions from re:Invent 2023!

Cloud Technology
Artificial Intelligence & MLOps