TFS Check-in check-out specification

A recent project, c#+.net3.5 do, the code management with TFS, the development team is not very complete, no special testers, plus the crew are not familiar with TFS, some or Java turned around, so tidy up a bit of the previous norms, forcing everyone to execute, looked at the online, this information is not much, sticky up caught dead

1) Conventions for development platforms
A) development of the operating system environment and end-user environment (including Service pack version number)

Development environment: WINDOWS2003SP2 WINDOWS7

User environment: WINDOWS2003SP2 SP1 WinXP

b) Development Tools version

VS2008SP1 + TFS Team Explorer

c) database type has been versioned

SQLServer2008

d) Version Control tool

Tfs

e) Implementation of the Development Code

"C # code Specification"

2) conventions of working methods
A) behavior before starting work (check out code before starting work every day) time: 8:30-9:30

Attention

1, as needed, check out the code you need to modify (note: When you check out the code, your checkout file will be synchronized with the server) do not check out all the code

2, modify the code, do not change the way you check out the others in the file, if necessary changes, please consult with the method author

3, the method body not too long, try not to more than 20 lines, more reconstruction

4. When a method is complete, build the unit test immediately and test the

5, unit testing needs to be repeatable test, do not appear to test only once, the next test must modify the database to re-test the problem
b) Daily check-in behavior (all development codes are required on the day of check-in) Time: 11:00-12:00 17:00-18:00

Check-In steps:

1. Select "Get Latest Version (recursive) on server" before checking in code (will not overwrite your checked-out file)

2, the compilation of all projects under the solution

3. Resolve compilation conflicts

4. Run Unit Test

5. Commit to check in your checked-out file
c) version control behavior (requirements for code commit and conflict resolution)

Resolve order 1, do not select Auto Merge when conflicts occur

2, automatic merger can not solve the Select the Resolve button, select manual merge
d) Note 1. When opening the solution, be sure to connect to the team development server when the network environment allows

3, prohibit the use of CTRL + A and other files with CTRL + C, CTRL + V to write back the overwrite code

4. Please write a brief description in the Description field when checking in the code

5. Associate valid work items when checking in code and select "Associate" or "resolve" according to the current situation

5) use Conventions for unit tests
1. Unit tests must test all methods in the class

2, as far as possible to expand the scope of unit testing, for example, in the Orgcompany class ID is an int value, if I give this value a floating point value 1.2323288 or a large number 1292310843812834923812348 method can be healthy catch error and return information, etc.

3, unit testing not only to test assert.isequal also assume assert.isnotequal Assert.isnull and other tests, a method can correspond to a number of test methods

4, each programmer is responsible for their own unit testing, to do the daily run at least two times their own unit tests
Implementation issues for development specifications
1) Making Problems
A) Encourage all project developers to participate in the formulation of the specification
b) Encourage the programmer to cross-test the bug, report to the team leader for approval and register to TFS, with the number of bugs as the project evaluation reward and penalty standard
2) implementation issues

A) in accordance with the development specifications for the code to detect, for the existence of problems require correction.
b) Implementation of development standards through cross-examination of team internal personnel

TFS Check-in check-out specification (GO)