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/)
Related
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.
We're doing an application which takes feeds and items in that feed to entities on our own site. This is supposed to be an open site which anybody can sign up to. All of this is done with MVC + knockoutjs. We are thinking about managing the entities from that site using Sharepoint 2013, essentially replacing our SQL tables of those entities, and putting them into lists on in our Sharepoint instance. We're also thinking of doing the same thing for users and passwords and such. Then we might have a setup for a single sign on for any other sites my company makes. Currently we're using NHibernate and SQL server.
Are we are naive to think that Sharepoint could handle the amount of traffic, with outside users using our site, along with customers. I've heard that it's doable, I'm just wondering if it's a smart thing to do, and if there are hickups, limitations that any of you have run into trying to do this.
We went pretty far down the Sharepoint-as-a-development-platform path and ultimately ended up scrapping what we had done and rewriting it in other technologies. That doesn't necessarily mean it is not the right choice for your situation, but there a few things to consider:
"Why do it this way?". What are the benefits to adding the Sharepoint layer to your technology stack? If not Sharepoint, what do the alternatives look like?
Do you already have a solid Sharepoint admin team in place? Sharepoint definately requires a dedicated admin or team of admins that really understand the product to keep it performant and to help you troubleshoot when things are not working correctly.
Do you have Sharepoint development talent already in house? Good Sharepoint developers are harder to find and are typically more expensive than your regular .NET developer. Also, some existing .NET developers may not be interested in learning Sharepoint.
What is your expected traffic, and can Sharepoint handle it out of the box? At least in previous versions of Sharepoint there were internal limits on the amounts of data that could be stored in each list. On top of that, there were practical limits before the performance of the app becomes totally unacceptable. Understanding what those limits are should be a part of your initial due diligence so you can plan for those eventualities.
Will you be extracting operational data for external reporting or warehousing purposes? Is your data team already familiar with getting data out of Sharepoint?
Ultimately, the reason we failed was we ran down the path after the promise of "easy" development without really committing to the product. When we started running into problems, we struggled with basics like troubleshooting because we had lost a couple key people and our regular devs and admins struggled to figure out what was going on. If we had had the right people in place, our experience might have been different. We didn't, however, and we eventually chose to move away from Sharepoint and rebuild on our standard MVC/SQL platform.
SharePoint has come a long way in a short time to allow external applications to interact with it in the way you describe. I wouldn't try it with anything but SharePoint 2013 mostly because the licensing allows for this without additional cost per user and partly because what I mention next isn't available in 2010 or earlier.
You can use a MVC/knockout frontend but, the MVC app for SharePoint template isn't exactly what you want unless you will provision every user as a SharePoint user account. That template is still an SP app which means it's run by an SP user. I would look at SharePoint as just an OData service that your app writes back to. You can either use the client object model (SCOM) and write back directly (each user exists as a SharePoint user), or you can proxy the data access from your MVC controller and use a 'service' SP user to connect to SharePoint using SCOM. SCOM is just REST and OData so you can use any web-capable language you choose. I know there are examples for C# and JavaScript (node.js). There may be others.
If you are expecting a lot of volume, I would suggest you host this application on SharePoint Online (Office 365), if possible, and configure it to federate with the rest of your environment. That way you only need to add more space as your data grows (rather than more and more servers as load grows).
Here's a nice overview of the APIs available to you:
http://msdn.microsoft.com/en-us/library/office/jj164060.aspx
SharePoint 2013 Developer Center:
http://msdn.microsoft.com/en-us/library/office/jj162979.aspx
5 minute video on SharePoint 2013 SCOM:
http://www.microsoft.com/office/preview?videoid=1e859ac8-58ca-46d0-a8e0-00f4189761a8&from=sharepermalink-link
Timely blog on anonymous access to SCOM:
http://blogs.msdn.com/b/kaevans/archive/2013/10/24/what-every-developer-needs-to-know-about-sharepoint-apps-csom-and-anonymous-publishing-sites.aspx
There is no point to redesign you application only for replacing your database tables with sharepoint lists. Performance is one issue. Sharepoint list limitation is another issue, you will lose flexibility from relational database design and give your life to a black box design called sharepoint list.
I am in the process of developing several data entry forms that the client has asked to be accessible through the SharePoint interface (2007 WSS version).
The forms will, among other requirements, consist of multiple drop downs that have to be loaded from tables in SQL Server. These lists of data are updated frequently through a process that sucks data in from Great Plains.
My inclination is to create a Web Part Page with a Page Viewer Web Part and go full screen like this: http://blogs.msdn.com/b/malag/archive/2008/09/15/story-of-a-mischievous-page-viewer-web-part.aspx
...and then to do the pages in ASP.NET MVC3. Is there a better story than this? The integrated SP development paradigm seems like waaaay more overhead.
This sounds like a common issue with developers new the SharePoint paradigm, especially for 2007. The short answer is that your solution will be the quickest way to get to where you want to go but isn't the "cleanest".
The other option is to create a SharePoint Solution and publish an application page to the _layouts directory. A quintessential "hello world" example can be found at http://msdn.microsoft.com/en-us/library/bb418732(office.12).aspx.
New SP developers will find the hardest transition with deployment. The WSPBuilder codeplex project http://wspbuilder.codeplex.com/ has become the industries default solution for doing this. An example of using this can be found at http://www.greggalipeau.com/category/sharepoint/wspbuilder/.
For you I would say the key words are Application Pages and WSPBuilder.
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.
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.