When we introduced Team Foundation Server hosting, it was one of our first ventures into offering specialized software as a product and our first step into the software as a service market. As we listened and worked with our user base, we introduced multiple Team Foundation Server Proxy nodes to improve performance and the user experience and we also introduced Team Foundation Server Build as an add-on service for existing accounts.
I’m happy to announce that we’re taking our next step: Offering Team Foundation Server Build as a standalone service.
At this time, the system is not dynamic, resources aren’t being re-allocated on-the-fly and unfortunately, it will not have dinner ready by the time you get home (but we’re working on that).
So, what do we offer?
We provide a managed, stable working environment that allows for the installation of custom packages and software so that the build server will meet your exact requirements. With the service, you now have the ability to:
- Add a build server without the account-related requirement (Yes, it works with Microsoft’s Team Foundation Service!)
- Scale out an existing configuration by adding additional build servers
- Deployment capabilities
- FTP/WebDAV build retrieval
While the service is still in its beta stage, it is fully functional and we’re continually working to make improvements. If you’re interested in giving Build as a Service a try – for free – please contact our sales team at: email@example.com for more information.
Since we launched Team Foundation Server 2012, I’ve been seeing a lot of questions regarding Eclipse and the Team Foundation Server plug-in that range from general configuration to licensing and I thought I’d take some time to get a post up to for clarification. Let me go over the licensing model and then you can continue through the article for the set-up guide.
We formally contacted Microsoft to get clarification on licensing and here’s what we’ve discovered and understood. In a typical in-house environment, in order to use Team Explorer Everywhere, you would need a client access license but in a hosted environment, you need a subscriber access license which is included for every user license that we offer as a services provider. Simply put: Feel free to use Team Explorer Everywhere against our servers without worrying about the licensing.
Now, just to make sure that everything’s covered, I’ll be going over a step-by-step guide on installing and configuring Eclipse on a Windows 7 workstation and for this example, you’ll need to download or install the following:
I’d also recommend reviewing the requirements list at MSDN for the Team Foundation Server Plug-in for Eclipse before proceeding.
Let’s go over all of the steps.
1. If it’s not already available on your system, install the Java runtime.
2. Next, extract Eclipse Classic.
3. Launch Eclipse and then go to: Help > Install New Software…
* Name: TFS Plug-In
* Location: http://dl.microsoft.com/eclipse/tfs
Agile Software Development
- Track project progress with a Kanban board
- Assign tasks to user stories through drag and drop in the taskboard
- Assign ownership through drag and drop in the people view of the taskboard
Team Web Access
- Improved navigation and usability enhancements for Web Access for example: Web Access now remembers the state of the splitters, contains styling improvements, added several animations and contains next/previous work item navigation
- Updated Team Foundation Server Web Access navigation styling
- Show counts for links and attachments in Team Foundation Web Access
- Drag and drop queries and query folders in Web Access
- Expand and Collapse the left navigation pane in web access
- Usability improvements for Version Control
- Version control supports paths longer than 260 characters
If you’re using Visual Studio 2012, I’d suggest applying Visual Studio 2012 Update 1. For more information on the Visual Studio 2012 update, see the blog post at: http://blogs.msdn.com/b/somasegar/archive/2012/11/26/visual-studio-2012-update-1-now-available.aspx.
Note: We have discovered a bug with update 1. When a new Team Project Collection is created, the collection name is visible to all users on a server through various clients (but of course it is not accessible by any other users due to lack of permissions).
We’re working with Microsoft to resolve this as soon as possible.
One of the key highlights of Team Foundation Server 2012 is an improved experience when you’re working offline and you would have to wonder: If it’s mentioned as a key feature, how bad was working offline previously?
If you’ve avoid opening a solution under source control in offline mode, you’re extremely fortunate. But for those that have to experience it with Team Foundation Server 2010, you might hear that it’s easier to call it a day than continue working.
Before going further, it’s important to discuss and understand what’s allowed the improvement: the local workspace. A workspace is a critical feature of Team Foundation Server since it’s what allows the differentiation between the changes that have been made against the data stored on the server and your working copy of files.
Prior to Team Foundation Server 2012, the only type of workspace that was available was a server-side workspace which has drawn plenty of criticism since an active connection to a TFS server was essentially required so that synchronization could occur. While the ability to make changes to files was available, it was an extremely tedious and cumbersome process.
The local workspace was introduced with Team Foundation Server 2012 as the default workspace type and it follows the Edit-Merge-Commit system – any changes that are made are noted and then synchronized with the TFS server at check-in.
There are some advantages and disadvantages between the workspace types so you may want to determine how a workspace will be used against a particular project.
Server workspaces have the following advantages and disadvantages:
- Ideal for a large number of files. According to a post made by Buck Hodges, you may want to consider using a server workspace if there are more than 50,000 files involved.
- Compatible with previous versions of Visual Studio. While users go forward with the transition to Team Foundation Server 2012, it’s highly probable that some users will need to continue using Visual Studio 2010 and if this is a case that might occur in your environment, you may want to continue using server workspaces if a workspace needs to be shared.
- Exclusive locks are observed (provided that the asynchronous check-out feature is not enabled).
- All local copies of files are set to read-only. If a solution is opened offline, you’ll be prompted to overwrite changes every time.
- In offline mode, core abilities such as adding, deleting, renaming or undoing changes to a file are not available.
Local workspaces have the following advantages and disadvantages:
- Local files are not set to read-only and changes can be made.
- All normal functionality is available. For example, you can create a new file and it would be recorded as a pending change.
- If a change is made to a file outside of Visual Studio, it will be detected.
- Exclusive check-out locks are not enforced.
- A high number of files may result in performance degradation.
The default setting for a workspace is set to local but if you need to alter an existing workspace or create a new workspace, you’ll find the option under the “Add Workspaces” window.
To get an idea of what using a server workspace is like in offline mode, let’s take a quick walkthrough.
1. To make sure that there was no connectivity to a server, I used the most effective method of guaranteeing no connection – I unplugged the network cable. After verifying that no network connectivity was available, I opened an available solution in offline mode.
2. In a sample application that I had available, I updated two files, About.vbhtml and Index.vbhtml and then saved my changes. Here’s what you’ll see every time a file is saved.
3. I decided to add a new file.
4. To simulate a restored connection to the server, I just plugged the network cable back in and attempted to go online.
Note: The file that was added is not detected as a change.
5. The new file will need to be manually added to source control and then checked-in.
1. For working offline with a local workspace, I used the same high tech method that I used for the server workspace and opened the solution in offline mode. Here’s what the Solution Explorer window looks like:
2. I opened and updated the Web.config file and then saved. I was not prompted to overwrite an existing file that was set to read-only and the change was noted immediately:
I continued working and just made a simple change to the Index.vbhtml file.
3. I reconnected the cable and went online. All of the changes that I had made were recorded as pending changes.
4. I recreated the disconnected environment, added a new file and then went back online. Unlike the server workspace, the change was detected:
While not everyone may find themselves in a situation where working offline is required, the introduction of the local workspace is a much appreciated and welcomed enhancement.
Deploying Team Foundation Server 2012 in our hosting environment at our North American and European data centers has been successful. All services have been stable and I’m seeing a decent rate of new customers that are early adopters.
I have performed several free migrations for our existing Team Foundation Server 2010 customers to the new environment. Everything has been working well, but a handful of users have been reporting a problem.
While the Team Project Collection and associated Team Projects and data have moved over, using the Configure Features wizard results in an error: “TF51515: The constant ID for InsertConstantSet is missing.”
Scouring the error code produced no useful information and I enlisted the help of the Microsoft Visual Studio Team Foundation Server 2012 team. It had been several weeks since I had first contacted them but I’m happy to have found a workaround.
The information that I had gathered was: In some cases, if a Team Project contains a custom Team Project Group, the Configure Features wizard (feature enablement) that upgrades a previous Process Template to an updated version shipped with Team Foundation Server 2012 that allows the use of new features, it will fail and throw the TF51515 error.
Having performed a serious evaluation, I have discovered that there are certain requirements that must be met in advance:
- You must be a member of the Project Collection Administrators group.
- You must have the updated tools that are compatible with Team Foundation Server 2012 that are available after you install Visual Studio 2012 or Team Explorer for Visual Studio 2012.
- You should make sure that you can run Command Prompt with elevated privileges.
If the requirements are met, the following steps need to be performed:
- Make sure that no team members are actively making changes.
- Create a backup (If you are a TFS 2012 hosting customer, please contact our technical support team and we can create an in-place backup on your behalf).
- Obtain the unmodified Work Item Templates. Download: TFS2012TypeDefinitions.zip.
- Extract the contents of the TFS2012TypeDefinitions.zip file and note the location.
- For good measure, delete the cache directory at: C:\Users\WindowsUser\AppData\Local\Microsoft\Team Foundation.
- Before going any further, just note that you’ll have to repeat the steps below for each Team Project that is failing to upgrade. Just work with the first Team Project that you’re having problems with.
- Access the witadmin command-line tool:
- Visual Studio 2012: Open Developer Command Prompt for VS2012
- Team Explorer (x86): Open a Command Prompt window with elevated privileges and change directories to: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE>
- Team Explorer (x64): Open a Command Prompt window with elevated privileges and change directories to: C:\Program Files\Microsoft Visual Studio 11.0\Common7\IDE>
- Execute the following command to get a full list of Work Item Templates for your Team Project: witadmin listwitd /collection:https://TfsServer.discountasp.net:443/tfs/YourTeamProjectCollection /p:”YourTeamProject”
I would highly recommend saving the list to a separate text document.
- Even though a backup is available, as an extra precaution, create a backup of each existing Work Item Template. To download the Work Item Template, execute the following command for each Work Item Template: witadmin exportwitd /collection:https://TfsServer.discountasp.net:443/tfs/YourTeamProjectCollection /p:”YourTeamProject” /n:”WorkItemTemplate” /f:”C:\path\WorkItemTemplate.xml.bak”
- Execute the following commands:
- Task Work Item Template: witadmin importwitd /collection:https://TfsServer.discountasp.net/tfs/YourTeamProjectCollection /p:”YourTeamProject” /f:”ExtractedZipFilePath\ProcessTemplate\task.xml”
- Code Review Request: witadmin importwitd /collection:https://TfsServer.discountasp.net/tfs/YourTeamProjectCollection /p:”YourTeamProject” /f:”ExtractedZipFilePath\ProcessTemplate\CodeReviewRequest.xml”
- Code Review Response: witadmin importwitd /collection:https://TfsServer.discountasp.net/tfs/YourTeamProjectCollection /p:”YourTeamProject” /f:”ExtractedZipFilePath\ProcessTemplate\CodeReviewResponse.xml”
- Feedback Request: witadmin importwitd /collection:https://TfsServer.discountasp.net/tfs/YourTeamProjectCollection /p:”YourTeamProject” /f:”ExtractedZipFilePath\ProcessTemplate\FeedbackRequest.xml”
- Feedback Response: witadmin importwitd /collection:https://TfsServer.discountasp.net/tfs/YourTeamProjectCollection /p:”YourTeamProject” /f:”ExtractedZipFilePath\ProcessTemplate\FeedbackResponse.xml”
- Use Internet Explorer to access the Team Project Collection Overview page at: https://TfsServer.discountasp.net:443/tfs/YourTeamProjectCollection/_admin, select the Team Project and then click Configure Features.
- Go through the steps in the wizard and your older Process Template should update.
I have been informed that the problem is a bug and Microsoft will issue a formal fix in the first quarter of 2013.
Thanks to Bogdan Spaiuc and Aaron Hallberg over at Microsoft for giving us a hand with this issue.
When we launched our hosted Team Foundation Server 2010 Build service, an active outbound Internet connection was not available. But after receiving many requests, we made plans to perform an infrastructure-related update that would accommodate the needs of our customers. We have been working tirelessly behind the scenes and I’m happy to announce that the project has been completed – you can now connect to an outside system!
As a showcase, I thought I’d do a small write up on deploying directly from one of our TFS Build servers to a server in our web hosting environment so let’s go over the steps that you’ll need to perform.
1. Use the Team Foundation Server Hosting Support Portal and open a request with the technical support team to get Web Deploy 2.0 installed on your TFS Build server.
2. After we’ve completed the installation, access the IIS Tools utility in your DiscountASP.NET Control Panel (web hosting) and make sure that the version of the .NET Framework is selected.
3. You can use an existing Team Project but for this article, we’ll use a C# Web Application.
4. After you’ve created the Web Application Project, connect to your Team Foundation Server 2010 server. If you’re a new user, follow the steps available in the DiscountASP.NET TFS Knowledge Base for configuration instructions.
5. Create a new Team Project. In the event that you need a reference, use the steps in our Create a new Team Project using Visual Studio 2010 article.
6. Add the Visual Studio project that you’ve created to source control. For help with this particular step, you can start from step number five in our Getting Started with Team Foundation Server guide.
7. You can modify an existing Build Definition or you can use the steps in the How to create a Build Definition article to create a new Build Definition and when you reach the Process step, click on Advanced and locate MSBuild Arguments.
8. In order to proceed, you’ll need your web server information which can be found on the Account Information page. You’ll need to prepare the following line and then add it to the MSBuild Arguments:
/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:DeployIisAppPath=”HostedDomainName/myapp” /p:MsDeployServiceUrl=WebServerName.discountasp.net:8172/MsDeploy.axd /p:username=AccountUserName /p:password=AccountPassword /p:AllowUntrustedCertificate=True
9. Add the information to the TFS Build Definition, save the changes and then execute a build.
10. Once the build has completed, access the deployed application.
While the example that was provided targeted a hosted site specifically, you are not limited to just the DiscountASP.NET servers, you can deploy to any system that’s been configured to receive connections.
If there are any technical questions you might have, feel free to contact the support team.
While SQL Source Control and SQL Connect offer the same underlying ability – adding a database to source control – the key difference is that SQL Source Control works in tandem with SQL Server Management Studio whereas SQL Connect allows the ability to work on your database directly from Visual Studio.
The ability to continue working on different aspects of an application without switching environments is a blessing – think of the amount of time that’s lost and the disruptions that you usually go through tabbing through open windows or using preview windows. Some key benefits are:
- I’m mentioning it again because it really is critical: the ability to work on application-related and database-related projects in a single development environment.
- Ability to create and execute queries and stored procedures from Visual Studio.
- If some team members are already using SQL Source Control, SQL Connect can use the same repository.
The setup process is straightforward and simple so let’s go through a new installation.
1. If you don’t have a TFS hosting account, use the sign-up form and take advantage of the 30-day free trial that we offer.
2. Make sure that you have configured your client and I’d recommend creating a new Team Project using the instructions available in our knowledge base if you’re evaluating SQL Connect.
3. Before proceeding any further, take a look at the software requirements for SQL Connect.
4. If you have Visual Studio open, save any work and then close all instances that you have open.
5. Download the 28-day trial version of SQL Connect and then run the installer. Make sure that SQL Connect is selected and you can un-check SQL Prompt.
6. After the installation completes, open Visual Studio and you’ll see the SQL Connect window.
If you close this window, you can re-open it by going to: View > SQL Connect.It’s not something that I’ll be covering but note that you can import from an existing SQL Source Control project at this point as well.
7. Click Create New SQL Connection Project or if you closed the window, you can create a new project and then click the SQL Connect template.
11. Select the Team Project and then specify a location.
12. As an example, I’ll modify an existing table.
13. Now, all that’s left is to synchronize the change.
SQL Connect allows for much required convenience – something that I always welcome – and it’s definitely worth checking out if you’re not already using SQL Source Control.
At the time of this writing, Red Gate is offering DiscountASP.NET users a 20% discount on SQL Connect! Check the Control Panel Marketplace for details.
After launching our Team Foundation Server 2010 Proxy beta service, I was very curious to see what type of real world results would be returned. My expectations were pretty high. During the deployment process, I was just using a generic ASP.NET 4.0 Web Application Project and the improved download speed was very impressive but how about a real project?
To get an idea of what type of actual performance to expect, there isn’t any isolation involved and I’ll be using actual production servers. I’ll be using our shared TFS server hosted at our European data center and using the TFS Proxy server at our North American data center.
Instead of trying to determine connection-related efficiency from different types of Internet connections and speeds, I elected to use the office connection during normal business hours where other staff members would be utilizing the connection. I did try a few of the tests on a residential DSL connection. I will not be including the results but I’ll mention my findings in the conclusion.
There wasn’t an easy way to get start and completion times through Visual Studio – I used the tf command-line utility in a batch file. The results do not take into consideration any overhead that an IDE might require. The tests were run back-to-back so a test without proxy was immediately followed up by a request with TFS Proxy involved.
I’m also looking at two of the most frequently used commands that benefit from TFS Proxy: get and diff. Each test was run five times, a new Workspace was created for each trial and only the local client cache was cleared.
The result times were rounded up to the nearest second, as the main purpose is to try and get an idea of real world wait times.
Team Project Collection:
- Team Projects: 2
- Size: 44.1 MB
- Folder count: 504
- File count: 3,983
Team Foundation Server 2010 server:
- Server: ETFS01 (shared production server)
- Location: London
- Operating system: Windows Server 2008 R2 Standard (x64)
- CPU: Intel Xeon E5520
- Memory: 4GB
- Hard drive: Microsoft Virtual HD
- Connection type: Tier 1 data provider
- Average latency: 150-200 ms
Team Foundation Server 2010 Proxy server:
- Server: USW-PROXY01 (shared production server)
- Location: Irvine, CA
- Operating system: Windows Server 2008 R2 Standard (x64)
- CPU: Intel Xeon E5620
- Memory: 4GB
- Hard drive: Microsoft Virtual HD
- Connection: Tier 1 data provider
- Average latency: 7-9 ms
Team Foundation Server 2010 client (my trusty laptop!):
- Location: Pasadena, CA
- Operating system: Windows 7 Professional (x64)
- CPU: Intel Core i5-430M
- Memory: 8GB
- Hard drive: Seagate Momentus XT ST750LX003
- Connection: Business-class 10mb
- Get (with and without Proxy):
- Full recursive
- Single binary file (approximately 1MB)
- Single text file (approximately 66KB)
- Diff (with and without Proxy):
- Single file (approximately 494KB)
Get (Full Recursive)
While it’s not something that you might end up doing frequently, I thought it would be fun just to see how much of a difference TFS Proxy makes on a full recursive get.
The recursive get of the Team Project results in downloading files from 30 seconds to a full minute faster! Again, it’s not something that would be done frequently but it’s a good way to show how much of an improvement Proxy provides.
There might be some binary files that you might end up pulling from a server. Much like the previous test, this isn’t something that you might end up doing occasionally.
TFS Proxy wound up being as much as 2.5 times faster than no proxy. I wasn’t able to try a larger file, but the benefits of using Proxy are evident.
For a more practical test, I tried performing a get on a single file.
On a couple of the trials there wasn’t much of a difference since text data downloads relatively quickly. If you’re pulling a large group of files, you’d definitely see improved performance.
File comparing is a command that’s also issued frequently against a server.
Much like the get performed on an ASCII file, text-based data seems to only have a minimal benefit but I suspect that under low bandwidth high latency conditions, the difference in speed would be more noticeable.
After spending a lot more time working with TFS Proxy, the difference between an operation completing may seem minimal but over the course of time, the amount of time saved for a download is incredible. I’m very impressed by the performance.
The results I came across led me to believe that the ideal time to use Proxy would be in low bandwidth high latency environment so I tried performing a few of the tests from home over a residential DSL connection. After purposely reducing the transfer speed by saturating the connection with some downloads and video streams, a get against a text file was reduced from 8-9 seconds down to a very good 4-5 seconds.
I thought I’d include the statistics on the Proxy server here as well and here are the details:
- Cache size: 38MB
- Files in cache: 4,060
- Number of requests: 28,167
- Number of cache hits: 24,107
- Number of cache misses: 4,060
- Cache hits percentage: 85.59%
- Cache miss percentage: 14.41%
Proxy was used almost 86% of the entire time.
If you’ve established an account and your TFS server isn’t in your region, I’d definitely recommend enabling the Proxy service if there’s a Proxy server near you.