I'm a bit confussed as to the best way to handle our projects in TFS.
We are a CMMI level 3 (working on level 4) compliant organization. As such we are currently using the MSF CMMI process template in TFS, which I'm working on customizing to beter suite the needs of our organization.
With each new release (whether that be a major or point release) we have to follow a standard process that includes multiple qualtiy gates and required documentation (project plan addendums, deployment plans, qualtity gate presentation materials, requirement review documents, etc). My problem is that from what I can see, TFS only requires process to be met with each project not release (we have been trying to use iterations to identify the releases).
The question is, is there a way to have a process indicate the documents required for each release or do I need to start a new TFS project with each release.
As a potential follow on question. If you need to create a new project each for each release, how do you handle source control and work item history.
You are right that opening a new TFS project for each release is probably overkill.
Instead, I recommend creating a release plan for each release, and associating each needed document with a Work Item.
Here are some details on one way to create a release plan, and here is an example template with helpful types built in.
If you have a bunch of spare time lying around, you can customize Work Item fields to create tasks that fit your documentation requirements.
To manage multiple releases in a single TFS project, I recommend simply creating multiple folders, and adding Work Items associated with each release to each folder.
Related
We are using TFS on premise, version 2015 update 3. We are using multiple team projects. Some Team Projects are used for applications (source control and builds), other team projects (with multple teams in it) are used for work item tracking. Teams can work on different applications.
Now we are looking into the Release functionality. Preferably we would like to use 1 team project to keep track of all the releases, so we get an overview of all releases in our organisation. But I can't figure out how to achieve this.
Is there a way to define release definitions linked to builds from an other Team Project? Here Microsoft says: "No additional setup is required when deploying Team Build artifacts published within the same team project." So I guess it should be possible to do an additional setup, but I can't figure out how.
We also have many team projects
We are using TFS 2015 CU2 but I do not think there are to many differences between the two versions.
The artifact link are for team builds within the same team project. I do think there is a way you can link to builds outside to other team projects.
In your one team project you could create all your CI builds there (in the build defintion mappings would can map to any source control path you want you simply have to cut in the path.)
If you still using your XAML build definitions; you could use the TFS Communinity build manager add-in for VS 2013 and clone the build defnition to you new team project.
So there is not easy way currently. We have chosen to release from every team project. The release overview is nice but we chose that it was not worth the effort. Maybe in the next release we will revise.
You shouldn't separate aspects of your project (builds, code, releases, work items, etc) into different team projects. You lose all tracability if you do that, as you're seeing.
You can manage your application portfolio within a single team project with the appropriate use of Teams, but discussion of exactly how to achieve that is going to be very specific to your organization and thus is too broad to discuss on Stack Overflow.
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.
What is the recommended organizational structure of team projects in TFS 2010? Let's say we have 4 big departments within our enterprise. Is the recommended approach to create a team project for each department or logical representation of one's organization and have different folders for VS projects within those TFS team projects? Or should each reasonable big project have their own team project?
I am asking more from a perspective of code storage and TFS artifacts. If we are to store both code and user stories, tasks, etc. in one big team project, does that hinder the agile development process? We can still setup separate queries and a separate dashboard for each "project" within the big team project. However, the builds would be in this giant list of builds.
If we had many smaller team projects, it would be more difficult for QA to span their work across multiple team projects. They'd need to know where to enter bugs - knowledge that we don't necessarily want to rely on.
So what is the best practice?
Storing everything in a single project will not hinder "the agile development process". My recommendation would be to create an area path for each project, and organize your work items under those area paths. You'll have a product backlog query for each area. Use the iteration path field to then drive a schedule across all the projects. That should work fine. All the reports can then be filtered by area and/or iteration.
For builds, I see many teams prefixing build definitions to provide better organization. Here's a blog post that describes an extension you can download to help better organize builds.
http://blogs.msdn.com/b/bharry/archive/2011/04/01/build-folders.aspx
In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).
All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:
Is it possible / feasible to use one of the existing projects as the target project for the other three?
How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
Today we have work item links from one team projects into another - how do we keep these links when merging?
What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?
Thanks for your help!
Unfortunately, TFS 2010 doesn't allow you to merge team projects.
Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don't make the up-front planning necessary and don't understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS :(
When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it's a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.
Ultimately, a "migration" doesn't end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)
Some additional thoughts for each of your original questions:
Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don't want to rename the team project. :)
This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
That's ultimately up to you. I would do a "move" version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.
It's not the best story for you but hopefully it will help your planning out some!
We're starting to user Team Foundation Server and my boss would like some way to "archive" projects. Meaning after they are completed, remove them from an "active" state so that only "active" projects are visible.
Does anyone have any experience with this?
I've thought of 2 options.
1) Create 2 base projects. 1 for active projects and 1 for achived projects
2) Remove all users from the archived projects.
Thanks,
Sam
I would personally recommend waiting for TFS 2010 when more functionality will be introduced that will assist you in the ability to "archive" Team Projects.
In TFS 2010 you will hopefully be able to move a team project to a new Team Project Collection. Actually you do this by duplicating your "active" project collection and then deleting all the team projects from it apart from the one that you want archived. In this active project collection, delete the archived project that you have a copy of in the duplicated project collection. This archived team project will then live in it's own project collection which means it has it's own database etc which can be easily backed up / archived etc.
The archived team project project collection can then be left as it is as it doesn't slow down the server any if not being used - or it could even be detached from the TFS Application instance so that it doesn't show up at all and re-attached at any time.
An advantage of using project collections in TFS 2010 is that full Version Control and Work Item Tracking history will be maintained.
I would use it just as you normally do, but when you are done with the project then you remove it from the visible list. (In Visual Studio you can right click on a project in the team explorer and say remove.)
If you are worried about changes after the project is done, then remove the users from the contributors list. If you really want to boot the users out (so they cannot even see it) then you can deny them rights to the project.
This way you don't have to see it, but you can keep all your projects on the base level.
I would NOT recommend having just 2 base project for active and in-active. A TFS project should not be based on a state.
We created an "Archive" team project and we regularly move unused source code to that team project. It has worked out well for us, the history is preserved so we can always reference the archive project for old code or information on past changes. We also limit access such that developers have read access but only TFS administrators have write access. I haven't checked to see how these moves impact the association of check-ins with work items - mostly because everything we archived was checked in before we moved to TFS.
As for the one active team project, I was led to believe by knowledge experts and online documentation that this wasn't the best way to organize team projects. I think ideally you group projects/solutions together into a single team project if they are related (i.e. by line of business or dependencies).
I'm sure you've already done your research, but there is plenty of documentation out there that might assist (especially if your team maintains a single application or a handful of applications). I would suggest starting with patterns & practices: Team Development with TFS.