I'm new to TFS and we're loving it! I'm having a difficult time figuring out how best to organize TFS from version control and agile/scrum/sharepoint sites, keeping isolation of teams yet sharing of code and projects.
For this scenario let's say I have three teams. Team 1, 2, 3. I want each team to have access to only projects they work on, and each team to have isolation for alerts and notifications, sharepoint, agile, etc. So let's say there are 5 total projects.
Team 1:
--Project 1
--Project 2
Team 2:
--Project 1
--Project 4
--Project 5
Team: 3:
--Project 1
--Project 2
--Project 3
--Project 4
We have one collection setup, DefaultCollection. Right now I only have one team but this doesn't give us good isolation and separation of the features. How can I best configure TFS to keep separation of teams but not have separate code projects? Some projects are shared and this is the point of contention - I don't know how to handle this part.
Acme Widget has X projects and then we have a "Company Shared" with X projects. We may be working on different products such as Acme Widget 1, 2, 3 but all share and work on the Company Shared projects, i.e. Company.Utilities, Company.Windows, Company.Security.
Can someone please shed some light on how to properly configure TFS while we're early into the stages of use. We want to go beyond just version control as mentioned above. We want to use the Task, Bug, Alerts, Build, etc.
P.S. If anyone is a TFS sub-contractor that helps organizations configure their TFS setup I would entertain a professional consultation and configuration.
Since TFS and SharePoint aren't actually holding the user accounts (they are inside Active Directory). It would probably be easiest to create an Active Directory group for each team and place your users in that group. You can then still keep one project collection (no need to over-architect) and then everytime you create a new project within that collection you assign the permissions to that project (TFS, Sql Reports, and SharePoint) using the Active Directory groups. You should download the free TFS Administration tool to manage permissions and when a user joins/leaves a team then you can manage that directly in Active Directory without changing TFS, Sql Reporting or SharePoint. This seems to be a very common approach starting when this issue arose from early SharePoint days when admins were trying to independently manage SharePoint groups and Active Directory groups.
I would suggest that you look at this:
http://blogs.ripple-rock.com/colinbird/2012/11/19/MultipleTeamsWithMicrosoftTeamFoundationServer2012VisualStudioScrumV2xUpdated1452013.aspx
This shows you how you can have multiple teams, which each of theirs board, tasks etc.
We use this in our company because its the same project, but 2 different teams. Then it works perfectly because we have the hierarchy of teams:
-- Project (level 0)
---- Team A (level 1)
---- Team b (level 1)
In that way we can assign stories or tasks to either the one of those, and if they are assigned to the project level (level 0), then it will appear on all teams.
Related
In my org, I have 4 teams and each of them will have their own backlog and will plan their sprints based on this. We want to have a main backlog where the product owners will discuss what work items will go into their backlogs
I would like some guidance as to what is the best practice to use Area path and iteration path to allow the different teams to plan based on their own backlog but also have a Mother of allboards for the POs to discuss and put it under the different teams.
Thanks in advance!
I would like some guidance as to what is the best practice to use Area path and iteration path to allow the different teams to plan based on their own backlog but also have a Mother of allboards for the POs to discuss and put it under the different teams.
In the Azure DevOps boards, it has default area path, if we create another teams, it will create a sub area area path under the default area path.
In my project the default team is test and I create teams test01 and test02, open project settings->Team configuration->Areas, we could see the test team area path is test, test01 area path is test\test01 and tesst02 area path is test\test02, switch team to test and click the button include sub-areas, check the pic below
Now we could see test01 and test02 teams work items in the test team backlog, we could create work item in the test team, and POs could discuss and change the area path to put it under the different teams. You could check the gif below.
There is detailed documentation to work with multiple teams. You can adapt some practics in your process:
Plans (Agile at scale)
How SAFe concepts map to Azure Boards artifacts
Configure Azure Boards to support SAFe
Agile culture
Since you mentioned 'Sprints', 'Product Owner' - I feel Scrum framework would be the best agile method. Product Owner has the final say on what goes on the 'Main Backlog'. When planning a Sprint, I expect you are going to involve all 4 teams. Azure is the best tool to maintaining and delivering backlogs.
For POs and mother of all boards you may have to rely upon a different tool like Asana.
Thanks
Are there any guidelines and best practices for organizing Visual Studio Team Services for a new cloud app? I'm planning on creating a WebAPI solution for REST services, a Xamarin Forms solution for mobile client, an MVC solution for web, and finally SQL scripts. Ideally, I'd like to account for future apps with their own source code.
Dev
App1
WebAPI
XamarinForms
MVC
SQL
App2
...
...
Test
Prod
Another approach is to create a project per App
App1
Dev
WebAPI
XamarinForms
MVC
SQL
Test
...
Prod
...
App2
...
I have also seen people put everything into a single giant project under a single collection. So, instead of creating Dev, Test, Prod projects in the first tree, we'd create them as folders. Same with the second tree. Why would I not want to create multiple team projects?
I'm not a TFS expert, but I'd like to get started on the right foot.
P.S. I've seen a few similar questions on SO but did not think they answered my question, especially the part about not creating team projects.
Visual Studio Team Services (and Team Foundation Server on-premises) support the notion of Team Project Collections, Team Projects and Teams.
A TPC is the highest degree of separation. Currently, you get one DefaultCollection on VSTS. Within this collection you create separate Team Projects. Within a Team Project you have one or multiple Teams.
The current best practices state that a single Team Project is the easiest to work with. In short, this allows you to more easily share code, work items and other assets while still having separate backlogs and code repositories.
For a more detailed explanation see a couple of blogs on this subject such as:
Why You Should use a Single (Giant) TFS Team Project
One Team Project to rule them all
Many Git Repositories, but one Team Project to rule them all
In your scenario, I would absolutely go with one Team Project and then multiple Teams for each separate application. In the top level team you can then schedule Epics and Features and distribute these to the implementation teams.
If I started such a project today, I would also choose Git for Source Control. Git and TFVC are both supported and TFVC is going nowhere. Git however does have some advantages that I think are very attractive.
Regarding your folder structure. If App1 and App2 need to be released together, they should sit in a shared branch. If they can be released separately, they should have their own branch.
The ALM Rangers have a great document on Version Control that explains different Branching models. This is freely available on CodePlex.
I am using TFS 2012/VS 2012.
I have five work items available to me: Bug, PBI, Task, Test Case and Impediment. I cannot figure out how to access user stories, and none of the information put out by Microsoft is very helpful.
I suspect the template that was used to create my project did not include them, but I am not sure. Is this true?
Can I alter my existing project to add user stories or requirements?
When creating a new project, which templates will automatically contain user stories or requirements?
Looks like you used the Scrum Template to create your Team Project. Only the Agile Template includes User Stories by default.
You can use the witadmin.exe tool to add additional Work Item Types to an existing project.
In Scrum PBI is the equivalent of a User Story (and in CMMI the Requirement is the equivalent of a User Story).
I am trying to implement a single Team Project with multiple sub-projects as recommended by this guy and this guy. I can control visibility of work items and source control folders but I cannot control visibility of iterations, teams, groups, and members. Say I have Team Project as the parent project of several sub-projects. Project1_Group has permissions only for accessing Project1_Area and Project1_Foler etc.
I place User1 in Project1_Team and Project1_Group and as expected that user can only see work items within that area. But User1 can go to their Administration page and see all iterations, teams and groups defined for the top level Team Project. User1 can even see groups that exist outside the Team Project by viewing the membership of each user within the current Team Project.
This is a lot of information. As far as I can tell, the minimum PROJECT-LEVEL permission I can give to a user is "View project-level information" (or GENERIC_READ at command line). Without this a user gets a 500 error. With it they get access to all information above. Is there some lesser Project-level permission that will allow full access to the relevant Area but deny read access to high level Team Project information?
No I don't think its possible. Iterations, teams and groups will be visible if you have access to the team project. If you want to permission everything in your project group I think creating separate Team Project is the only solution.
Is there a way to export all of TFS 2008 Groups and Permissions for an Audit?
I looked at the TFS Permissions Manager mentioned in another answer and couldn't easily figure out how to use this for an audit of user permissions. That said I looked around and found a few other possible tools to help in this process:
Team Foundation Server Administration Tool - This can be used to produce a list of TFS groups, users & permissions on a per project basis. The utility uses a grid control to display the results and this can easily be copied and pasted into Excel, etc.
TFS Project Audit - This tool generates output in an indented text format. It too works on a per project basis however it lists the output grouped by TFS role.
I think both of the options I mention are more recently maintained than the TFS Permission Manager at the time of this writing. Also, keep in mind that for purposes of a security audit I believe that the local & domain administrators groups in Windows Server have the ability to override any of the TFS permissions (at least with TFS 2008).
I'm the guy who wrote TFS Project Audit and I'd like to clarify a few things about my tool. First, it works on a project basis for TFS 2008 or a collection basis for 2010. It can report on a specific collection or all collections on a TFS server. These are enhancements I made in the newest version, released only a few days ago. Also, the output can be restricted to a specific group, Project Administrators, for example, across a project, collection, or the entire server.
I am always soliciting but rarely receiving feedback on this pet project of mine, so please feel free to leave suggestions for future releases! I have plenty of ideas in mind but it would help to know where my time is best spent, because this projectis hardly all I do with my days.
To prove it is really me, I'll give Saul a shout at tfsprojects.codeplex.com. Thanks a lot Saul!
Have you looked at this?
http://blogs.microsoft.co.il/blogs/srlteam/archive/2006/11/27/TFS-Permission-Manager-1.0-is-Finally-out.aspx