Release management with JIRA and Confluence
Content of the article
The principles of release management are not new and are widely known, mostly due to the ITSM/ITIL framework.
According to Wikipedia, release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.
Among some development teams, there is a misconception that the software release is an only about “to deliver the code (the new functionality) to a production server”. In case of such an approach, the release management flow stops right after the code delivery. And a big disadvantage here is about no one is ready to answer the important questions, like
- “what features were delivered to week/month ago”,
- “what features are planned to be released this/next week”,
- “what was the last release structure (how many new features, bug fixing, UI or UX improvements, etc)”.
Agile environment, dozens of new tasks and daily product support activities are taking the situation far and far more out of control.
What is JIRA?
JIRA is a project tracking software. It is enough customizable to be set up for any software development flow. You can:
- set your own flows,
- add/hide/remove fields for tickets,
- use Kanban boards or tickets lists.
It has its own language (JIRA Query language - JQL) that is applied for searches and filtering.
What is Confluence?
Confluence is a Wiki-style software for creating, organizing and discussing the work. It consists of workspaces and pages. Pages can be easily created and modified via an intuitive and functional editor. It also supports the dynamic data for pages taking them directly from JIRA.
What made us improve our release management
Working on the current project (Platform as a Service (PaaS)) we had to admit that we are not in a required control of its workflow, as nobody was ready to give a certain and quick answer for:
- What features our team is going to deliver in the current release?
- What features were released to the particular instance?
- What are the features differences in different environments?
The application has the single code base but each instance/environment may have own custom features. There can be a huge releases deviation between instances.
A tracking tool we used didn't provide us with the technical possibility to manage the releases.
We required our new tracking system to provide us with:
- an entity (release or version);
- a possibility to plan releases (adding, removing tasks from/to versions);
- a monitoring and control the planned released tasks (handled by QA) and delivered to instances;
- release notes to briefly explain what was done;
- a releases store to answer the questions WHAT, WHEN and WHERE;
- additional reports and some custom fields for the tasks.
The Strategic solution
We split the strategy of the release management improvements several steps:
- Change the development flow;
- Choose the issue tracking tool for release management;
- Discuss the releases planning with the client.
Development flow changes
We updated the development flow:
- work on the new features should be started only from a stable version;
- all the features should be collected to “release” branch;
- there should be versions tags for “release” branches;
- build server should take the tag code and append it itself.
QA's were supposed to move the code throughout the development instances (merging the code to the needed branches).
A development flow looks like this:
Choose the appropriate tracking tools
Our team checked several tracking tools and chose JIRA as the most suitable to meet current project needs.
JIRA Cloud by Atlassian contains releases functionality out from the box. Later, we began to use Confluence as a knowledge base for versions storing. As both products belong to the Atlassian family they can be easily integrated with each other.
Communicating with the client
This direction assumed the customer conviction to have a product roadmap and avoid chaotic implementation of new features. We agreed for weekly releases.
How it works
Basically, the updated release management flow using JIRA and Confluence consists of several steps:
- Create a version for the next release;
- Assigning the tasks to the versions;
- Tracking releases;
- Reporting releases.
Create a version/release
The initial step to start release planning is to create a version in JIRA:
Our team uses names in the format “x.x.x.x”, where the last number is reserved for various kinds of “hotfixes”. Sure, it can be customized to add any text data.
Assigning tasks to versions
We use Kanban board with various statuses columns to move the ticket throughout its lifecycle.
The version should be assigned to the ticket while changing the status into “Awaiting release” on Kanban board.
It means that the feature was well-tested, merged to “release” branch and is waiting to be released (deployed to the needed environment).
The version can be assigned to a ticket if it must be included to the certain release.
The release may contain the tasks with different statuses (e.g. “In progress”, “Reopened” or even “Closed”). Clicking the “Releases” in JIRA displays the report:
JIRA will not allow you to release the version until the team complete al the tasks or remove the task from the current release.
After merging to “feature” branches, a “release” branch should contain all the required features to be delivered under the current release. All the tasks on the Kanban board should be in “Awaiting release” status.
The final step for developers here is to deliver the “release” branch to “production” (Live site).
Finally, QA checks every feature on Live site and move the task to “Done” status on Kanban board.
To release the version in JIRA you simply click on “Release” button and set up the release date. The next step is to prepare the release page in Confluence and notify a client about the release.
As I've mentioned, Confluence helps us to store all the information about the releases.
Our team uses the following page structure:
- Releases deviation*
- Release 220.127.116.11
- Release 18.104.22.168
- Release 22.214.171.124
- Releases deviation
- Release 126.96.36.199
- Release 188.8.131.52
- Releases deviation
- Release 184.108.40.206
* Release deviation is the difference between the latest and delivered to the particular instance release.
Here is the “Releases” Homepage:
After the version was released in JIRA, we create a page for the release in Confluence:
- click on “Add Release report” button at the instance page.
- fill some fields (page Title, Date, etc) including the release version in JQL request.
- add the label to the page (assuming instance is a label to group the pages under the hierarchy)
The version page in Confluence is ready.
Confluence automatically gets all the tasks from JIRA related to the particular release.
The displayed columns (JIRA issue fields) on the release page can be easily customized easily and added to the page template.
And finally, we check release notes for the tasks. This one is very time-consuming but it pays off. We use this custom field “release notes” in JIRA ticket for “human readable” comments. We use simple words, easy to understand for the client (neither ticket title, nor summary or comments) what was done under the current task.
To add the release notes open JIRA ticket from Confluence and update the description.
When you are ready to report the release, share the page and notify the client.
The basic flow with JIRA and Confluence applications:
After a couple of weeks, our team get used to the upgrade in the releases management process.
This model makes the workflow transparent for all the project stakeholders.
- For the development team: release planning, executing and storing the versions.
- For the clients: 24/7 access to the updated information WHAT, WHERE and WHEN was done.
Perfection is unachievable, but our team does the best to improve the workflow every day.
And we are glad to see the currents results: happy customers and satisfied developers.