Master Jira workflows for efficient software development lifecycle (SDLC) management and leverage it in combination with Bitbucket pipelines to optimize your CI/CD process.
Explore Amazon OpenSearch Serverless NextGen, AWS's new scale-to-zero architecture that decouples compute from storage to deliver faster autoscaling, lower costs for idle and agentic AI workloads, and offers a new approach to managing search and vector search collections.
Explore how building a multi-tenant SaaS platform changes when the infrastructure lives in customers’ AWS accounts, and the architectural lessons learned from managing resources across environments you don’t own or control.
AWS will end support for Amazon Pinpoint on October 30, 2026. Learn what's going away and what's surviving, what your migration options are, and how to quickly audit your environment to see your exposure.
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 articlesAtlassian’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.
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.
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.
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.
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.
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).
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:
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.
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:
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?”.
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.
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.
One option is to provide the access key and secret key via secure variables under an additional "aws" section in the YAML image configuration:
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:
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.
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.
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.
Gastón Gamietea
image:
name: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/openjdk:8
aws:
access-key: $AWS_ACCESS_KEY
secret-key: $AWS_SECRET_KEY
image:
name: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/openjdk:8
aws:
oidc-role: arn:aws:iam::<aws_account_id>:role/<your_role_name>
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "bitbucketAllowed",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::[aws-account]:oidc-provider/api.bitbucket.org/2.0/workspaces/[workspace-name]/pipelines-config/identity/oidc"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"api.bitbucket.org/2.0/workspaces/[workspace-name]/pipelines-config/identity/oidc:aud": "ari:cloud:bitbucket::workspace/[workspace-uuid]"
}
}
}
]
}
1 pipelines:
2 default:
3 - step:
4 oidc: true
5 script:
6 - export AWS_REGION=us-west-2
7 - export AWS_ROLE_ARN=arn:aws:iam::XXXXXXXXXXXX:role/oidc-demo
8 - export AWS_WEB_IDENTITY_TOKEN_FILE=$(pwd)/web-identity-token
9 - echo $BITBUCKET_STEP_OIDC_TOKEN > $(pwd)/web-identity-token
10 - aws s3 cp s3://bucket/XXXXXX ./XXXXXXX
