Software Configuration Management Policies


--------------------------------------------------------------------------------------------------------------------------------------------------

Table of Contents

  • Quick Rule Synopsis
  • Section 1. Source Code Repository Structure
    • 1.1 Shelvesets and Private Branches
    • 1.2 Branching from Development Mainline
  • Section 2. Toolsets and Components
    • 2.1 Use of MindFusion's FlowChart.NET
    • 2.2 Use of NUnit
    • 2.3 Use of TestDriven.NET
    • 2.4 Use of NCover & NCoverExplorer
    • 2.5 Use of NDepend

--------------------------------------------------------------------------------------------------------------------------------------------------

Quick Rule Synopsis

  • Provide a useful check in comment describing at a high level what the changeset accomplishes.
  • Always associate a task APPROPRIATE to the code that is checked in.
  • NUnit is the expected unit test appliance.



This section will begin to define the structure of the project in terms of the source code repository, releases, builds, branches and merges. The text to follow will be assisted by a source repository template map which is a guide to the structures in the repository.


Section 1. Source Code Repository Structure

1.1 Shelvesets and Private Branches

The use of private developer branches should be a rare occurrence and is highly discouraged. In its place shelvesets should be used. This provides for a developer specific branch that does not appear within the normal repository tree and may persist and be used indefinately. Shelvesets should provide the needed functionality that would normally be used for temporary private developer branches.

The shelvesets are not to discourage or replace the utilization of the feature branch section of the repository. In fact in many cases a developer may start out with something in a shelveset for a personal proof of concept or prototype that then gets placed into the feature branch for a later iteration deliverable. The feature branches should always be driven from a workitem that is in turn driven from the iterations and scenario roadmap.

If anyone has any questions on how to use shelvesets don't hesitate to speak up.

1.2 Branching from Development Mainline

Any branching from the development mainline should be be done in collaboration with the Team Coordinator and other developers. A Team Coordinator has the final approval on all branching requests. As a developer you have the physical permissions within the source control tree to branch but it should not be done without discussion, and approval in the form of a task by a Team Coordinator. If you feel there is an immediate need for a branch utilize a shelveset, pending approval to create such a branch.

Requests for branching for the purposes of supporting various long term and more intensive interests in the form of divergent feature branches or significant research branches in utilization of new technologies such as .NET 3.0, LINQ, SVG, etc. are encouraged. If eventual branches are made for support of community interest in working with other technologies under the Vertigo project then new Areas will be created specifically for support of work items under these branches.

Section 2. Toolsets and Components

2.1 Use of MindFusion's FlowChart.NET

MindFusion has graciously provided the project with a Vertigo specific developers version of FlowChart.NET Pro. The provided dll's will only work with the CodePlex.Vertigo strongly named libraries. It is based on the public key of the public/private key used to sign the document. This allows all developers on the Vertigo project to use the tool for development without having to purchase the tool. Runtime distribution is free. The libraries, documentation and samples are placed in the source code repository under $/TFSVTreeBrowse/External/MindFusion. This path is for long term storage.

The main development line contains a copy for reference by the CodePlex.Vertigo.Controls project in $/TFSVTreeBrowse/Main/External/4.1.0.18962 Vertigo Version/. These dll's can be added to your Visual Studio 2005 toolbox. It's recommended that you maintain them in the same relative path to the CodePlex.Vertigo.Controls project since these are binary references. Since the public/private key pair is not publically available for signing of the assemblies the use of the public key portion with delay signing must be turned on. Furthermore in order to debug and run the delay signed assemblies you should for the purposes of development turn off verification of the assembly strong name for the specific assemblies or for all assemblies with the public token as defined at Public Key for Assemblies. This can be done with the command sn -Vr *,79fe4b0cb12744b2.

For directions on how to use the controls see the documentation that comes in the form of a .chm located at $/TFSVTreeBrowse/External/MindFusion/Docs/fcnet.chm and the samples located at $/TFSVTreeBrowse/External/MindFusion/Source/Samples/C#/. Additonal information can be found on the MindFusion website. No direct support is provided by MindFusion to the project for use of the components. But if you have difficulty using the tool during Vertigo development post any questions to the project forum and someone else on the team will try to answer them or select individuals may be able to get some assistance directly from MindFusion.

2.2 Use of NUnit

We will be utilizing NUnit v2.2.8 for .NET 2.0 as our unit testing tool. The installer can be downloaded from http://prdownloads.sourceforge.net/nunit/NUnit-2.2.8-net-2.0.msi?download and the documentation can be found at http://nunit.org/index.php?p=docHome&r=2.2.8

2.3 Use of TestDriven.NET

You can download and use a copy of TestDriven.NET from http://testdriven.net/download_select.aspx. The Personal license is valid for open source development. The site asks you to register prior to download and it stores this data in a cookie, so you may have to allow your browser to write one. There is a quickstart document at http://testdriven.net/quickstart.aspx. Jim Cansdale (author) has integrated this tool with NCoverExplorer so that you can now run "Test with... Coverage"

2.4 Use of NCover & NCoverExplorer

NCover will be used for code coverage metrics for the project. The current beta version (v1.5.4) can be found at http://ncover.org/SITE/files/4/ncover_setup/entry202.aspx

NCoverExplorer gives you a GUI to view your NCover data. It can be dowloaded from http://www.kiwidude.com/blog/2006/01/ncoverexplorer-downloads.html. This download also includes an FAQ in the zip file.

2.5 Use of NDepend

NDepend analyses .NET assemblies of an application and generates reports containing design quality metrics, warnings and diagrams. The fully functional v2.0 Beta 1 can be downloaded from http://www.ndepend.com/NDependDownload.aspx. You will be asked to enter an email address and the URL to the actual download will be sent to you. There is a QuickStart Tutorial online at http://www.ndepend.com/QuickStartTutorial.aspx

Last edited Jul 26, 2006 at 5:03 PM by sstjean, version 10

Comments

No comments yet.