Version Control

Version Control

Any development project that involves more than just creating some simple demo code has a critical need for some sort of version control. In the Microsoft world, this has generally meant using Microsoft Visual SourceSafe® (VSS). Although VSS was a very useful tool, many enterprise customers chose to use a third-party version-control system instead. Many of these tools allowed developers to use more advanced features than were available in VSS.

With the introduction of Microsoft Visual Studio 2005 Team Foundation Server and Team System, Microsoft has provided an advanced, full-featured, enterprise version-control system that is able to handle the most complex development tasks. It handles tasks such as code branching and merging with far more reliability than VSS did. It also includes new features such as code shelving, which allows developers to place their unfinished code in the repository without actually checking it in. It also provides different types of locks when checking out files from version control. You can decide to not lock the code at all, allow others to check out code but not check in code, or lock other developers from even checking out the code at all. (See Figure 6-6.)

Figure 6-6 Checking out code

One of the major features of Team Foundation Server and Team System is that it allows the creation of version-control check-in policies. These policies can warn developers if they are trying to check in code that violates some stated policy. These policies can be defined by an administrator and include rules such as the following:

• The source code must have been reviewed by a senior developer.

• Unit tests must have covered more than 80 percent of the code.

• There are no violations of the corporate naming convention guidelines.

Associating Check-Ins with Work Items

When you check in code, it can be associated with a work item. This allows developers to track their work as it relates to their assigned tasks. When code is related to a check-in, it's also reported to the Team Foundation Server. This system allows reports to be generated that track code churn, bugs, and the progress made toward project completion.

You can even define a check-in policy to ensure that every piece of code added to the version-control system is tied to a particular work item. This best practice ensures that project managers, architects, and other stakeholders can use the built-in reports to understand the progress being made in the various areas of the project.

To associate a check-in with a work item, you simply begin the check-in process. First, you need to select the files you want to check in. (See Figure 6-7.) You then associate the check-in with a work item by clicking the Work Items icon on the left-hand side of the wizard. You can then search for the appropriate work item to associate with the check-in. Once you select the appropriate work item, you can ensure that the Checkin Action is set to Associate. (If the code you wrote resolves the work item, you can instead select Resolve.)

Figure 6-7 Checking in code

Associating a check-in with a work item allows the progress of the project to be tracked more closely, and it allows other developers to easily find code relating to certain features of the system. (See Figure 6-8.) This is especially true if you relate the code to a Quality of Service (QoS) Requirement or a Scenario work item.

Figure 6-8 Associating a check-in with a work item or multiple work items

You might also choose to associate more than one work item with a particular check-in. In fact, in many situations you will be associating a piece of code or an architectural diagram with as many as three or four different work items, possibly more. For instance, your code may solve a particular bug that has been reported, so it clearly needs to be associated with that work item. In addition, it is likely that the code was related to a particular feature of the application, or possibly a QoS Requirement so it will also be associated with that work item. Finally, you may have responded to the bug by a task created automatically by Team Foundation Build. You should associate your check-in with that task so it gets reported as being completed.

Version Control Explorer

You can choose from a number of tools to access the source control inside Visual Studio. You can go to the File menu and select the Source Control item. (See Figure 6-9.) You can also use the Source Control Explorer window. (See Figure 6-10.) The Source Control Explorer window allows you to see all the available projects and individual files. You can also add new files to version control, get the latest versions, and even compare two different source-code revisions.

Figure 6-9 Accessing version control from the main menu

Figure 6-10 Using the Source Control Explorer

Pending Check-Ins

In addition to using the Source Control Explorer, you can use the Pending Check-ins window (available by choosing View and then selecting Pending Check-ins menu item). This window allows you to check in existing code, shelve and unshelve code, associate work items with the check-in, and perform other source-code-related tasks. The user interface is nearly identical to the wizard interface shown in Figures 6-7 and 6-8.

Pending check-ins are a way for you to determine which code you currently have checked out of version control. They also alert you to which code is stored only locally, which is valuable information because any changes made to locally stored code since check-out have not yet been uploaded to the server. A failure of your local system, then, could result in code being lost. Shelving your code can help prevent that from happening.

Shelving and Unshelving

Shelving code allows a developer to place his or her code on the version-control server, but it doesn't force a developer to do an official check-in. This process can ensure that your code is safely tucked away without requiring you to fully check in your code.

In many version-control systems, you simply check in your code, even in an unfinished state, and check it out later for the fixes. However, because of the possible check-in policies mentioned earlier, you might be unable to check in your code because it is not yet ready to pass the policies. In this case, you can simply shelve your code because shelved code doesn't have to pass any of the source-code-control check-in policies.

To shelve your code, simply select the items to be shelved in the Source Control Explorer window and click the Shelve button. You then provide the shelved code with a Shelveset name so that it can be unshelved as a group later. The code is then shelved. To unshelve your code, simply click the Unshelve button in the Source Control Explorer and select the Shelveset you want to unshelve. (See Figure 6-11.)

Figure 6-11 Unshelving code

When unshelving code, you might have a conflict with code that you have changed locally, because shelved code doesn't prevent you from editing the files that were shelved. (This allows you to shelve multiple versions of the same code if you want.) In that case, you'll be informed of the conflict and presented with options for resolving the conflict. (See Figures 6-12 and 6-13.)

Figure 6-12 Resolving conflicts

Figure 6-13 Resolving a local overwrite conflict

Shelving and unshelving open up many new possibilities for developing code. If a customer doesn't know what type of user interface design to choose, a developer can come up with several different versions of a window or Web page, each one having a different look and feel. Each version could then be shelved separately, and when the customer came in, the versions could be unshelved in turn and demonstrated, without affecting the remainder of the code.

Another use of shelving is dealing with the unavoidable need to fix a bug, right when you're in the middle of developing a new feature. With shelving, the feature you're working on can be directly shelved, leaving your code in the previous state (before you began working on the feature). You can then go back and fix the bug. When the bug is fixed, you can unshelve the code and continue work on your new feature. As long as the bug wasn't found in the code you were editing or writing for the new feature, you don't need to do anything. If it was, you are prompted to resolve any conflicts that occurred.

In the case of bug fixes, code shelving can be a lifesaver. Because the code for the new feature is likely incomplete and will not pass the check-in policies, you can simply put it to the side easily and continue working. You can also pass shelved code to another developer to look over, possibly for a security check or to help out with a particularly nasty bug.

Version Control Check-In Policies

Check-in policies are used to ensure that the code checked in to version control passes a set of minimum standards. Generally, senior developers or architects will specify the policies to ensure that the enterprise developers follow the appropriate coding guidelines when designing, building, and refactoring code. These check-in policies can also be enforced against unit tests that are checked in to the system as well.

Using check-in policies opens up a whole new frontier in code quality. The capability of an organization to programmatically enforce a comprehensive and tailored set of policies can ensure that developers build good, solid code that has far fewer bugs, is more secure, and is far more maintainable. Later, we'll discuss using code analysis to check code for hundreds of well-known security, reliability, maintainability, and performance rules, as well as check for the presence of several well-tested best practices. Developers can be forced to implement these configurable best practices and rules before their code will be allowed to be checked in to version control.