Assumptions and Preparations: This article assumes you have Visual Studio installed. VS 2012 is used for all screenshots and written instructions, but you can also use Visual Studio 2010 with SP1 and KB 2662296, or even Visual Studio 2008 with SP1 and the applicable General Distribution Release (GDR) update.
I won’t bother arguing here that source control is important for everyone who works with code. There are plenty of articles all over the web written to convince us of this fact. But which source control mechanism should we use? This question is also well covered in the blogosphere, and often seems to be largely about the choice between SVN and Git, but I have my own agenda.
And my agenda is simple: Rather than trying to determine which system is best (likely an impossibility due to the different features of the various options, and the divergent needs of their users), my concern arises largely from a simple practical question: What do potential employers use?
The answer, thus far,has been Team Foundation System (TFS). For the most part. And prior to TFS, it was VSS and a series of various internal or highly customized specialty options. Now, admittedly, the reason for my rather Microsoft-centric experiences is the fact that most of my working adventures to date have been in the Microsoft world. As I diversify those experiences, I am indeed starting to use other systems. But since I don’t plan on leaving the Microsoft world altogether, TFS will likely remain a part of my working life for the foreseeable future.
Yes, it’s certainly true that Microsoft code can be managed and versioned in other systems. It is also true, however, that many shops can easily justify using TFS given their heavy investment in Microsoft tools for the rest of their work. So they do.
But the decision to continue to work with TFS (at least for Microsoft tech) is not the end of the question about which source control mechanism to use on my own projects. TFS hosting tends to be expensive, and maintaining a TFS server at home really doesn’t appeal to me any longer (and for a growing list of reasons). Well, now I (and maybe you) have a new answer: Team Foundation Service from Microsoft – TFS, in the cloud, and free! For now.
Using this new service is fairly straight forward, and the integration with Visual Studio is exactly as we would expect it to be. The service provides useful online help, but some documents are a little light on screenshots and instructions, so here’s an alternative run through the common first steps:
- We start by signing up for the service.
- When we log in, we see something like the following image (as we add projects to the TFS account, they will be listed here, directly below “RECENT PROJECTS AND TEAMS”):
- Click the New Team Project button, then complete the simple form:
- Note that Project name cannot be changed after project creation. Microsoft doesn’t provide any guidance (here) in selecting project names, but all the usual advice we might expect in a system like this, does indeed apply: Use brief and clear names that are unlikely to change, are just as descriptive as needed, but too much so, avoid special or non-English characters which cannot be read on systems used by teammates, and so on.
- Description should be fairly self explanatory, and it can be modified later.
- Process template can be set to one of several options, which update as Microsoft updates the process templates bundled with TFS. At the time of this writing, the three options are: (1) Microsoft Visual Studio Scrum 2.1, (2) MSF for Agile Software Development 6.1, and (3) MSF for CMMI Process Improvement 6.1. I normally select the first option because I find it a little lighter with respect to administrative overhead. I’ve also found that many of the “work items” bundled with MSF process templates are less familiar to some of those to whom I turn for support while working on a project (unless they have experience on the Microsoft campus or at one of the larger Microsoft shops elsewhere in industry).
- Click Create Project.
- The service creates our project, which normally takes less than a minute. Or so. When done, the service informs us it’s ready:
- Click Navigate to Project.
- The new project opens to the project overview page, which appears approximately as follows (though other process templates may result in different layouts):
This is a good time to switch gears slightly. In upcoming steps, we’ll be connecting our new online Team Foundation Service repository to our desktop Visual Studio application, but let’s pause for a moment first.Whenever Microsoft want to communicate with us regarding changing conditions or other service issues, their message is likely to be broadcast to us via an informational ribbon directly below the header links (see overview page pictured directly above). If you are going through these steps anywhere near the time of the publication of this article, this info ribbon is likely advising you that your account can have 5 users for free, and that all use of the system is also free. For a limited time. Follow the link to learn more, and maybe do some additional research.The day will come when some parts of this service, maybe most, will no longer be free. I always feel the need to remind users about such things when applicable, because I know how easy it is to get swept up in the excitement of a new toy, and especially if that toy offers such strong benefits. The bottom line? We should all be careful how much we come to depend upon a free service that is not expected to remain free for long. This goes double for any service that is not completely clear about which features will remain free after premium features come online.Now, back to our regularly scheduled program.
- On the TFS Team Project overview page (as pictured above), click Open new instance of Visual Studio. In the above image, this is the last link under the “ACTIVITIES” heading in the right sidebar.
- If your browser asks you for permission to open the link, and/or which application to use, allow it to continue (and be sure it does so with Visual Studio).
- If the wrong version of Visual Studio starts, you may have to reconfigure your system so that this link opens in your preferred version, or uninstall the version you don’t want. A common occurrence of this problem involves Microsoft Visual Studio Express 2012 for Web. As this version may be installed along with other products, it may haunt you here until you deal with it. My preferred solution is to uninstall Express 2012 for Web (and any other offending version present). But beware: Uninstall of any Visual Studio software may temporarily break your browser’s ability to correctly handle the link. If the link becomes unresponsive, the easiest solution may be to run a “Repair” install (Control Panel > Programs > Uninstall or Change a Program > Microsoft Visual Studio [Version] > Change > Repair).
- Visual Studio 2012 opens with the following TFS Sign In window (this step may appear differently with different versions of Visual Studio). The sign in window appears in modal focus (so we must sign in or hit escape to get to the main Visual Studio interface):
- After we sign in, the Team Explorer window appears in the Visual Studio interface, as in the following image (and typically docked on the right side of the interface), and we can now interact with our new TFS Team Project.
If you’re already comfortable with TFS (and it’s integration with Visual Studio), you can probably stop here. Pick it up again and explore this particular implementation of Team Foundation System according to your favorite practice. But if any of this is really new to you, your next step should probably be to add code to your new project, so you can end this introductory experience with a complete and work ready deliverable.
- We begin the final phase of this process by establishing a workspace on disk in which source controlled materials will be stored. Since, in this case, we are working with Visual Studio, we might be tempted to use the existing default Visual Studio document storage location for this purpose (something like C:\Users\MyUserName\Documents\Visual Studio 2012). However, an alternate location is preferred for three reasons:
- Conflicts may rise between tools working with source controlled materials and those working with strictly local materials, if samples of each coexist too closely on disk. For safety, we should never save via source control AND via local tools to the same location.
- Default paths used by many tools (including Visual Studio) can include spaces. While spaces in paths are far less likely to be a problem with modern tools than they once were, there remain a surprising number of cases where spaces in paths cause issues. This risk seems higher when we rely on a large sets of tools hitting the same materials, and/or when we must rely on quickly built mission critical patches and helper apps. Both of these circumstances are certainly likely to occur in software engineering projects, and if you haven’t been hit by them yet, you probably will soon enough. For safety, we should avoid paths that do or may include spaces.
- Maximum allowed lengths for file and path names should be considered when building ANY software, even if that software will not be run on an end user machine (like a web site). This, of course, is because file and path name rules (including total lengths) apply to the materials we use as we build our projects. Windows limits us to 256 characters when establishing the full name and path of an addressable object on disk. This limit accounts for the path, the filename, and the filename extension, but does not include the disk/volume name (for which three more characters are allowed). The full address of the location we use for storing our source controlled materials counts toward the length limit of the individual files within that very directory. In some cases, such as those in which file names and/or paths are dictated by external dependencies rather than by us, the lack of play space in our total filename plus pathname allotment can result in technical issues that are hard to overcome. Quite obviously, it is to our advantage to leave as much filename and path length to our working materials as possible. For safety, we should avoid paths that are any longer than necessary.
- Given these factors, we should consider a directory like C:\TFS as a workplace for our source controlled materials. I’ve even seen directories like C:\A and C:\B used. These extra careful directory names seem a little extra crazy, perhaps, but they also afford the user a natural way to create multiple source control directories without adding sequencing or differentiating characters. If you like this approach, beware: Try to avoid directory names like C:\0 and C:\1. These, apparently, can cause various hardships with some tools.
- Remember the Project name used near the beginning of this process? If that was a real project, it probably already has files on disk (likely somewhere near C:\Users\MyUserName\Documents\Visual Studio 2012). If it doesn’t have any files yet, or if you used a fictitious project name, take a moment to create a project now, or add files to your empty project. Now, we must move our project materials from the location currently used by Visual Studio, to our newly created source control workspace:
- Open the project from its new source control storage location (FILE > Open > Project/Solution… or FILE > Open > Web Site…).
- Right click the solution name in Solution Explorer and select Add Solution to Source Control…
- In the dialog that results (as pictured below), we can make various minor changes to the folder structure of our project on the source control server. For me, the default settings usually work best:
- Click OK.
- Right click the solution name in Solution Explorer and select Check In…
- The Team Explorer panel opens in Pending Changes mode (typically docked on the right side of the Visual Studio interface). Review the changes we are about to make: See Included Changes and Excluded Changes.
- Add a meaningful but brief comment to the Comment field.
- Click Check In.
- By default, we are prompted with a small Check-in Confirmation dialog. Whether each of us chooses to continue to see these dialogs is individual choice, but I’ll share that I rarely use the Don’t prompt again option. This sort of dialog has saved me from a wide variety of late night disasters…
- The check-in process may be lengthy, if this first check-in is extensive. When done, the solution should be safely stored in TFS, the Team Explorer interface should inform us of it’s success, and it should report a changeset number.
- Click the Home icon near the top of the Team Explorer panel.
- Click the Source Control Explorer link.
- The Source Control Explorer, which typically opens docked in the main area of the Visual Studio interface, allows us to verify our check-ins. In the following image, note the remote address at the top of the left pane, and the local path at the top of the right pane.
And that’s it! For now…
And now we have a new Team Foundation Service account, with a new Team Project, and newly uploaded code with which to do… Well, whatever we need… And we can do whatever we need, whether as individual devs or dev teams of virtually any size, with the productivity, safety, and best practices advantages offered by a top shelf source control system!
There are, of course, many next steps possible here: Checking files in and out, requesting and providing code reviews, working with unit tests, managing builds, sharing code with teammates, and more. The online documentation is decent enough, though not always complete, so expect to spend some time at your favorite online haunts if you’re not already comfortable with TFS. And if growing TFS skills is part of your agenda in considering this service, this is certainly a good time for it. For now (January 2013), the service is still free. For now.