Sharing a Solution in Visual Studio

To share a solution in Visual Studio, right-click the solution in Solution Explorer and select Add Solution to Source Control. If you are not already connected to a Team Foundation Server project collection, you select the server and project collection that you want to connect to. Then you select the location in the central version control repository that you want to use for sharing your source code.

If the path you selected is not under a locally mapped folder, you'll be prompted to specify which type of version control you want to use—either Team Foundation version control or Git—as shown in Figure 3.5.

If you are sharing code into a new Team Project then a good practice is to create a folder called Main (with possible additional subfolders like src for source code, docs, tools, and so on) under your Team Project and share the solution into it, as shown in Figure 3.6.

After you have set the location you want to use for sharing your files, click the OK button on the Add Solution to Source Control dialog window. The solution displays in Solution Explorer with a plus symbol to the left of it (see Figure 3.7). The plus sign indicates that the file is pending addition into version control.

In general, you don't want to see the dialog shown in Figure 3.6. This dialog appears when the local path you've selected is not a known folder to version control. If you've already created a workspace mapping for a team project and you pick a folder under one of your mapped folders, Figure 3.6 will not appear. Figure 3.6 typically appears when you create a new Visual Studio project and accept the default folder, which defaults to your profile directory's documents folder.

This solution at this point is not yet shared with Team Foundation Server. TFS version control works using a two-phased process. You first build up a list of changes that you want to make in version control and then you commit the changes in a single transaction called a changeset.

To check the files into version control, go to the Pending Changes page in Team Explorer by right-clicking on the solution in Solution Explorer and selecting Check In. Alternatively you can go to the Team Explorer view and then select the Pending Changes page. A third alternative is to go to View ⇒ Other Windows ⇒ Pending Changes.

The next section reviews the pending changes page. You commit your changes from there.

Sharing a Project in Eclipse

Microsoft provides an Eclipse plug-in as part of Team Explorer Everywhere. After you have the TFS plug-in for Eclipse installed, you may share a project in Eclipse easily. Right-click the project in Package Explorer and select Team ⇒ Share Project. The Share Project wizard shows the installed team providers in your Eclipse instance (see Figure 3.8).

Select Team Foundation Server and then choose the project collection that you want to connect to (if you have not already connected). Then select the desired TFS workspace. (You can also press Next to select the default TFS workspace, which is usually correct.) The Share Location page of the Share Project Wizard displays, as shown in Figure 3.9. From here you select a path in version control to share the files. As previously discussed you want to add your files into a folder called Main, so you simply enter the full server path into the Project folder path textbox that you want to share at. As mentioned earlier in the chapter, it does not matter that the Main folder does not exist yet; it is automatically created on the server when you perform the check-in.

Pressing Finish creates pending adds for all the files in the project into version control. The file icons are annotated in the Package Explorer with a small check mark to indicate that they are pending adds to version control (see Figure 3.10). Note, just as with Visual Studio, these files are not yet stored on the server; you must first check them in. To get the pending changes view in Eclipse, go to Windows ⇒ Show View ⇒ Other Windows ⇒ Team Foundation Server ⇒ Team Explorer and click the Pending Changes page.

In the next section, you find out how to work with the pending changes view to check in code to the source repository. You also find out about changesets and how to configure team check-in policies.

Candidate Changes

Before moving from the Pending Changes view, it is worth discussing Candidate Changes, which is a feature unique to a Local Workspace in Team Foundation Server 2012 and later.

Inside the Excluded Changes section is a Detected Changes link. Clicking it shows any candidate changes that Team Foundation Server has detected (see Figure 3.13). If you have made changes in the file system, such as adding or deleting a file outside of Visual Studio, then these changes are not automatically pended by Team Foundation Server. They are flagged as changes that you might want to add into your pending changeset. The example in Figure 3.13 shows five candidate changes.

In this case, the ui-icons image file was deleted by the developer from Windows Explorer as she realized that the file was no longer needed in the website. The developer renamed bullet.png to wingding.png while she had no network connection to Team Foundation Server and was working offline. The developer added testdata.txt in Windows Explorer as a data file to be used during testing, but she did not specifically add it to the solution, which is why Visual Studio did not explicitly pend an add against it. And finally testrun.dat was automatically created in the source tree as part of a unit test run, and the developer wants to make sure that she and her colleagues never accidentally check in this file.

As the developer renamed the bullet.png file inside Windows Explorer, Team Foundation Server has no way to automatically detect that this was a rename operation. It sees the changes as an add and a delete. If the change had been made inside of Visual Studio from Source Control Explorer or Solution Explorer then the rename would have been automatically detected and pended as such, which would have preserved the history of the file under the new name. The developer would like to preserve that this was a rename operation. She selects both bullet.png and wingding.png (by holding down Ctrl while making the selection) and then selects the Promote as Rename option, as shown in Figure 3.14. This creates a new pending change on wingding.png specifying that it was renamed from bullet.png.

Next the developer wants to ensure that no one ever accidentally checks in the file testrun.dat as this is generated as part of a unit test run and doesn't make up the code of the application. She right-clicks the file and selects Ignore This Local Item (see Figure 3.13). This creates a file in the folder called .tfIgnore that tells TFS to ignore this file from ever being added to version control. Note that the developer could have ignored all files with a .dat extension, or files called testrun.dat regardless of where they appear below the folder containing the .tfIgnore file. She even could have ignored the whole HelloWorldMVC.Tests folder. After the .tfIgnore file is checked in to version control, other developers will also ignore that file.

The developer is left with two candidate changes (see Figure 3.15) that are both checked. She clicks the Promote button as she wants to make sure that those candidate changes are included in the next changeset.

Performing the Check-in

Figure 3.16 shows that you now have the changes and how you want them recorded. There is a changeset comment, and a work item associated with the check-in will be marked as resolved when you perform the check-in. Click the Check In button. The changes are then committed to TFS in a single atomic transaction and given a changeset ID.

Note that if TFS could not have performed the check-in for some reason (perhaps another developer had checked in a conflicting change to the HomeController.cs file while you were editing your version) then none of the changes would have been checked in. You would have been notified about the conflict and given options to resolve the conflict before you were allowed to complete the check-in. Only when all the files included in the changeset can be committed to the repository is the changeset created and given the next incremented changeset ID for that project collection.

Note that as well as checking in from the Pending Changes view, there are a number of other actions on the drop-down menus next to the Check In button. You can shelve or unshelve code, find shelvesets, resolve conflicts, undo all changes, and, if you have an appropriate version of Visual Studio, you can request a code review using the Code Review feature.

Branch

A branch is a copy of a set of files in a different part of the repository that allows two or more teams of people to work on the same part of a project in parallel. In Team Foundation Server 2013, branching is a lightweight server-side operation; when you perform the branch, it doesn't actually create new copies of all those files on the server. It just creates a record pointing to them and does not take up any significant extra storage—one of the reasons why creating a new branch containing thousands or even millions of files can be done quickly.

Merge

A merge is the process of taking code in two branches and combining it back into one code base. For example, if you have two teams of developers working on two branches, and you want to bring the changes together, then you merge them. If the changes consist simply of edits to different files in the branches, then the merge is simple—but it can get more complicated, depending on what was edited in both branches.

For example, if the same line of the same file has been edited in both branches, the person performing the merge must make a decision as to which change should take precedence. In some circumstances, this results in a hybrid merge, where the combination of the intent behind the two changes requires a different result than simply the text in those versions being combined. When you branch, Team Foundation Server keeps track of the relationship between branches, as shown in Figure 3.25.

The branch containing the changes that you want to merge is called the source branch. The branch that you want to push the changes into is the target branch. The common ancestor, that is to say the changeset that indicates the version from which these branches are derived, is called the base version. When you merge, you can select a range of changes in the source branch to merge into the target branch.

Conflict

If the same file has been edited in both the source and target branches and the conflict can't be resolved automatically, Team Foundation Server will flag this as a conflict. For certain changes (such as a file that was edited in two different places), Team Foundation Server can make a good guess about what should happen (that is, you want to see a file containing the changes from both places). This is called an auto merge. Team Foundation Server 2012 introduced significant improvements to the auto merge capabilities and the occasions in which they are available. A best practice is to let the tool perform an auto merge, but you should then validate the merge results afterward to ensure the correct intent of the two changes has occurred. For example, if two different bugs were fixed, you probably want both changes. However, if the two changes were just fixing the same bug in two different ways, perhaps a different solution is in order. In most cases, where the development team has good communication, the changes are a result of different changes being made to the file. Auto merge usually does a great job of merging them together, making it easy for the developer to simply validate the changes.

There can also be many cases where the actual outcome is unclear, so auto merging is not available. For example, if you deleted the file in one branch and edited it in another, do you want to keep the file with the changes or remove it? The person performing the merge is responsible for deciding the correct conflict resolution based on an understanding of the code, and communicating with the team members who made the conflicting changes to understand their intent.

As with life in general, conflict is never good in version control. Making the decision about the correct conflict resolution in version control can be a complex and time-consuming process. Therefore, it is best to adopt a branching strategy that minimizes the likelihood of conflicts occurring. However, conflicts will occur, and Team Foundation Server provides the tooling to deal with them, so conflicts should not be feared.

Branch Relationships

When you branch a folder, the connections between those branches form a standard hierarchical relationship. The source of the branch is the parent, and the target of the branch is the child, as shown in Figure 3.26. Children who have the same parent are called sibling branches.

Baseless Merge

A baseless merge is a merging of two arbitrary branches in version control without reference to a base version. This is sometimes necessary if the source code was originally imported in a flat structure without the branch relationship being in place, or if you want to merge between one branch and another that is not a direct parent or child (for example, Branch A1 and Branch B1 in Figure 3.26).

Because no base version is being used to compare against, the probability of the server detecting conflicts occurring between the two branches is much higher. For example, if a file is renamed in one branch and edited in the other, it shows up as a file delete conflicting with the file edit, and then a file add that gives no hint as to which file it is related to, or that there is an edit intended for this file in the other branch. For this reason, baseless merges are discouraged. Your branching model should attempt to constrain most merges between parent and child branches to minimize the amount of baseless merging required.

Forward/Reverse Integration

Forward integration (FI) occurs when you merge code from a parent branch to the child branch. Reverse integration (RI) occurs when you merge code from a child branch up to the parent branch. The terms FI and RI can often fly around quite freely during a branching debate, so it is important to understand what they mean. If you are doing feature development in branches, it is common to use FI at various points during the feature development cycle, and then to use RI at the end. See the “Feature Branching” section later in this chapter for more information.

No Branching

It may be counterintuitive, but the simplest branching technique is to not branch at all. This should always be your default position. Do not branch unless you know you need to. Remember that you are using a version control tool that tracks changes over time. You can branch at any point in the future from any point in the past. This gives you the luxury of not having to create a branch “just in case”—only create branches when you know you need them.

However, there are things you can do to prepare yourself to make branching easier in the future if you decide you need a branch.

Figure 3.27 illustrates the most important thing that you should do if you think you might possibly need to branch in the future. When you first create your team project in Team Foundation Server, create a folder called Main and check it in. Then, right-click the folder in Source Control Explorer and select Branching and Merging ⇒ Convert to Branch to get to the screen shown in Figure 3.28.

With no branching, you only have one code line to work in for all teams. This technique works great when you have small teams working on the same code base, developing features for the same version of the application, and supporting only one version of the application at a time. At some point, no matter how complex your branching strategy evolves to support your business needs, you need at least one stable area that is your main (or mainline) code. This is a stable version of the code that will be used for the build that you will create, test, and deploy.

However, during stabilization and test periods, while you are getting ready to release, it may be necessary for the team to not check in any new code into the code base (that is, undergo a code freeze). With smaller teams working on a single version, this does not affect productivity because the people who would be checking in code are busy testing to ensure that the application works, as well as getting ready for deployment.

With this technique there is no way to start work on something new before the final build of the current version has been performed. The code freeze period can, therefore, be very disruptive because there is no way to start work on the next version until the current one has shipped. It's these times when other strategies become useful for teams of any size, even a team of one.

Branch Per Release

After no branching, the second most common branching technique is branch per release. With this technique, the branches contain the code for a particular release version, as shown in Figure 3.29.

Development starts in the Main branch. After a period of time, when the software is considered ready, a branch is made to the V1 branch, and the final builds are performed from it. It is then released into production (with the code in the final production build getting a label to indicate which versions of which files were in that version). Meanwhile, development of new features for version 2 (V2) continues on the Main branch.

Let's say that some bugs are discovered in production that must be addressed, and a small change is necessary to reflect how the business needs something to work. However, the development group does not want to include all the work for V2 that has been going on in the Main branch. Therefore, these changes are made in the V1 branch, and builds are taken from it. Any bug fixes or changes that must also be included in the next version (to ensure the bug is still fixed in that next release) are merged back (that is, reverse-integrated) into the Main branch. If a bug fix was already in the Main branch, but needed to go into V1, then it might simply be merged (that is, forward-integrated) into it. At a certain point, the build is determined to be good, and a new V1.1 build is performed from the V1 branch and deployed to production.

During this time, development on the next version can continue uninterrupted without the risk of features being added into the code accidentally and making their way into the V1.X set of releases. At a certain point, let's say that it is decided that V2.0 is ready to go out the door, the mainline of code is branched again to the V2 branch, and the V2.0 build is created from it. Work can continue on the next release on the Main branch, but it is now easy to support and release new builds to customers running on any version that you want to keep supporting.

Branch per release is very easy to understand and allows many versions to be supported at a time. It can be extended to multiple supported releases very easily, and makes it trivial to view and compare the code that was included in a particular version of the application. Branch per release is well-suited to organizations that must support multiple versions of the code in parallel—such as a typical software vendor.

However, for a particular release, there is still no more parallelism of development than in a standard “no branching” strategy. Also, if the organization must only support two or three versions at a time (that is, the latest version, the previous version, and, perhaps, the version currently being tested by the business) then this model can lead to a number of stale branches. Although having lots of old, stale branches doesn't affect the performance of Team Foundation Server, or even cause any significant additional storage requirements, it can clutter the repository and make it difficult to find the versions you are interested in—especially if the organization releases new versions frequently. If this is the case, you may want to move old branches into an Archive folder, and only have the active branches (that is, the versions that the development team are currently supporting) in the Releases folder.

Code-promotion Branching

An alternative to the branch per release technique is code-promotion branching (or promotion-level branching). This technique involves splitting the branches into different promotion levels, as shown in Figure 3.30.

As before, development starts with just the Main branch. When the development team is ready to test the application with the business, it pushes the code to the Test branch (also often called the QA branch). While the code is being tested, work on the next development version is carried out in the Main branch. If any fixes are required during testing, they can be developed on the Test branch and merged back into the Main branch for inclusion in the next release. When the code is ready to release, it is branched again from Test to Prod. When the next release cycle comes along, the same is done again. Changes are merged from Main to Test and then Test to Prod.

Code-promotion branching works well in environments that have a single version running in production, but have long test-validation cycles that do not involve all of the development team. This allows development to continue on the next version in Main while test and stabilization of the build occurs in the Test branch. It also makes it trivial for the development team to look at the code currently on each system. Finally, the branch structure makes it easy to create an automated build and deployment system using Team Foundation Build that can automatically update the QA/Test environment as code is pushed to the QA branch.

Feature Branching

The previous branching strategies involve a single team working on the system in its entirety as they work toward a release. All features for that release are developed in parallel, and the build can be deployed only when all features in flight have been completed and tested. However, in large systems, or systems that require very frequent deployment (such as a large commercial website), feature branching (or branch per feature), as shown in Figure 3.31, can be useful.

Feature branching is used when a project requires multiple teams to be working on the same code base in parallel. In Figure 3.31, you see four feature teams working in separate branches (F1, F2, F3, and F4). Note that in a real branching structure, the feature branches themselves would likely have meaningful names such as FlightSelling, InsuranceExcess, or whatever shorthand is used by the project to refer to the feature under development. The Main branch is considered “gold code,” which means that no active development goes on directly in this branch. However, a feature must be reverse-integrated into this branch for it to appear in the final release build and for other teams to pick it up.

Initially, F1 is started with a branch from Main. But, while F1 is being developed, second and third teams start F2 and F3, respectively. At the end of development of the feature, F1 is merged back into the Main branch, and the F1 branch is deleted. Then that team starts on feature F4. The next feature to finish is F3, followed by F2. At each point, after the feature is merged into the Main branch, a new version of the software is released to the public website, but only one version is supported at any time.

Feature branching allows for a large amount of parallel development. However, this comes at the cost of delaying the pain of integrating each team's changes together until the feature is complete and you are merging the feature branch back into the Main branch. For example, in Figure 3.31, when merging the F2 branch, all changes and inevitable conflicts introduced by features F1, F2, F3, and F4 must be analyzed and resolved.

The longer a period of time that code is separated into branches, the more independent changes occur, and, therefore, the greater the likelihood of merge conflicts. To minimize conflicts, and to reduce the amount of integration debt building up, you should do the following:

• Keep the life of a feature short—The time taken to develop features should be as short as possible, and should be merged back into the Main branch as soon as possible.
• Take integrations from the Main branch regularly—In the example shown in Figure 3.31, when F1 is merged back into Main, the feature teams still working on their features should merge those changes into their feature branches at the earliest possible convenient point.
• Organize features into discrete areas in the code base—Having the code related to a particular feature in one area will reduce the amount of common code that is being edited in multiple branches, and, therefore, reduce the risk of making conflicting changes during feature development. Often, the number of teams that can be working in parallel is defined by the number of discrete areas of code in the repository.

When using feature branching, the whole team doesn't necessarily have to be involved. For example, one or two developers might split off from the rest of the team to go work on a well-isolated feature when there is a risk of the move not being possible (that is, they are working on a proof of concept), or when it is decided that the current release should not wait for that particular feature to be implemented.