In our work place we use Team foundation server as the main server used for source control, work tracking, build server etc.
We develop in house software with many teams working on different projects.
Sometimes we develop applications or libraries which can and should be shared in our company including the ability to have more than one team contributing. Unfortunately due to nature of the applications being developed they cannot be shared outside our company.
I would like to know if tfs can help in that respect or do I need to add other tools.
For instance if our teams work in different areas or team projects how can open source projects be shared without risking editing permissions or such. How can projects be shared, cataloged, published?
How can issues be published for the project? How can pull request be done as they are done in github?
Share projects or source code in TFS is accomplished mostly through a combination of using the Area hierarchy and Teams functionality.
Then we can use the Area field to filter all reports and queries. Each Team is tied to the related Area and is used to provide each Team/Sub-Project with it’s own Product Backlog. And Security can be granted based on Area and/or Source Control Path.
Update
Permission is a very important concept in TFS. The simplest and safe way is using permission to restrict and help other team contributing to the share projects. One main team/group which have all permissions for the contributing to the share project.
Most of the teams/groups which have visibility into the share projects. They need to create pull requests to review and merge code in project. Pull requests let your team give feedback on changes in feature branches before merging the code into the master branch. Reviewers can step through the proposed changes, leave comments, and vote to approve or reject the code. The same thing as GitHub.
And many times a request or issue fix will come from the share project managers , but they are not sure what team or project it should be assigned to. Then you could use share product backlog items (pbi, or user story if you are using agile template) across team projects within TFS. Since you are using a multiple team strategy under a single team project. You could collect the pbi’s and place them in an oversight queue that will be reviewed by either an individual or committee. Then these pbi’s will get moved as they get assigned to teams and projects. However, you also need to setup security in way so that the individual teams don’t have permissions to get in and monkey around with other teams backlog, queries, or code.
Otherwise, there are no built-in share project process or tool inside TFS, if you really need this, could add a uservoice.
Related
Is it possible in TFS 2013 to put a particular user in the Readers group for the team project but allow them to have Contributor permissions for a certain folder? It would look something like this:
$/Main - Read
$/Main/User - Read/Write
Or is it best to just give the user Contributor access for the whole team project?
Yes, you can set permission on TFVC up to a single file; for Git version control in TFS, you can control access to a repository or at most to a branch.
That said, it is correct to ask yourself if it is worthwhile, as every time you break inheritance on security you face more administrative work in the future. The leaner and simpler the configuration, the less work for the administrator.
Some scenarios where this make sense are:
a big project space with multiple teams (read carefully: not a big project, but a single TFS Project spanning many loosely related sub-projects)
a hosting configuration, which means just the same as above
protecting some special files, so they are accessible to special accounts, like certificates, private keys, etc.
We have a very standard / simple instance of TFS installed in our development environment.
I can see how to provide web access to a manager for a single project, e.g /tfs/fooProject, but I would really like to setup a worklist or add titles / homepage to the entire TFS instance.
This would be helpful as we host multiple projects, each with a couple of outstanding issues, and I would like it if a manger could go to a website and see a snapshot of all our applications on the one page.
Any ideas on how I could do this?
Check out this blog post: http://blog.nwcadence.com/working-within-a-single-team-project-with-team-foundation-server-2012/
The basic idea is that you model levels of your organization using area paths. This will allow you to scope your Web Access view to the appropriate level.
Note that this is made considerable simpler in VS 2013 with the introduction of the Agile Portfolio Management Tools (http://blog.nwcadence.com/video-new-with-visual-studio-2013-manage-project-portfolios-to-understand-the-scope-of-work/)
Consider a new deployment of Team Foundation Server 2010, with the first use cases being Version Control.
The teams using TFS for Version Control are:
application development - web applications, SharePoint, db scripts, etc. primarily through Visual Studio
integration - text files (XML and JavaScript) for an integration engine.
data warehouse - VS database projects, SSIS packages
Each team typically doesn't have projects relating to each other, and work independently. All projects are internal, and each team has a different set of customers.
The first suggestion is to have a Collection layout as such:
* Applications
* Sharepoint
* Integration
* DataWarehouse
How would you structure a TFS 2010 given these conditions?
Are there any practices or suggestions that would you recommend for these teams in terms of collection structure?
(source: msdn.com)
I'll answer my own question here with how I laid it out in this environment with many distinct teams.
For any other developers taking on the TFS admin role, I'd again throw out the suggestion to divide your TFS Collections where the projects won't have any cross-over between teams. This could be however you define it - customers, separate teams.
This helps to allow teams to see & contribute to projects that they're concerned with.
Create new or leverage existing AD security groups for the purpose of granting read/write to each appropriate Group in the Collection. Allow/deny permissions to each Group for the Collections as they're needed.
Steve Lange has a very good posting about this topic ("Thoughts on TFS Project Collections"), click here
Can collections have collections? If so, I'd suggest a team bases collection. Then each team can have their own child structure as they see fit. It also gives you a nice seperation between teams, giving you flexability in security, stability, etc.
Team Foundation Server 2008 allows that every check-in is associated with a work item, but what do you do if you are developing some features which span several Team Projects?
For example, you're developing a specific product for a client and that product has its own Team Project, but is also using some of your other components or tools which are maintained independently in another Team Project.
Where do you create work items for requirements which involve a change in both projects?
Separated, every work item in its own Team Projects
All work items in clients Team Project, regardless of associated source code
The latter seems easier to maintain and control, but it involves associating check-ins from one Team Project to work items in another.
For a start I would say that having each check-in associated with a work item is good practice and more important that where exactly that work item lives.
From the TFS point of view it is really irrelevant whether the work item is in the same project or another - where it makes a real difference is the reporting side.
Therefore one way of looking at this is to look at reporting. For instance
if all work on the project and on the components/tools is charged to the project then it would make sense to create all work items within the project.
if changes to the components are funded separately - it would make more sense to create separate work items withing individual projects
Another way of looking at it is for historical reasons - if you want to be able to go back and see what was changed in a particular tool/component it is easier to see the work items also within the project.
Probably there is a way to sensibly split the work items and create the work items for the components in the component project and work items for the projects (if they relate to using the component) in the main project. You could always link the two work items together.
We would like to give our customers access to report bugs and to look at existing bugs and work items, through Team Foundation Server.
For that, we will need a web frontend, which is customer-friendly. It should be easy to use and with a nice UI. I am aware of Web Access, but think it is too developer-oriented for our customers to use.
Is there any good open source or commercial products out there for doing this? It is important that we will be able to customize the products for our needs.
There is WIWA, but it's quite similar to the regular web access tool. It exists more as a licensing aid (helping TFS admins ensure they don't overstep the CAL requirements) than as a fresh new UI aimed at non-developers.
Note: get it from the latest download package for TSWA SP1, not the CTP linked in the blog post
I don't know of any other solutions that are as customizable as you're hoping. I've seen (and contributed to) one-off solutions that were tailored for a specific work item type. At the broadest level, you could say that the bug pages # connect.microsoft.com and # Codeplex fall into that category as well. But none of them is publicly available, nor would they be helpful even if published.
You'll probably need to do a one-off of your own using the Work Item Tracking API. Luckily, this is far easier than writing a generalized workflow engine / forms designer that knows how to parse WIT XML.
A bit of a shameless plug as I'm the project owner: Spruce is an ASP.NET MVC2/jQuery driven front end for TFS 2010 aimed at replicating the user-friendly approach you find in products such as Fogbugz, Unfuddle and online sites such as Github, Bitbucket.
A few screenshots:
I'll be adding the list of features found on the blog at the start of the year.