We started using TFS 2013 as bug tracker some time ago (about 3 months). Before this we used TFS only as source control (bug tracking was performed in another software). For now we have developed some processes. We would greatly appreciate any comments, that would help us to understand, whether this processes are right, or not. So, here they are:
General info:
We are developing one big product.
Our team has 5 developers and 2 QA's.
Often we release new versions each 1-2 months.
We have 1-week sprints.
This is how we use TFS:
We have one team project and a number of areas in it. Each area represents some part of the product.
Our team project uses Scrum 2.2 template.
In the team project we create a "big" iteration for each release (e.g. "Release 01.2014", "Release 03.2014"), which starts from the end of previous iteration and lasts 1-2 months.
We use 2 standard work item types: Tasks and Bugs
All bugs and tasks belong to the appropriate "big" iteration and area.
We use tasks in 2 ways: as a standalone work item for any improvements and new features, and as the child of a bug when fixing a bug.
To monitor current situation we created a bunch of queries for TWA. Some of them are shared (Such as "Bugs new","Bugs for testing", "Tasks in progress" and others), and some of them are created by each dev/QA (e.g. "My tasks in progress", "My bugs done" and others).
Here goes work process description for Bug:
-->QA (or dev) creates a bug (State: New)
-->QA (or dev) assigns this bug to some dev (State: Approved)
-->When dev starts to fix a bug, he does the following:
---->changes state of bug to Committed
---->creates child task and changes its state to InProgress
-->When dev commits some code, that should fix the bug, he bounds checkin to task (created on previous step)
-->QA understands, that bug is fixed and ready for testing, when bug is in Committed state and EACH child task is in Done state
-->QA tests fixing of bug:
---->if bug is not fixed he changes state of bug to Approved
---->if bug is fixed he changes state of bug to Done
This process looks not bad, and somehow works. But there is a problem with standalone tasks, which is created for improvements and new features.
And here goes process description for standalone Task:
-->QA (or dev) creates a task (State: ToDo)
-->QA (or dev) assigns this task to some dev (State: ToDo)
-->When dev starts working on this task, he changes its state to InProgress
-->When dev has finished working on task, he changes its state to Done
-->QA tests this task:
---->if new features work fine ?
---->if new features work with errors ?
Here is the main problem: how can QA mark Task as passed or not passed the tests?
How we resolved it for now: QA's marks tested tasks with tag "Closed", if all is ok, and creates child bugs for task if there are some errors.
But working with tags this way seems not to be good.
EDIT One more question: Which state of Bug/PBI is most suitable for state, when bug was assigned to developer, but he did not started working on this bug yet?
Any comments and suggestions will be greatly appreciated.
You are not using the Scrum template as intended.
The typical approach is to use Product Backlog Items to represent features, and child Tasks to represent the work necessary for PBI's or Bugs.
Teams will often have one (or more) tasks that represent the testing work that needs to be performed for each PBI/Bug. Then you can track if testing is done or not by looking at the status of the tasks.
Maybe more work/overhead than you're interested in investing, but have you looked in to using the "Test Case" workitem type? A couple fancy things about Test Cases:
They can be attached to a Task to specify the task is "Tested by" that test case
They can have results, making the definition of the test reusable across iterations
There's a bunch of built-in reporting for showing what the current status of testing is (passed vs failed vs not run, etc)
There's even UI for entering test results and managing test cases in the TFS web interface
Tests don't have to be automated, but it's nice if they are. You'd get all the above benefits even if you're only using "Manual" tests
More info here: http://msdn.microsoft.com/en-us/library/dd380763.aspx
Related
I have created a new project in VSTS (Visual Studio Online) using the Agile Template.
I have created a sprint, and added a user-story. Within the user-story I have some tasks.
On the sprint Kanban board there are 4 columns;
New
Active
Resolved
Closed
I can move tasks from New to Active, but cannot move them from Active to Resolved.
How do I do this?
This confusing behavior is because the Agile Template shows both Bugs and Tasks on the same board view. While Tasks have a New -> Active -> Closed workflow, bugs have an additional Resolved step.
Your task should transition directly from Active to Closed.
You bugs will be able to rest a bit in the Resolved column before being dragged all the way to Closed.
To recall your question:
I can move tasks from New to Active, but cannot move them from Active to Resolved.
This is also not a problem in Azure DevOps but the standard process (Agile workflow states). The following are the steps that can be used for the workflow in the standard process:
User Story (New, Active, Removed, Resolved, Closed)
Bug (New, Active, Resolved, Closed)
Task (New, Active, Removed, Closed)
In Azure DevOps, however, this workflow can be adapted. For this the process must be modified. Here you can also add Resolved for a task within the workflow. Role "Collection administrator" is needed.
via Organization settings / Boards / Process / Agile (default) ... Create inherited process
Further information and picture source under https://learn.microsoft.com/en-us/azure/devops/boards/work-items/guidance/agile-process-workflow?view=vsts
and https://learn.microsoft.com/de-de/azure/devops/organizations/settings/work/manage-process?view=vsts&tabs=new-nav#create-inherited-process
You need to first create an inherited Process from Agile template as explained here:
https://www.visualstudio.com/en-us/docs/work/process/manage-process#create-inherited-process
Then , you can simple Hide the "Resolved" state for Bugs from your workflow as shown here:
https://www.visualstudio.com/en-us/docs/work/process/customize-process-workflow
That's it! the column is gone from your Task Board!
Moreover: you can now add your own States and Columns.
Good luck!
Michael
My team is just now starting to use TFS 2015 Update 1 on premise to manage their development process. I have set up the server and defined some custom states and transitions for work items to better map to our process. To start with, we will only be taking advantage of the Kanban board and are not attempting to use iterations for a variety of reasons I won't get into here.
My problem currently is using TFS to plan releases. Specifically, I don't see any way to group Features and User Stories into a specific release. All of my googling has turned up many articles involving Microsoft Release Management, so I installed and configured it, but it is absolutely overkill for what my team is trying to do right now. I'm not trying to automate deployments to different environments at the moment, I just need a way to group work items into a something that encapsulates the concept of a release in TFS. Is there no way to do this? The best I can come up with right now is to further modify the work item templates to either provide a simple "Release" field with a pick list, or define another type of work item that I can group the others into. This seems like a glaring oversight by MS from my perspective, so I'm hoping I'm just missing something.
Grouping work into releases can be done in a couple of ways, just remember that the concept of a "Release Plan" doesn't explicitly exist in TFS. Release management covers the "Release to Production", but doesn't cover any planning.
Ways to plan releases:
One way is to create a Release Iteration, this works when you're not working on multiple releases in parallel and truly finish one release before working on the next. The Release iteration used to be default, but has been removed from the product in favor of teams delivering sprints and teams doing continuous delivery.
Project Root
+ Release 1.2
+ Sprint 1
+ Sprint 2
Another option is to use Tags. You could tag work items with a tag that signifies it's targeted for a specific sprint.
Use a Marker workitem, on the backlog place one work item which clearly stands out ### END OF RELEASE 1 ### Any workitem below it is not part of that release. This technique fits a more agile way of working and more clearly shows that the contents of a release are a floating thing.
Create a custom Release Workitem, link your other workitems to this work item to target it for that release.
And your option to create a picklist on a *Custom workitem field** is another option.
Alternatively you could also use the Area Path in much the same way as Iteration Path. By using the Area Path you have the benefit of not having a sprint tied to one specific release.
It is not the best solution but could be the solution in some cases.
Answering solely based on your question around planning releases, then:
Create a custom work item template, called 'Deployment'.
When planning of a release begins, create a new 'Deployment', let's say, called 'MyProduct v1.1'.
In your planning meeting, create Features and User Stories appropriately, and create a relation to the 'MyProduct v1.1' Deployment, by opening the User Story and adding a Link (using the Deployment Work Item number) as 'Related'.
To monitor Deployments, create a custom Work Item query targeting the new 'Deployment' Work Item template. You can configure this to display on your dashboard.
Follow whatever release procedure you like based on the 'Deployment' and its' relations.
You should follow a naming convention when creating 'Deployments' for consistency.
p.s. I recommend using the extension 'Work Item Visualization' in this instance. It'll nicely map out the 'Deployment' related Work Items.
If you want to use TFS to actually build an and create a Release, then Release Manager is worth considering.
TFS 2015 Update 2.1 now includes a built-in version of Release Manager. It's much more user-friendly and simple to configure when compared to Release Manager standalone installations.
To group work items into a 'release', you can do the following:
Create a build definition for the repository you're working with - see Build Def creation docs
Create a Release definition - see Release Def creation docs
Once you have these definitions created, the working process would be:
Developers work against work items
Commits are made against the WI number (or tasks)
When it's time to create a release, start a build on the definition you created. In doing so, WIs will then be associated with a Build Number.
When the build succeeds, start a new Release from the definition you created.
You have have a set of work items associated with a release, see screenshot:
Note: You can enable CI builds and releases, although the above is based on manual triggers.
You can also directly call the Release API to locate WIs associated with Releases, however you'll need to obtain the actual Id of the release first.
You are currently limited however to viewing these relationships based on knowing the Release. In a real world scenario, it's more realistic to look at a Work Item to see when it was release. To do that, there's no built-in functionality at present, however my own-answered question will guide you - see here.
Additional to the methods explained by jessehouwing there exists also several 3rd party tools which can integrate with TFS/VSTS and provide advanced planning features. See VSTS Marketplace for an overview.
When I have defined a Gated Build, when somebody checks in code the Integration Build field of a work item changes to the Gated Build number (if the developer associates his check in with work items, of course). Once a CI build is triggered this field changes to the CI build number.
My question is: Is there any way of not changing the Integration Build field of a work item once a Gated Build is triggered?
EDIT
Let me be more clear about how we work.
We have several work itens (some are user stories and some are bugs). When a developer checks in code he or she associates his/her check in with those user stories that gets the Resolved state and a "Gated x.x.x.x" in the integration build field. We never test gated builds. Instead, every night we manually trigger a build and those work itens gets updated again, but this time with a "Release x.x.x.x" in the integration build field. In the next day we test those work itens but the process continues and developers keep check in more US or Bugs (that will have the Gated ...).
Sometime we get confused and we test work itens that should not be tested because they are in the "Gated state".
Even if we have branches that will not solve our problem because the developer associates a check in with work itens and we cant change that.
We do not test gated builds because our QA team is small. The dev team have 20 developers and the QA team have only 2. The process of deploy the application takes about 10 minutes and it can be a pain to wait 10 minutes on every developer check in. Also changing the code while we are testing is never a good idea because it can mess up with our test.
Somebody can think that our process is wrong and suggest a new approach. This will be very welcome, but what we do is working very well besides that small issue.
My fairly-large project uses gated builds, with a heavily-customized process template (XAML). For reasons beyond the scope of this question, our process has a single SharedResourceScope, so multiple builds don't run in parallel (I know you're supposed to do that with an Agent scope, but we switch agents in the middle, so wrapped everything with the SharedResourceScope).
Now, if there are several check-ins in queue, all of them go into "In Progress" state, and all but one wait on the SharedResourceScope. This means that:
People can't know which build is actually running
Even if I set a new queued check-in to be high-priority, it can't overtake all those who are in progress and waiting on SharedResourceScope, so the whole priority setting has little meaning.
I've experimented using DefaultProcessTemplate.XAML, and I see that usually only one build is In Progress (though Occasionally I see 2 builds).
Questions:
When exactly does a build start, and therefore goes into "In progress" mode? What prevents all builds from starting immediately, and blocking on AgentScope / SharedResourceScope?
Is there something I can author in my XAML to prevent all builds to go in progress?
A build starts when the build controller has capacity to start a new build. Since builds can use 0 to n agents, the controller doesn't wait to get an agent before the build starts. The controller determines its capacity based on the "Maximum number of concurrent builds" setting on the controller properties (in code: MaxConcurrentBuilds).
Default setting: "Default to number of agents".
No way in XAML to control this behavior.
Also, there's a bug in TFS2010 regarding this, hotfix: KB2567437
Using TFS Build Extensions, you get a number of activities with which you can administer agent control through the process: QueryBuildAgentStatus, IsBuildRunning, SetBuildAgentStatus to name a few that could be useful to you. They're fairly undocumented as of now, so you'll have to experiment to get them running. But there is a help file included in the package that is useful.
As for the "In Progress" mode, I've noticed that this is the status even if a build is waiting for a free agent; check the log of such a build and you'll see. This is quite confusing, and I hope that MS will add a "Queued (but not started)" mode.
Question:
What is the best practice for creating branches for development and release based on the information provided below?
Background:
I work in a small development team (2.25 frontend, 2 backend), and we have a yearly release schedule. Our environment does not allow for patches or services packs mid-year, but every once in a while if our user's environment changes we will release a "recompiled" version with a few bug fixes thrown in (on the current stable version).
Currently we do all of our development on the mainline and then create a branch (5 so far) for the code freeze and do minor bug fixes and the bulk of our testing. Once the version is sent out for layering and deployment we merge these bug fixes back to the mainline where we have continued to develop new functionality for next year's release. The branch stays in our repository forever.
The way TFS does its branches is by having a new "folder" in the source control, and it is starting to get a little cluttered.
Thoughts:
Maybe the way we are doing this is right, but it just feels like in a few more years there will be a large number of branches that are never going to be touched... seemingly ever. Maybe it is possible to create a single "Stable Release" line that has each new version labeled on it, and then if we need to go back to do a mid-year release then it can be recovered from this single line.
Upgrade your environment to 2010 ASAP - TFS 2010 branching is vastly superior, including management.
Your idea sounds about right - you branch off a release version when you have one, then just fix it.
You just have to live with the versions accumulating. This makes sense - until you totally retire one (and "never" is not real here, I bet after 7-8 years you kill an old version) there simply is no other way.
A few places I have worked would handle that like this:
Devs never touch "main" branch directly and it always represents what is in production
A single "maintenance" branch is used for all of your changes throughout the year.
At the end of the year, after all of the changes are ready to go, label everything approprirately and the maintenance branch is merged back into the mainline. A new release build is prepared from the mainline and sent out.
Ongoing changes happen in the maintenance branch.
Rinse and repeat as needed.
Benefit is that you only ever have 2 branches. That makes some SCM related tasks easier to deal with since you don't have to keep dealing with changing folder names, etc.