How do you version in JIRA when your versions are like 4.8.{TFSBuild}.{TeamCity.Build}?
Do I simply create a 4.8 Version in Jira?
However what would I set the release date to?
The problem is that our versions are dynamically and created based on the build# from tfs and the Team City build#.
What is now the best way for me to create versions in Jira?
Only the Major. Minor is hardcoded for now and for every few bug fixes we upload the release to the live server.
Jira versions are primarily a planning tool (especially if you use Greenhopper aka Agile, where you can have a version hierarchy).
So that's different from a build. It may take a thousand builds to achieve the functionality planned for a "FixFor" version.
On the other hand, "Affects" versions are used to track in which build a particular bug was found. So it'll pay to rename the "current version" (when you mark it as Released) to the actual build, as Hugo suggests. And cleanup/close/move any outstanding issues at the same time.
I would suggest to name the upcoming version that doesn't have a fixed name yet something like "Next release".
When you actually do release that version then you can change the version name in Jira to reflect the correct name.
Using Jira For Project Management - Creating Versions
We use Jira for project management of daily task assignment and we like to have versions either by week or by month. This lets us assign work for a week and is very helpful with the Greenhopper plug in. Basically, you:
Open the project from "Projects"
On left side, click on "Versions"
We have version 4.4 so might be slightly different other Jira versions.
Related
In TFS 2018, There's a need to manage versions for application that is managed as a team under a team project.
Normally such versions could be managed as iterations, each of which having its sprint children. However, it so happens that there are cases where there's an overlapping between Start Date / End Date of these versions. In such cases, while working on a current version, part of the team already works on the next version in parallel, and TFS shows only one iteration as current in the backlog screen, although in this case there are two current versions...
A solution can be to add dedicated field for VersionNo, in which the team will assign work item to version. However, since version number can be arbitrary number, it will not be reasonably possible to bind it to some predefined manageable list.
Another solution might be to use AreaPath to manage these versions, because area path is based on manageable tree definition, but that could mean using AreaPath for a purpose not intended to in TFS. Since we would like to keep compatibility with future TFS updates, is this solution ok in this manner ? Can u suggest another solution ? Kindly note TFS Release mng mechanism seems to apply to the distribution of the code but not to the versioning of it as needed above.
In Atlassian JIRA, what is the difference between the fields "Fix Version" and "Release Version History", and when should you use what? I cannot seem to find any definitions and recommended usage of these fields online.
This distinction is very much useful for me, especially for Epics, that span across fix versions. For example, if my Epic feature is being released in phases, e.g. 1.2.0, 1.2.1, 1.2.4 and 1.3.0, then should I:
add each release version number to "fix version" after every release, or to "release version history", or both?
If I add to only "release version history" while the Epic is in progress, then, when closing the Epic, should I update "fix version" only with that last release version number, or update "fix version" with ALL previous versions?
(Side note: I realize that maybe I am not creating Epics correctly, that an Epic should ideally be rolled out in a single release (version)? If that is the case, please do correct me.)
JIRA was originally a bug tracking system and I believe that "Fix Version" was used to indicate which version you planned to fix a bug in.
For example, a team releases version 1.1 but then a bug is reported. They raise the bug in JIRA and give it a Fix Version of 1.2 as they want the bug to be fixed in the next release.
As JIRA is now a full-blown agile project management tool, a lot of fields aren't used for their original purpose. It is really up to you to use them how you see fit. You can even add custom fields if the standard fields aren't what you want.
Ask yourself:
What information do we need?
What will this information be used for? Reporting? Analysis of trends?
Can we leverage the existing JIRA fields, or do we need to create a custom schema?
Epics are just large stories. If you are releasing every sprint then often an epic will span several releases. If you are releasing less frequently then you could aim to fit epics in to releases, but there are no hard and fast rules about this.
We've been using Jira for a number of years now, and one of the challenges we've had is our build team had been generating daily build numbers for versions in the specific software product versions.
i.e.
t 5.0 rev 1.0001
When we have a customer facing build, we make a new version.
c 5.0 rev 1
when we release a final build, we renumber it to be:
v 5.0
When files are checked into a build, our build management automatically generates a version in the project, but we don't want to lose the build numbering when we merge versions.
Equally, we'd like the fields to be as easily searchable as versions are currently.
We aren't using Jira-Agile (aka Jira Software) at present, but that's an option.
I just don't know if Sprint versions will give us the flexibility we will need.
Has anyone got any thoughts on this, and how we would best be able to capture that requirement?
If you have one release per sprint then it would be possible to have a sprint name that followed your version syntax (e.g. sprint name = "t 5.0 rev 1.0001").
This won't give you much flexibility though, say if you needed to do an emergency bug fix release mid-sprint. It also won't allow you to track the daily build version increments.
Other things worth considering:
You could use custom fields for release type, version number and build number. The main advantage of this approach is that you could potentially use the JIRA API to have the build system update issues with the latest build number. It would be possible to then have a concatenated field that contained the entire version that would be easily searchable.
Another thing worth considering is using labels. For example you could have labels for the different types (customer facing, release, etc.). This won't make searching particularly user friendly though.
HI i need some advice on how to set up JIRA for our team.
We have multiple Projects that have multiple items that will need to be released on their own. For example if we have project A it will have 6 items that will be developed but each item needs to be released individually. Then there can be other projects with items that also need to be released individually.
If I want to use Bamboo to release the items and create the release notes etc what is the best way to set up JIRA?
Is it possible if I used 1 project but used components with 1 item to release just 1 component?
what other options do i have?
Releases in JIRA are driven by Versions which belong to a project. This means that you can manage multiple releasable 'components' from a single project.
So for example, you could have the following versions;
COMPONENT_A-1.0
COMPONENT_A-2.0
COMPONENT_B-1.0
COMPONENT_B-2.0
Then when you allocate issues, select one of these as the fix version. When you generate release notes, or trigger a release in Bamboo you would use one of these versions for the release and it will track the issues that were assigned to it.
You can additionally use JIRA Components to pre-allocate issues to certain components if you don't like the idea of assigning them to a specific version in advance. There isn't however any way to add validation to enforce that issues from specific Components can only be allocated to certain Versions.
Note, there is also a JIRA plug-in available that adds support of component-based versioning; https://marketplace.atlassian.com/plugins/com.deniz.jira.versioning
We have recently transitioned from Gemini to TFS for application change control. There is one aspect of TFS I can't get my head around - the lack of a built-in concept of the application version that each work item will be addressed in.
In Gemini every feature request, enhancement, bug etc can be tagged with a version number. If the field was left blank, the item was "unscheduled", i.e. on the backlog. Each version could be flagged as either released or not. Reports could be then created listing the issues addressed in each released version, i.e. release notes, and the issues to be addressed in future versions, i.e. a roadmap. I was completely happy with this!
Now in TFS I can't find any built-in concept of version. It seems like there are 2 ways to represent version:
As a parent item in the iteration tree, e.g.
Version 1.0.0
Sprint 1
Sprint 2
etc
Version 1.1.0
Sprint 3
Sprint 4
etc
As a parent item in the work items tree, e.g.
Version 1.0.0
Requirement 1
Requirement 2
etc
Version 1.1.0
Requirement 3
Bug 4
etc
The latter approach looks better because it allows versions to be worked on simultaneously (e.g. a major release will be worked on at the same time as bug-fix release).
So what is the recommended approach to managing work by version?
Finally, with the version property not actually being present in the work item itself, is it possible to make reports on issues addressed in each version?
For now I am going to use iteration path to capture the version number. This doesn't lend itself so well to managing development on different versions concurrently, but we are trying to get away from that practise (i.e. be working on the next release while simultaneously working on multiple bug fixes to past releases) and adopt short release cycles, i.e. a more linear path, so maybe that is a good thing.
Earlier I though Area Path might be a good place to put Version, but its too valuable as a way to split up a huge application into parts to sacrifice for versioning.
1. Tags (TFS 2013+) are the easiest way to append metadata such as build#. (same as mentioned above.)
2. The CMMI Process Template > Requirement and Bug Work Item Types have an "Integrated In" field that links to TFS Builds for direct correlation from requirement to build# [to related code changes] [to related test cases [to related test results]]. Note you must select from retained TFS Build system builds (that have not been deleted). This hard reference drop-down limits this field significantly over time or if you use a different build system. (That and build versioning are entirely different discussions :-).) The Build CMMI template fields have been there since TFS2010.
3. Create a custom field in your User Story and Bug work items. BuildImplementedIn or similarly named field would do. Creating custom fields is not hard in TFS. You will need a Team Project Admin or possibly a TPC Admin to make the customization if you aren't already an admin.
p.s.: Sorry for the late reply. I posted this answer in case others still have the same or similar question.
You could use the area field.
We use that one for product name (we maintain multiple products) and then version goes into the description of the story, but you could use the area field for versions.
Another possibility is to use tags at the top of the Product Backlog Item.
Btw, I agree that TFS is lacking a few important fields (custom fields)