Is there an equivalent of Jira-Releases in VSTS?
In Jira, you can create Releases for a project. As part of a Release, you can specify which issues are part of it as well as add Release notes.
These are extremely useful when you have automated build scripts, as the API for JIRA can be queried by the scripts as part of a CD pipeline.
You can therefore do things like (but not limited to):
- Fill in a changelog dynamically
- Stop deployment if there are an issues part of the Release that are not Done
- Retrieve version numbers
Question: Is there a VSTS equivalent?
azure-devops jira asked Nov 16 '18 at 1:32
AshAsh
682728
add a comment |
In Jira, you can create Releases for a project. As part of a Release, you can specify which issues are part of it as well as add Release notes.
These are extremely useful when you have automated build scripts, as the API for JIRA can be queried by the scripts as part of a CD pipeline.
You can therefore do things like (but not limited to):
- Fill in a changelog dynamically
- Stop deployment if there are an issues part of the Release that are not Done
- Retrieve version numbers
Question: Is there a VSTS equivalent?
azure-devops jira asked Nov 16 '18 at 1:32
AshAsh
682728
add a comment |
In Jira, you can create Releases for a project. As part of a Release, you can specify which issues are part of it as well as add Release notes.
These are extremely useful when you have automated build scripts, as the API for JIRA can be queried by the scripts as part of a CD pipeline.
You can therefore do things like (but not limited to):
- Fill in a changelog dynamically
- Stop deployment if there are an issues part of the Release that are not Done
- Retrieve version numbers
Question: Is there a VSTS equivalent?
azure-devops jira asked Nov 16 '18 at 1:32
AshAsh
682728
In Jira, you can create Releases for a project. As part of a Release, you can specify which issues are part of it as well as add Release notes.
These are extremely useful when you have automated build scripts, as the API for JIRA can be queried by the scripts as part of a CD pipeline.
You can therefore do things like (but not limited to):
- Fill in a changelog dynamically
- Stop deployment if there are an issues part of the Release that are not Done
- Retrieve version numbers
Question: Is there a VSTS equivalent?
azure-devops jira azure-devops jira asked Nov 16 '18 at 1:32
AshAsh
682728
asked Nov 16 '18 at 1:32
AshAsh
682728
asked Nov 16 '18 at 1:32
AshAsh
682728
asked Nov 16 '18 at 1:32
AshAsh
682728
asked Nov 16 '18 at 1:32
AshAsh
682728
682728
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/organization/project/_apis/wit/reporting/workitemrevisions?types=YourCustomWorkItemType&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.YourFieldName' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
answered Nov 16 '18 at 13:11
ThomasThomas
189110
Thanks, but I think you might be misunderstanding what I’m asking. I’m not after Azure DevOps equivalents for the scenarios I’ve listed in my question as those are just examples of things you can do with the one JIRA feature that I’m asking about; and that’s a special work item type (if you want to call it that) called a Release. This is not a pipeline; it simply contains release notes (text), release description (text), and a list of issues that are part of the release.
– Ash
Nov 17 '18 at 17:59
Thanks Ash, I have completely revised my answer based on your clarification and my re-reading your question properly.
– Thomas
Nov 19 '18 at 9:34
Thanks Thomas. Appreciate the complete revisal :) Yea I had a feeling it would need to be a custom WIT. I guess my next question is, can custom WITs be retrieved via the Rest API?
– Ash
Nov 19 '18 at 21:54
...because with JIRA, you have a /versions endpoint, which gets you the list of releases. I’m guessing it won’t be as simple as a /<custom_WIT> with Azure DevOps API?
– Ash
Nov 19 '18 at 23:30
Absolutely, the Azure DevOps REST API supports this, I have added an example to the answer.
– Thomas
Nov 20 '18 at 9:50
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53330210%2fis-there-an-equivalent-of-jira-releases-in-vsts%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/organization/project/_apis/wit/reporting/workitemrevisions?types=YourCustomWorkItemType&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.YourFieldName' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
answered Nov 16 '18 at 13:11
ThomasThomas
189110
Thanks, but I think you might be misunderstanding what I’m asking. I’m not after Azure DevOps equivalents for the scenarios I’ve listed in my question as those are just examples of things you can do with the one JIRA feature that I’m asking about; and that’s a special work item type (if you want to call it that) called a Release. This is not a pipeline; it simply contains release notes (text), release description (text), and a list of issues that are part of the release.
– Ash
Nov 17 '18 at 17:59
Thanks Ash, I have completely revised my answer based on your clarification and my re-reading your question properly.
– Thomas
Nov 19 '18 at 9:34
Thanks Thomas. Appreciate the complete revisal :) Yea I had a feeling it would need to be a custom WIT. I guess my next question is, can custom WITs be retrieved via the Rest API?
– Ash
Nov 19 '18 at 21:54
...because with JIRA, you have a /versions endpoint, which gets you the list of releases. I’m guessing it won’t be as simple as a /<custom_WIT> with Azure DevOps API?
– Ash
Nov 19 '18 at 23:30
Absolutely, the Azure DevOps REST API supports this, I have added an example to the answer.
– Thomas
Nov 20 '18 at 9:50
|
show 1 more comment
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/organization/project/_apis/wit/reporting/workitemrevisions?types=YourCustomWorkItemType&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.YourFieldName' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
answered Nov 16 '18 at 13:11
ThomasThomas
189110
Thanks, but I think you might be misunderstanding what I’m asking. I’m not after Azure DevOps equivalents for the scenarios I’ve listed in my question as those are just examples of things you can do with the one JIRA feature that I’m asking about; and that’s a special work item type (if you want to call it that) called a Release. This is not a pipeline; it simply contains release notes (text), release description (text), and a list of issues that are part of the release.
– Ash
Nov 17 '18 at 17:59
Thanks Ash, I have completely revised my answer based on your clarification and my re-reading your question properly.
– Thomas
Nov 19 '18 at 9:34
Thanks Thomas. Appreciate the complete revisal :) Yea I had a feeling it would need to be a custom WIT. I guess my next question is, can custom WITs be retrieved via the Rest API?
– Ash
Nov 19 '18 at 21:54
...because with JIRA, you have a /versions endpoint, which gets you the list of releases. I’m guessing it won’t be as simple as a /<custom_WIT> with Azure DevOps API?
– Ash
Nov 19 '18 at 23:30
Absolutely, the Azure DevOps REST API supports this, I have added an example to the answer.
– Thomas
Nov 20 '18 at 9:50
|
show 1 more comment
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/organization/project/_apis/wit/reporting/workitemrevisions?types=YourCustomWorkItemType&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.YourFieldName' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
answered Nov 16 '18 at 13:11
ThomasThomas
189110
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/organization/project/_apis/wit/reporting/workitemrevisions?types=YourCustomWorkItemType&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.YourFieldName' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
answered Nov 16 '18 at 13:11
ThomasThomas
189110
edited Nov 20 '18 at 9:50
answered Nov 16 '18 at 13:11
ThomasThomas
189110
answered Nov 16 '18 at 13:11
ThomasThomas
189110
answered Nov 16 '18 at 13:11
ThomasThomas
189110
189110
Thanks, but I think you might be misunderstanding what I’m asking. I’m not after Azure DevOps equivalents for the scenarios I’ve listed in my question as those are just examples of things you can do with the one JIRA feature that I’m asking about; and that’s a special work item type (if you want to call it that) called a Release. This is not a pipeline; it simply contains release notes (text), release description (text), and a list of issues that are part of the release.
– Ash
Nov 17 '18 at 17:59
Thanks Ash, I have completely revised my answer based on your clarification and my re-reading your question properly.
– Thomas
Nov 19 '18 at 9:34
Thanks Thomas. Appreciate the complete revisal :) Yea I had a feeling it would need to be a custom WIT. I guess my next question is, can custom WITs be retrieved via the Rest API?
– Ash
Nov 19 '18 at 21:54
...because with JIRA, you have a /versions endpoint, which gets you the list of releases. I’m guessing it won’t be as simple as a /<custom_WIT> with Azure DevOps API?
– Ash
Nov 19 '18 at 23:30
Absolutely, the Azure DevOps REST API supports this, I have added an example to the answer.
– Thomas
Nov 20 '18 at 9:50
|
show 1 more comment
Thanks, but I think you might be misunderstanding what I’m asking. I’m not after Azure DevOps equivalents for the scenarios I’ve listed in my question as those are just examples of things you can do with the one JIRA feature that I’m asking about; and that’s a special work item type (if you want to call it that) called a Release. This is not a pipeline; it simply contains release notes (text), release description (text), and a list of issues that are part of the release.
– Ash
Nov 17 '18 at 17:59
Thanks Ash, I have completely revised my answer based on your clarification and my re-reading your question properly.
– Thomas
Nov 19 '18 at 9:34
Thanks Thomas. Appreciate the complete revisal :) Yea I had a feeling it would need to be a custom WIT. I guess my next question is, can custom WITs be retrieved via the Rest API?
– Ash
Nov 19 '18 at 21:54
...because with JIRA, you have a /versions endpoint, which gets you the list of releases. I’m guessing it won’t be as simple as a /<custom_WIT> with Azure DevOps API?
– Ash
Nov 19 '18 at 23:30
Absolutely, the Azure DevOps REST API supports this, I have added an example to the answer.
– Thomas
Nov 20 '18 at 9:50
Thanks, but I think you might be misunderstanding what I’m asking. I’m not after Azure DevOps equivalents for the scenarios I’ve listed in my question as those are just examples of things you can do with the one JIRA feature that I’m asking about; and that’s a special work item type (if you want to call it that) called a Release. This is not a pipeline; it simply contains release notes (text), release description (text), and a list of issues that are part of the release.
– Ash
Nov 17 '18 at 17:59
Thanks, but I think you might be misunderstanding what I’m asking. I’m not after Azure DevOps equivalents for the scenarios I’ve listed in my question as those are just examples of things you can do with the one JIRA feature that I’m asking about; and that’s a special work item type (if you want to call it that) called a Release. This is not a pipeline; it simply contains release notes (text), release description (text), and a list of issues that are part of the release.
– Ash
Nov 17 '18 at 17:59
Thanks Ash, I have completely revised my answer based on your clarification and my re-reading your question properly.
– Thomas
Nov 19 '18 at 9:34
Thanks Ash, I have completely revised my answer based on your clarification and my re-reading your question properly.
– Thomas
Nov 19 '18 at 9:34
Thanks Thomas. Appreciate the complete revisal :) Yea I had a feeling it would need to be a custom WIT. I guess my next question is, can custom WITs be retrieved via the Rest API?
– Ash
Nov 19 '18 at 21:54
Thanks Thomas. Appreciate the complete revisal :) Yea I had a feeling it would need to be a custom WIT. I guess my next question is, can custom WITs be retrieved via the Rest API?
– Ash
Nov 19 '18 at 21:54
...because with JIRA, you have a /versions endpoint, which gets you the list of releases. I’m guessing it won’t be as simple as a /<custom_WIT> with Azure DevOps API?
– Ash
Nov 19 '18 at 23:30
...because with JIRA, you have a /versions endpoint, which gets you the list of releases. I’m guessing it won’t be as simple as a /<custom_WIT> with Azure DevOps API?
– Ash
Nov 19 '18 at 23:30
Absolutely, the Azure DevOps REST API supports this, I have added an example to the answer.
– Thomas
Nov 20 '18 at 9:50
Absolutely, the Azure DevOps REST API supports this, I have added an example to the answer.
– Thomas
Nov 20 '18 at 9:50
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53330210%2fis-there-an-equivalent-of-jira-releases-in-vsts%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
