I'm currently tasked with setting up a TFS server for a client. The TFS will mainly be accessed by local (on-site) users through the internal network... Easy!
But what about the few remote users we have? Should they connect via VPN or is it better to make the TFS server public and have the users connect over SSL and provide username and password to the TFS?
Do you have any suggestions on how these solutions will perform compared to each other?
VPN is the way to go if you want the optimal TFS experience with TFS 2005 or TFS 2008. While TFS mainly uses web service based protocols that can all go over SSL, there are a few small things that will not work unless you have proper network access. For example:
Viewing the Build Log (unless worked around)
Access Team Build drops
Publishing Test Results
As well as a few other little niggles. Going the VPN route will also mean that your TFS installation will vary less from a standard base TFS installation which gives you some peace of mind that you won't run into any problems when it comes to upgrading to a new version, applying service packs etc. (or at least any problems you run into will have been run into by many before :-) ). Going the SSL route you are treading a less worn path - though obviously plenty of people do run it that way including CodePlex and all the commercial companies that provide a hosted TFS installation.
The downside of VPN is that usually you are granting users to an entire section of your network (unless you are running TFS in it's own mini private network or something). If you go down the SSL route then be sure to properly test the new team projects as this is easy to break and you might not realise until you try and create one either inside or outside the network.
For additional information, see Chapter 17 of the TFS Guide.
I'd start with a few questions: does the client have a VPN? And are the remote consumers on this VPN already? How secure does this need to be?
(In our case, we have lots of outside vendors we don't want on our VPN, so our source control is publicly accessible with SSL)
When I did it, I used a VPN. Was easier to setup, and made sure that no-one could even see the machine with out being authenticated via the VPN - this was obviously way better from a security standpoint, which trumped any performance benefit we would have got from using SSL, if there even was one...
My previous experience with TFS was in an environment where we had a team of developers staffed out at client sites all over the city. In many situations we still accessed our TFS instance instead of something at the client site. We used SSL with public access to TFS. It worked very well for us.
Related
Is there a way for our development team to point Visual Studio at an instance of TFS on another domain?
Pretty green when it comes to Team Foundation Server and not sure if this should go in the overflow that handles IT admin stuff (from my understanding stackoverflow is more code related).
We just got bought by another company and they want us to use their TFS that resides on their domain. We are working on getting to one domain, but in the mean time we still have two separate domains that talk enough to get by.
Just as Daniel said, just make sure there is a trust relationship between the domains.
Generally if you can access the TFS that resides on another domain with you current domain user, then everything should be OK.
More information please see Trusts and Forests Considerations for Team Foundation Server and Grant the Allowed to Authenticate permission on computers in the trusting domain or forest for details.
You can also reference this related thread : TFS Cross-domain authentication without trust
I have figured out that TFS 2010 has the following web service endpoint
http://tfsservername:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx
Are there ones to get a feed of check-ins, work items and other TFS items?
Update: yes! Visual Studio Online introduced a new REST API, and on-premises installations of TFS 2013 have access to this new API.
In versions of TFS prior to TFS 2013:
tl;dr: Not in any way you're going to want to consume.
Team Foundation Server does expose SOAP web services that the clients use to talk to it. However, it's not something that is publicly documented, it's not supported by Microsoft (meaning they can, and will, change version to version) and, quite frankly, it's remarkably unlikely that the effort required will be worth the result.
Although the web services are well designed, some of the web services require a significant amount of client state. This is particularly true of the work item tracking web services. The clients basically contain an entire "rules engine" for processing and verifying changes to any fields. The client must, basically, be able to understand the process template and process all these state changes before submitting an updated work item back to the server. The server will also run the rules and verify that the client made only legal changes.
The rules engine is not exposed publicly. You would have to reverse engineer it.
This also makes some underlying assumptions like your web services stack can successfully speak NTLM2 and Kerberos properly (most can't, outside of the .NET web services stack, although some an support NTLM version 1 to some degree, which will only give you the illusion that you should be authenticating.)
It's therefore strongly suggested that you just use one of Microsoft's APIs for accessing TFS, either the .NET or the Java SDK.
(I actually worked for a third-party company that successfully wrote a Java front-end to TFS by talking to the web services. It was a fair challenge for us -- especially the work item implementation -- and this was the full-time job for several of us. I wouldn't recommend it as a side project.)
Just like Edward mentioned, the TFS web services aren't meant for public consumption.
On the other hand, you might want to give the "OData Service for Team Foundation Server" a try.
It offers a really nice REST-like interface - thus callable simply by issuing HTTP requests, just like you were willing to do with the web services.
To learn more, check this blog post: http://blogs.msdn.com/b/briankel/archive/2011/10/26/odata-service-for-team-foundation-server-2010-v1.aspx
We are four developers in different locations (in a 100 km radius of each other) tryint o collaborate on a software development project.
We would like to install Team Foundation Server 2010 on one of our machines (we are all using Windows 7) and use that as our central source code repository and work items management.
However we cannot seem to be able to configure TFS to accept remove connections (through Visual Studio). Is it possible to use TFS in this manner?
TFS is just a bunch of web services and should be set up for remote access out of the box.
Things you'll probably need to configure.
Make sure that the windows firewall is allowing TFS to accept incoming requests on port 8080 (the TFS install may do this for you)
Configure your router to use "Port Forwarding" so that requests from the internet to port 8080 are routed to the machine with TFS installed.
Your ISP probably allocates IP addresses dynamically so you might need to sign up for a Dynamic DNS service such as NO-IP.com. (check which ones are supported by your router)
Once you've done this then you should be up and running.
I'm sure others will suggest that you ditch TFS and use a DVCS such as GIT or Mercurial, they have a point! You should consider if it's worth the effort of getting TFS to work in this way when another system might be easier to get up and running.
TFS works just fine for this type of scenario and whether you use a DVCS or not you're still going to have to configure access. You don't need to set up proxies. TFS is extremely fast even over a slow connection. The 3 things you need to remember if you're not on the same domain as the TFS are:
Have the TFS administrator set up your TFS rights using a domain account set up for you. If you don't have a domain account set one up and use it. If there's no domain then create a workgroup account or a local TFS server account.
Add your domain (or workgroup or local TFS server) account credentials manually to the Windows credential store or TFS will keep bugging you to login and that's a pain. Make sure you include the domain (or workgroup or local machine name) in the user name in this format: MyDomainOrMachineOrWorkgroup\MyUserName. No backslash at the beginning, no backslash at the end.
You need to either use the IP directly to connect or add an entry to your hosts file (C:\Windows\System32\drivers\etc\hosts). For those that haven't ever gone into this file the "etc" is actually the directory name not just me saying "and so on". The entries there tell you that when you type an address like mytfs.mydomain.com it should go to IP such and such. That's all.
#Nigel We have TFS on a remote server with local proxy at my workplace. Our internet connection is quite slow relative to the number of developers on site. TFS has extremely poor performance in this configuration compared to having the server local. Our solutions can be several hundred MB to download (of which there are a few branches). Checking version history is slow and painful. Retrieving shelvesets is slow and painful. Checking in on VS2010 or VS2008 is slow and painful. Fortunately VS2012 does this asynchronously so checking in is not so bad but you will eventually get a modal dialog when the op is complete.
All in all, I would say a poor experience compared to SVN let alone DVCS.
you can use AnyDesk (version 5.2+) which allow you to set up TCP connection between clients.
I used it for connecting my client PC to a Team Foundation Server (TFS) over the internet. The server and client are behind NAT. I set the local and remote ports to '8080' and I can connect to server from client using this address on client: 'http://localhost:8080/tfs/'
Reference: TCP-Tunneling-AnyDesk
We have 2 subnets (VLAN1 and VLAN2). TFS is installed on server with both network interfaces .
Domain controller is up for all subnets.
VLAN1 is main office with many computers (and users). VLAN2 in highly secured area for developers only.
VLAN1 users use TFS for posting bugs, viewing progress etc. VLAN2 users use it at full.
The problem is - to restrict access to sources from VLAN1 even for developer user accounts.
Denying access to TFS from VLAN1 for developer users - is valid answer too, but i do not know how((
Any ideas??
EDIT - From comment to answer from #Robaticus
The point is to restrict reading sources from outside.
If you block (at the network) port 8080 (the default), users won't have access to TFS through Team Explorer, only through the website at port 8090 (also the default).
Valid users would still be able to view source through the web portal, but would not be able to update it.
EDIT
Based on the requirement to restrict reading of sources from people outside, if you first do what was mentioned above (blocking 8080), you could always secure the directories for the source control under Team System Web Access. This might be a little ugly (giving 401 errors), but it might work.
It looks like the directory that would need to be secured is under the website:
Team System Web Access->UI->Pages->Scc
This would remove source code browsing from the Web UI for everyone, though. In my opinion, that wouldn't be a real problem, as this function likely gets used only rarely.
I don't know squat about TFS, other than as a user who has performed simple check in/outs.
I just installed it locally and would like to do joint development with a friend.
I was having trouble making my TFS web site on port 8080 visible (the whole scoop is here if your interested) and I wonder if it could be related to the fact that TFS is probably using Windows Authentication to identify the user.
Can TFS be set up to use forms authentication?
We probably need to set up a VPN, though that's a learning curve too.
To use TFS, do our machines have to belong to a domain?
We're not admin types, though he is better than me, though I would be interested in any feedback or advice on which path is likely to pan out the best. I already got AxoSoft OneTime working in this type of an environment and it suits us well, but I am tempted at all the bells & whistles with TFS and the ability to tie tracked bug items to code changes.
As far as finding a good way to share code, do sites like SourceForge allow one to keep code secure among members only?
It does not need to be installed in a domain. I'm running TFS at home within a workgroup on a virtual machine.
Create a user on the machine that hosts TFS. Let's assume this machine is named TFS-MACHINE. Grant that user appropriate Team and Project rights.
When connecting to TFS from the remote machine, the user should be prompted for a user ID and password. They should use a User ID of TFS-MACHINE\username and the appropriate password.
Regarding external spots to host code. If you're looking for cheap/free, you can look at something like Unfuddle, which supports SVN and Git.
If you're looking for hosted TFS, the only place I've been able to find thus far is SaaS Made Easy, but they can start getting a bit expensive, depending on the number of users you have.
Keep in mind if you're going to host locally that you'll still need to do things like periodic backups, etc.