At a recent Atlassian Community Event, I was asked to present on a topic of my choice. After some thought (and, to be honest, a poll to our Client Delivery team), I decided on Release Management. It's a frequent topic of discussion with our clients: how can I understand what will be or is released? Also, what changed between what was in Production to what is in Production now?
I've seen many complicated solutions and I've seen many simple solutions. However, your team, your company, or your organization has to hash out the following:
- What is your definition of "Done"?
- What is your definition of "Release"?
- Are these two things in conflict?
Definition of Done versus Definition of Release
As you may already know, in Scrum, "Done" is when the Product Owner accepts the story as complete, meeting all acceptance criteria, and packaged into a potentially shippable increment. While I agree with this definition, at the same time I challenge the phrase, "potentially shippable." This is where you, your teams, your operations teams, and your product managers need to have a conversation. Does "Done" and "Released" mean the same thing across your organization?
In one organization, they had four definitions of done: Done, Done-Done, Done-Done-Done, and Done-Done-Done-Done. In reality, they were defining the QA, deployment, and Production Release processes with the four separate definitions of "Done". This was also directly related to their use of Jira Software and how to demonstrate success to management. Notice I said success and not progress. The Teams wanted credit for code complete in Jira Software to demonstrate a predictable velocity. QA wanted credit for test complete in Jira Software to demonstrate a continuous flow. Release Managers wanted credit in Jira Software for integration activities before deploying to production. Operations wanted credit in Jira Software for the production deployment. As you can imagine, this was relatively messy in Jira Software and tying work from code complete through release to Production was excruciating.
While Done may be clearer to your organization, "Release" may not be as clear. Different parts of the organization will have different definitions of Release. For a team, "Release" may mean the code has been deployed to a QA environment. For Operations, "Release" may mean deployment to Production. In the example above, "Done" and "Release" meant the same thing among the teams, QA, and Release Management, but not Operations. Nor did it mean the same thing across the organization. Without clarity across the organization, tracking and managing Releases in Jira Software becomes nearly impossible. Clearly defining "Done" and clearly defining "Release" across the organization can drive organizational alignment. Once you understand these two concepts, you can manage these in Atlassian using the following two methods: The Release Issue Type or Bitbucket Pipelines.
Method One: The Release Issue Type
Within your SDLC projects in Jira Software, create a new Issue Type called, "Release." This lets the organization know that, while code is complete, there are additional items that need to be fostered through the process. These may include documentation, release notes, a hardening sprint, or anything that can foster work from code complete to Production. The additional items can be managed as Sub-Tasks of the Release to understand the scope of work needed to move it through the process.
As with any new Issue Type, the Release will need a Workflow. The Workflow can be simple, however, we recommend using a Ready for Production Status in the workflow. When integrating Jira Software with Jira Service Management, the transition to Ready for Production is a perfect time to automate creating a Change Request. Your Operations team can review the change request with a link back to the Release Issue Type.
How do we know which stories and bugs are tied to the Release? Do we link all the work to the Release Issue Type? No. I mean, you could, but why take the time to do that? Is it really a value-added activity for traceability? Is there another way to tie these things together that could be quicker and easier? the answer: Yes.
Even long-time users of Jira Software forget about Versions. If used properly, Versions can provide every team the status, progress, and any known issues in a single view in the Release Hub. This is true for all development activities AND the Release issue. By adding the Fix Version of the intended Release, every part of the organization can see the progress of the Release. Because JQL supports Versions, all items tied to a Fix Version can be displayed in other places such as a Dashboard or a Confluence page. With a little up-front discipline during backlog refinement, or sprint planning, or even big room planning, managing a release is as simple as adding a Fix Version to the work as well as the Release issue.
Once the Release issue has been deployed to Production, always go back and release the Version in Jira Software. Anything that is not in a "Done" status category can either move to the next Version or be removed from any Version entirely.
What if a story or bug spans multiple Releases? There is still only one Release issue per Version. However, I would also challenge you to take a look (again) at your definition of Done versus your definition of Release. Are you actually completing the work or are you pushing it forward again and again because there's a problem? In the next backlog refinement meeting and/or retrospective, ask why this continues to happen. Really dig in and understand whether the work needs to be moved to an Epic, de-prioritized, completed in the next sprint, or abandoned altogether.
Method Two: Bitbucket Pipelines
Using Bitbucket Pipelines still requires your organization to have a conversation defining "Done" and "Release". However, the entities that support these definitions are different when integrating Jira Software and Bitbucket Pipelines. The Release is managed through the Pipeline and requires little human intervention. Instead, we work with a series of Workflow Triggers and automated deployments to determine where the Release is in its process.
You still need to create a Version in Jira Software. You still need good discipline during backlog refinement and sprint planning to ensure work is tied to the correct Version. You may also choose to halt the automation just before deployment to Production based on your Change Management processes. Clarify the process before implementing in Atlassian.
After your Version is created and work is tagged with the Version, add Triggers to your development workflows. For example, you can automate a transition from Open to In Progress based on the creation of a Branch in Bitbucket. You can also automate a transition to Closed or Done once a Pull Request is merged. Triggers in Jira Workflows keep people focused on the work instead of Jira Software. But where Bitbucket Pipelines really shine is everything that happens after code is merged. Separate Pipelines can be created per environment. For example, if you need to manually deploy to production, a Pipeline can automate the process through build and deploy to a staging environment after it passes all checks. Commits, build, and deploy information is visible in the Development Panel of the individual story or bug. You can even quickly understand failures and receive additional information by clicking on the failure. For a specific Version, as long as work is tagged, you can aggregate the overall health of the Release in the Release Hub by viewing the Version. Status, success, warnings, and errors are available in a central location. If everything looks good, simply click a button and deploy to Production. Alternatively, if the staging deployment is successful, automate the production deployment in the Pipeline as well.
Which one is right for you?
At Praecipio Consulting, we believe the answer is: "It depends." Regulatory compliance, risk tolerance, product uptime requirements, etc., may dictate which method is right for your organization. And, to boot, the answer can be different for different parts of the organization. However, the critical first step to implementing release management in Atlassian is to have a conversation. Are your definitions of "Done" and "Release" at odds with one another? What do they mean from a process perspective? Is there room for improvement in those definitions? We here at Praecipio Consulting have extensive experience with both Release Management best practices and the Atlassian suite of products. Contact us to find out how we can help you manage your releases more effectively.