I'm in the process of migrating from VSS 2005 to TFS 2010. From what I have read a Basic branching plan will work for us.
But the issue i'm struggling with is how to automate our build process in TFS. As a development team we are use to 'cherry picking' what gets put into certification. This does not appear to be recommended for TFS.
I'll explain how our build process current works using VSS.
1. We have a $/Dev/Src folder where all developers check in their code.
2. When they check in their code they are prompted to enter a point number to tie the code items to. The tool that prompts the developer is a Visual Studio and Visual Source Safe Add-In. The tool lets the user
enter a point number then writes a database record specifying the point number, vss file path and vss file version.
the database table looks like this...
PointID : The point number from our point / issue tracking system.
FileName : The path to the file in Source Safe
Version: The version of the file in Source.
Cert Date: Date the file was pinned in the cert branch.
3. In VSS we have a $/Cert/Src folder which is shared from the $/Dev/Src folder. All the code files in this trunk are pinned. The pinning is maintained in the next step...
4. When we want to build code to certification we have an access database where we enter the point numbers. The access database uses the VSS API to pin each version of all files tied to all points in the list of points entered by the build
user (in the $/Cert/Src trunk). For example, if point 1000 has file1.cs version 10 checked into it, the access database would pin file1.cs to version 10 when building point 1000.
5. We then use FinalBuilder to get latest version of all code in the $/Cert/Src folder, perform the build and copy it to the appropriate location. As you know, getting pinned code means you get that version of the code regardless
of the number of revisions checked in afterward.
This basic process has been in place for 7 years and works well. Sure we run into dependency problems at times, but our Visual Studio / VSS Addin also prompts the developers when they start checking out a code file if the code file is tied
to a point that is currently marked 'in cert'. So they might hold off on working on that file until the change is completed and in production.
All of my web research says you should not cherry pick changes to move between branches. I don't think I can sell our organization on not cherry picking what changes move into the next QA cycle.
Also, in TFS I assume work items are similar to our points. I'm assuming a changeset is a snapshot of all code items when a check in occurred (even those items not explicitly checked out and changed). Are
my assumptions correct?
A couple other notes about our current build process
-Our applications are used in house only, not products we sell to customers. So our production build consists of copying certification code to production. This is true for our windows and web applications. Would
we really need a release branch?
-To build our development code we simply get all code from $/Dev/Src and perform a build.
I am doing some test team projects and visual studio solutions to work out the details of build automation but was hoping someone could give any guidance.
I apologize if this is not the correct place to ask this question. I would appreciate a pointer to somewhere else to ask this question if this is not the correct place.