We have had a few discussions and workshops … the resultant 1-2-3 guideline we are currently considering is as follows:
1. Create the source tree in Team Foundation Version Control (TFVC)
Once we have created the Team Project, we should perform basic housekeeping before opening the sluice gates allowing the developers and testers in. One of the housekeeping tasks is the creation of the source tree for the solution, which is documented in great detail, as all other tasks, on the patterns and practices site for VSTS Guidance.
Refer to “How To: Create Your Source Tree in Visual Studio Team Foundation Server” on the patterns & practices site as above, which outlines the following basic steps and options.
1. Create a Workspace Mapping
2. Create Your Main Folder
3. Create Folders for Your Project Artifacts
4. Perform a Get Latest Version to export the server side structure to the workspace
Once we have completed steps 1-3, we should see a source tree that resembles the following best practice tree:
An example view of an actual solution is shown in the following illustration:
The team project ScrapYard contains two applications, namely eApplication and fApplication.
2. Create the solution files (views) and add to the source tree
The next step is to create the various solution files, which we refer to as solution views, which break the solution into the various environments. The objective is that we have a master solution that includes all project artifacts and other solutions that contain only those artifacts relevant to specific team members. The advantage is that these views simplify the solutions, avoiding unnecessary clutter and speeding up the load and build time from a developer and tester perspective.
We have requested the creation of the best practice source tree and these base solution files to be optionally included in the team project creation process, however, for the time being, this is probably one of the manual and humanoid error prone processes that we should complete with great caution, again before opening the sluice gates.
The basic steps are as follows:
1. From the File menu select New, and then click Project.
2. Expand Other Project Types and then click Visual Studio Solutions.
3. Select Blank Solution.
4. Type the correct application name, i.e. eApplication, in the Name text box and select location C:\Sandbox\ScrapYard\Main\Source.
5. Click OK.
6. Repeat steps 1-5 for all known solutions.
If you need to create another solution view, proceed as follows:
1. Create an empty Visual Studio solution in a temporary directory, i.e. c:\temp\scrapyard and close it.
2. Copy the solution files from the c:\temp\scrapyard to C:\Sandbox\ScrapYard\Main\Source\XYZ, where XYZ is the appropriate solution, i.e. eApplication.
3. Open the solution in its new home.
4. In the Solution Explorer right click the solution icon and select "Add Solution to Source Control".
5. Repeat steps 1-4 for all known solution views.
3. Create the project files and add to the “solution views”
Add existing projects to the relevant solution file by copying the project folder to the solution in Visual Studio. The solution file will automatically be checked out for edit. Check the solution file back-in, which check-in the new project folder as well.
Add new projects to the relevant solution file by creating the new projects as normal and ensuring that you specify the target directory to be in the correct path within the source tree.
4. Double checking the source tree and workspace
The Source Control Explorer view of the source tree should reflect the best practices source tree or your customised source tree as shown:
Looking at your workspace on your local storage, you should see a replica of the solution as shown:
5. Prepare the project team
Before letting the team project members loose, it is important to run a quick TFS workshop preparing everyone for the following bare minimum, plus more where appropriate:
1. Quick TFS demonstration of the basic tools for those not experienced with TFS.
2. Explain the source tree and agree on what goes where, what goes to the team portal and what has not place in either.
3. Define and agree on the stakeholders, especially team project administrator and build master.
1, 2, 3 … GO! Open the gates …
Oh, we have one last issue we have not addressed in this post. When we have the best practice source tree structure, do we start on DEV, MAIN or PROD trunk and branch when needed, do we start on MAIN, branch immediately to DEV ... many, many options and as the answer is probably "it depends" we will mull over it. Watch this space.
