More and more companies are starting to practice lean product development. Continuous improvements to their products help them react quickly to user feedback and changes in the market.
As a response, companies started implementing microservices architecture and creating reusable components to enable faster development.
Let's have a closer look at the reusable components approach. For example, the web application project consists of components like Database, APIs and custom UI kit library. When you start building the next application, you can re-use the same components, in this case, the UI kit library. You don't need to spend precious time on developing new UI, and you can focus mainly on business logic.
Applications usually go through many release iterations during their lifecycle to enable continuous improvement of the app. If the app consists of many components, you find yourself in a situation when you need to release a new version of the component first. Then you update your application with the new component version.
If the component is used in many apps, it also often happens that different apps use a different version of the same component.
That can happen for many reasons, for example:
- the update of the component is planned but wasn't performed yet,
- the new version of the component caused side defect in the app, and an update was postponed till the new component version is released with an appropriate bug fix,
- the update was missed accidentally due to miss communication or lack of release tracking.
To gain better visibility over your component releases and application releases in general, it's good practice to track what and when was the version deployed, and have quick and easy access to these reports.
Tracking Component versions in Jira
Jira allows basic project releases tracking out of the box. You can create a new release in your Jira project, give it the name, description, start date, and release date and link issues that are delivered.
There is also an option to create components and link issues to them. But components don't have versioning functionality available by default, so we need to look into some workarounds.
Use default Jira Releases and naming conventions
Using Jira project Releases and sensible version naming conventions allows you to track application and component releases separately:
- application releases [APP_KEY]-[version number], eg: OCTO-2.0.1
- component releases [COMPONENT_KEY]-[version number], eg: UI-3.5.0
Afterward, you can manage both Component and project releases from Jira Releases screen and use the Fix version field in JQL to filter and build reports.
- Release Reporting - allows tracking component releases separately,
- It's Free - there is no extra cost you need to pay except for your Jira instance.
- No Version hierarchy support - there is no link between component and project versions,
- Hard to manage - Jira Releases page might be overpopulated with an ongoing project and component versions with no ability to properly filter,
- No cross-project releases - only issues from one project can be linked to the version.
Component management app for Jira
Octo - Component Management for Jira is the app that enables Component releases in Jira. You can create a Component version and give it a name, description, Start date and Release date and link the component itself.
Then you link Jira issues to the Component version, and you can use JQL to search.
Component releases have their own screen, so they're not going to mess with your project releases. To track what component version is used in which project release, you can link them together. That allows you to create the following release hierarchy:
For more information watch the following video demonstration
- Jira Version Reporting - allows tracking component releases separately
- Project and component releases hierarchy - link component version to your Jira project version to see with which project release uses which component version,
- Separate screen for Component versions - Component releases are not showing in your Project release list and are managed from one single place,
- Cross-project releases support- Component version can be linked to the issues from multiple projects.