| I recently needed to come up with a project configuration management strategy using VSS 6.0d (no TFS for us :(...) for my development team and decided to put something together outlining the steps involved to accomplish this. Maybe this can help someone else looking to do the same.... |
| SourceSafe Version Control |
| Since a majority of development projects are in constant flux, development teams need the ability to work in parallel environments so that they can continue to work on newer versions of projects as well as provide subsequent updates and changes on previously released project code bases. Visual SourceSafe has a set of features, such as share, pin, and branch, which allow developers to facilitate this kind of parallel development environment. |
| |
| Label Promotion |
| Using label promotion and the standard VSS features, we can provide management for multiple projects and their different versions via snapshots or views represented by labels. In order to provide snapshots of a particular version in a file or project's history, VSS uses what it is called, "sharing". There are two ways to share files in VSS, pins and branches. |
| |
| Pins |
| Visual SourceSafe defines a pin as a marker that designates a specific version of a file as the version that is part of a project. The pin is represented by a pushpin icon, and is added through the Pin command in the History of dialog box. They are simply pointers to a particular version in a file's history. To change the version of the file the pin points to, all you have to do is simply unpin the shared file, and then pin it again to the version you want. In the context of a project, pins are used to provide specific snapshots of a particular project configuration. |
| |
| Branches |
| Branching is the process of separating a shared file among two or more branches. During branch creation, the share link is broken for the shared file. After branching, files will have a shared history up to a certain point and divergent histories after that time. Branches differ from pins in that they represent a completely separate baseline for the source code that is entirely independent from which the version they branch was originally created. Branches are used when a new baseline is needed to permit development or maintenance of one baseline independent of development or maintenance of another. |
| |
| Below is a sample base project structure and steps on how to use VSS label promotion and versioning (This is just an example, your implementation will depend on your specific needs): |
| |
- YourCompany_VSSDirectoryName
- Dev Branch
- Project_101
- References
- Source Codes
- Unit Tests
- Etc...
|
| DEV Branch |
| This is the main branch of the project. It serves as the daily check-in and check-out environment for the given project. Individual developers may freely add and update files in this level. Developers should not expect that source in this level is in a useful condition. That being said, proper commenting should be exercised by the members of the development team when checking-in code that is not in a usable state. QA Build This level holds code that compiles and is ready for quality assurance testing. The default policy is that individual developers or build masters will be able to promote code to this level from the DEV Branch. By promoting to this level, the developer is certifying that the code compiles properly and has been successfully unit tested. This level of the project tree contains pins to particular versions in the project file history maintained in the DEV Branch sub-tree. At first, the files will be promoted to this level as a group of files (i.e. for example a Website Project). Following promotion, updates will normally be done on an individual file basis. |
| Promoting Sub-trees and Directories to QA Build |
| This procedure assumes that the sub-tree has not previously been promoted. If it already exists, you should delete the sub-tree in the QA Build segment before doing this. Caveat emptor, however, since history has shown that VSS databases have been prone to corruption after excessive deleting, re-pinning, and exceeding recommend storage limits. |
| In order to promote a sub-tree from DEV Branch to QA Build, follow these steps: |
- Label the sub-tree:
- In the DEV Branch segment, right click the top level of the sub-tree you are promoting to display the pop-up menu.
- Select Label...
- Type the text for the label. Use a descriptive name such as QA Build_v1.0_[mm]_[dd]_[yy].
- Click OK. SourceSafe will apply the label.
- Right-click the top level of the sub-tree again to display the pop-up menu.
- Select Show History...
- Check the Include Labels: and Labels Only check boxes.
- Click OK. SourceSafe will display the history dialog box.
- Select the version in the history with the label you just applied.
- Click Share. SourceSafe will display a dialog box showing the project tree.
- Select the node in the QA Build segment, or the node itself, that will be the parent of the sub-tree. For instance, if you are promoting a website project /My_Web_Project that is in a directory YourCompany_VSSDirectoryName/Dev Branch/, you would select the QA Build node.
- Make sure the Branch after share check box is not checked.
- Click OK. SourceSafe will display another dialog box.
- Enter a name for the new node. In the example above, you would simply enter /My_Web_Project_v1.0 since you are promoting the My_Web_Project website.
- Check the Recursive check box.
- Click OK. SourceSafe will create a new sub-tree below the node you selected in step 8. The new sub-tree will include pins to the versions of the files you labeled in step 1, recursively.
|
| Resulting Structure will look as follows: |
- YourCompany_VSSDirectoryName
- Dev Branch
- My_Web_Project
- References
- Source Codes
- Unit Tests
- Etc...
- QA Build
- My_Web_Project_v1.0
- References
- Source Codes
- Unit Tests
- Etc...
|
| Promoting Updates to Individual Files |
Follow this procedure when updating the QA Build version of a file that already exists in the QA Build segment. To promote an updated version of a file from DEV Branch to QA Build, follow these steps:
- Check-in the file in the DEV Branch segment.
- Select the file in the QA Build segment and right click it to display the pop-up menu.
- Select Show History...
- Make sure the Labels Only check box IS NOT checked.
- Click OK. SourceSafe will display the file's version history, with a pushpin icon next to the version currently pinned to QA Build.
- Click Unpin. SourceSafe will remove the pin icon.
- Select the version you want to include in QA Build. This will usually be the latest version at the top of the list.
- Click Pin. SourceSafe will place a pushpin icon next to the version.
- Click OK.
|
| RC Build |
This level includes named testing versions of the project and its source code that can be reproduced if necessary. These versions consist of pins that represent snapshots of the project at the time a test build was created. You create them by sharing the current state of QA Build.
Versions in this level are used to conduct independent and user acceptance testing and represent candidate versions for release. It is recommended that only the designated Project's Configuration Manager(s) be responsible for promotion from QA Build to this level. Versions should be given labels that are easily identifiable as test builds, using some form of approved numbering system. |
| Creating a Release Candidate Version |
- 1. Label the QA Build segment:
- 1. Right click QA Build to display the pop-up menu.
- 2. Select Label...
- 3. Type the text for the label. Use a descriptive name such as
RC Build_[mm]_[dd]_[yy].
- 4. Click OK. SourceSafe will apply the label.
- 2. Right click QA Build again to display the pop-up menu.
- 3. Select Show History...
- 4. Check the Include Labels: and Labels Only check boxes.
- 5. Click OK. SourceSafe will display the history dialog box.
- 6. Select the version in the history with the label you just applied.
- 7. Click Share. SourceSafe will display a dialog box showing the project tree.
- 8. Select RC Build. Make sure the Branch after share check box IS NOT checked.
- 9. Click OK. SourceSafe will display another dialog box.
- 10. Enter a name for the new node. To make it easier, use the label that you applied earlier such as My_Web_Project_v1.0_RC.
- 11. Check the Recursive check box.
- 12. Click OK. SourceSafe will create a new sub-tree for the test version in RC Build. Once completed, you can use the Get Latest Version option to reproduce this RC Build version at any time in the future.
|
- YourCompany_VSSDirectoryName
- Dev Branch
- QA Build
- RC Build
- My_Web_Project_v1.0_RC
- References
- Source Codes
- Unit Tests
- Etc...
|
| Release |
The release level includes actual released versions of a project. At this level, we will use branches rather than pins to permit development to continue on later versions while still allowing maintenance patches on the previously released code base. The versions here will be created from the RC Build versions that were accepted by the release authority, whether that is a user acceptance group or a quality control group.
Only the project's designated release coordinator should be responsible for promotion from RC Build to this level. Versions should be given labels that are easily identifiable as releases (i.e. V_1.1.0.0)
Release versions are independent branches that can be reproduced to create maintenance patch code bases. To promote a RC Build version to a Release follow these steps: |
- Label the RC Build versions:
- Right click the RC Build version node to display the pop-up menu.
- Select Label...
- Type the text for the label. Use a descriptive name such as Release_v1.0.
- Click OK. SourceSafe will apply the label.
- Right click the RC Build version node again to display the pop-up menu.
- Select Show History...
- Check the Include Labels: and Labels Only check boxes.
- Click OK. SourceSafe will display the history dialog box.
- Select the version in the history with the label you just applied.
- Click Share. SourceSafe will display a dialog box showing the project tree.
- Select Release. This time, check the Branch after share check box (**).
- Click OK. SourceSafe will display another dialog box.
- Enter a name for the new node. To make it easier, use the label that you applied earlier, such as Release_v1.0.
- Check the Recursive check box.
- Click OK. SourceSafe will create a new sub-tree in Release. You can then use the Get Latest Version option to reproduce this Release version in the future. Since it is a branch rather than a pin, the maintenance staff can also conduct updates to the code and provide patch releases independently of continuing work on future releases.
|
- YourCompany_VSSDirectoryName
- Dev Branch
- QA Build
- RC Build
- Release
- My_Web_Project_v1.0_Release
|
| **Note: When performing fixes to any branched files or projects these fixes will need to be merged into the original parent code branch at some point. |
And thats pretty much it! Customize this and maybe write your own msbuild script that incorporates some of these steps using build tasks to make your process even smoother.
Regards, Mark |