![]() Any changes on the board are automatically replicated in Jira Releases and vice versa. Versions are moved through workflow using drag and drop functionality. Teams can define custom workflows for versions represented as columns on the board, share boards with colleagues and/or restrict access to them for certain groups. Key featuresĪs mentioned above, at the core of the solution are Kanban-style release boards with versions from multiple projects. This creates a foundation for building some good features on top. The idea seems straightforward: - We enable teams to bring versions from multiple projects onto a single Release board and define custom versions workflow, matching it to Releases/Unreleased statuses. To overcome the above challenges we created our Release Management App. The tool has no restriction against doing so, though this seems an anti-pattern just for the sake of having cross-project release functionality. Others go a bit too far - substitute Agile notion of “Epic“ and use this issue type as “Release” notion. So, some of the teams that are practicing CD, deliver through Epics that are composed of multiple user stories and technical tasks from different projects. One issue type that works across projects and has good internal tooling, is Epic. This requires a serious amount of manual maintenance to keep the integrity of the entire solution. Versions are tracked in such projects as standalone issue type with custom workflow being linked to multiple project versions / issues. Teams often create a custom project for Change Management. There are some workarounds that teams are employing to overcome these limitations. This is a some what limiting, since Jira versions are tied to a single project. So, the actual release is a cross-project exercise. This means in Jira they are handled by different teams in different projects. ![]() most current solutions are multi-component.in most of cases teams want to extend versions workflow to better track progress and/or rollout.Versions have Start Date and Release Date as well as 2 predefined statuses - Released / Unreleased. ![]() So, by specifying “fixVersion“ for Jira issues we actually assign them to one of the versions. or the new-way, via Jira Releases section of the board for Classic and Next Gen projects.either by the old-way, via Project Administration / Version Management.The standard way of Release Management in Jira is a long-lived “fixVersion“ field for any standard issue types. In this article we would like to present Release Management for Jira as a challenger to find it’s niche and close the gap within the release phase of software products with Jira. This obviously created some gaps and presented a need for middleware to connect the dots for seamless processes. Release Management, however, in most of cases, was done outside of Jira with standalone CI/CD tools. Therefore, software teams have pretty good alternatives to choose from. Test Management seems to have found its way with Apps like Zephyr, Xray, TM4J and others. The two remaining phases - testing and releasing - have become the target for loads of individual vendors worldwide to deliver possible solutions via Atlassian Marketplace. With “Portfolio“ acquisition and conversion into Jira Roadmaps, the vendor closed the gap of planning phase with an out of the box solution. This gave development teams limitless options to manage their development process the Agile way. Powering - more than 80% of Fortune 500 companies list Atlassian Jira (Jira) has become a golden standard for software teams globally to plan, develop, test and release software products.įrom its earliest days Jira focused on the development phase to introduce Agile and Lean principles and practices into their solutions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |