We are using TFS 2017 as our project management system, and I'm missing a functionality that seems to be available in most other solutions: it's the ability to regroup tasks/user stories/bugs/etc into a single set (called Milestone in Github, or Version in JIRA) to be able to track the work done and remaining for the release of a defined set of functionalities.
Does TFS provides an equivalent to those Milestones/Versions?
It sounds like a sprint / iteration to me.
Since Iteration path is hierarchical you can create nodes that represent Releases or Milestones (versions are a bad idea) and then have your Working Time as Sprints under them.
Release 1
Release 1\Sprint 1
Release 1\Sprint 2
Release 1\Sprint 3
Release 1\Sprint 4
release 2
Release 2\Sprint 1
You can then have a variable number of Sprints inside of each Release. If you are in VSTS you get good visual planning tools to help you plan across releases or sprints...
Another options would be to add a custom field for the data that you want to track.
Usage of Iterations is typically the way to go. However, you can also use Tags and Queries to create release or milestone lists that are either flat or hierarchical. If the queries are flat, you can create graphs/charts and dashboard them as well.
Delivery Plans also add yet another alternative to help visualize timelines and create markers for important dates/milestones.
Related
I come from using Rally and Pivotal Tracker. In both I could assign work items to Releases as a planning tool, and to have a historical record of those work items that were deployed.
Even with all the highly-specific guidance from Microsoft about Azure DevOps, it is silent how to organize work against future Releases. I can't see a place to even associate a work item to a Release. Is there something I am missing in all the documentation, or is there some workaround strategy more robust than just using tags to pro-actively plan against releases? Or is Microsoft's expectation that I use some separate product management tool to manage work items against Releases?
There are multiple techniques employed to accomplish this, not "one way":
use a parent iteration path that groups the iterations you plan against a certain release. This works best when you completely finish one release before starting the next. Otherwise, it usually becomes a mess with multiple active iterations.
Backlog Iteration
+ Release 1.0
+ Sprint 1
+ Sprint 2
+ Sprint 3
+ Release 2.0
+ etc
-
use tags for releases. Add a tag [Release 1.0] top all work items that are included in that release, this is one of the most flexible options.
use Azure Pipelines to keep track of which Work Items were associated to which Git commits and thus was included in which Build artifact. Track the build artifacts across environments to see which work items were deployed to an environment by looking at the intermediate builds.
add a custom work item field to the work item types you want to track. You can change the work item process being used and you can add a field to the work items in which you can specify the release name/number. There are custom controls available that can scope the version numbers to a specific list or can fetch the allowed values from any REST API.
Azure DevOps is more flexible in the usage patterns as you can see, but it also means that sometimes you need to "figure out what works best" for your team.
Another extension you may be interested in is the Bravo Notes extension. Or one of the other extensions that can generate Release Notes based on you work item data, commits and/or pipeline artefacts.
Similar to this question but for Azure DevOps. Going back 6-12 months, I was able to open a deployed Release (or possibly a successful Build, my memory is hazy) in what was then VSTS and view the backlog Work Items associated with it. On that page I was also able to filter on release names so that the list would show me all Work Items associated with any Release from the same Release Definition that was newer than the one I filtered on. This was how I used to put together our user-friendly release notes. It allowed me to view the bugs that'd been fixed, the features that'd been included, and so on. As far as I can tell, this feature no longer exists in Azure DevOps - at least, I can't find it.
The closest I can get is to view a list of Changesets from a particular date in the Changesets pivot, but that's not as comprehensive as a list of Work Items that were completed, and also doesn't tell me which Release those Changesets were included in.
I can also run a Query to show Work Items completed from a particular date but again I don't think I can view what Releases those Work Items were associated with, and even if I could it wouldn't help much unless I could filter Work Items based on the repository branch from which the Release was created.
Does anybody know if there is a way now in Azure DevOps to view the Work Items associated with a particular Release or Build? And, ideally, a list of Work Items associated with any Build or Release created from a specified Build or Release Definition from a particular date (e.g. "Show me all Work Items associated with Builds created from the 'Education Only Version' Build Definition since January 1st").
Howzit
Edit: I just realized this question was long ago... it showed near the top, assuming you have this solution but now
When you deploy a stage you can see all the work items and commits that are linked to commits since the last build that went to that stage.
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?
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.
I notice that the docs say that Epics are groups of stories, and that Releases are simply markers above and below prioritized lists of stories. I also note that we can use Epics as a kind of special label or tag to denote what can go in a release. My question is, are you using Pivotal Tracker epics to label what you WANT to go into a release, or what WILL go into a release, and why? Where in the process do you actually assign the epic label to the story?
Personnaly, I use epics to have a high level view of relative feature load on the team. It helps understand where time went the last couple of months.
we recently decided to move to TFS 2010. we would like also to improve our source control structure and projects structure.
here is the structure the team agreed on:
|OurCompanyName (or common root name)
|
+--Windows
+----Applications
+------App1
+------App2
+----Services
+------WindowsService1
+------WindowsService2
|
+--Web
+----Applications
+------WebApp1
+------WebApp2
+----Services
+------WebService1
+------WebService2
|
+--Common
+----ThirdParty
+----Libs
+------DataAccessLib
+------BusinessLogicLib
|
+--Tests
+----TestProject1
+----TestProject1
The common folder holds 3rd party and our in-house libraries which is used all-over(App1,App2,WebApp1...etc)
We need to acheive the following :
Release versions must depend on latest production release of Libs.
if tests failed, depended projects shouldn't build and team should be notified.
simple branching: development, production,versioned releases and how we can structure them accordingly.
I have already read the following guide Visual Studio TFS Branching Guide 2010 but it only addresses the branching bit of it.
You aren't really asking a question from what I can tell. But I can give some feedback/discussion on your goals.
Release versions must depend on latest production release of Libs.
A release version should depend on whatever it used while it was being developed. Not whatever the current version is. You may want to go into more depth on what this requirement is and why you think you need it.
if tests failed, depended projects shouldn't build and team should be notified.
TFS doesn't support chaining builds out of the box, you can modify the build template to add support, but it's not a particularly clean solution (imo).
You can self subscribe to failing builds utilising the built in tfs alerts subscriptions, however it is up to each developer to do so. (Unless you subscribe a mailing group or create a custom event mailer).
Again why are you automatically updating dependencies in other projects? surely you'd be better off using a pull for updates than a push and use a technology like NuGet to handle your references.
simple branching: development, production,versioned releases and how we can structure them accordingly.
That sounds like simply branching each time you do a release, which is very simple.
If you however knew which changeset you releases you wouldn't have to branch and could branch only if you needed it (eg to fix a production bug). It takes a lot more work as you either need to manually label your code on release (at which point you gain nothing over branching) or have an automated release process which does it for you.
Other notes
You dont' want to use multiple Team Project Collections - this adds in a nightmare when it comes to managing build servers.
You may want to update your diagram to show what is a Team Project, Branch, and what is just a standard folder.
Having used TFS for a while, I would like to give a caution:
You look at things from the developer's side, as we did when we started thinking about how to best deploy the projects. However, you should also take under account project management requirements.
Having different TFS projects, means different reporting data to the manager.
Thus if App1 and WebApp1 are to the person that runs your projects part of the same overall project, then if you have them in different TFS projects, questions of the form: 'How many hours did my team spend on this project' will be difficult to answer.
I would seriously look into this issue before deciding on the project structure.
Now regarding your questions:
Release versions must depend on latest production release of Libs
As Betty (above) mentions this is not good practive. What will happen if development took place with production release of Lib v1.0 and sometime during stabilization Lib changed to v2.0 ?
if tests failed, depended projects shouldn't build and team should be notified.
I believe this is a matter of your build script, not of your layout
-simple branching
We try to implement a simple MAIN-line based approach,where we have one or more development branches (depends really on your specific requirements).
Once in a while, when dev code is considered 'stable' i.e. passed basic unit tests, it is merged onto the MAIN line. Developers carry on, on their development branches whereas code on the MAIN line goes more extensive testing. Bugs found are reported and fixed initially on the DEV branches and merged back onto the main line. Once code on the MAIN line is good enough, stabilization starts on a RELEASE branch. After that point, bugfixes take place on the RELEASE branch and merged back into the MAIN line. Note that 'stable', 'good enough' are values that mean different things to organizations.