This project has moved. For the latest updates, please go here.

Migrating from VSS to TFS - Build automation question

Nov 10, 2010 at 3:38 PM

Hello -

  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.

  Thanks 

 

 

Developer
Nov 10, 2010 at 4:02 PM

Your VSS $/Dev/Src folder would be similar to the Dev branch in the basic branch plan. The Dev branch in this plan is a full child of the Main (top level) branch

Your point number seems to be similar to a changeset ID. I am assuming that *only* the code items that are checked-in together are tied to a given point number.

As you probably know, TFS does not have the same concept as shared code or pinned code

As a general rule, in TFS the recommended process would be:

  1. When the code in Dev is ready for Cert (it passes quality gates and builds), Merge the latest code in Dev to Main
  2. Build the code in Main and deploy to QA
  3. You can consider using labels in TFS to mark a milestone, but labels are NOT immutable in TFS - this means that changes can be made to the files and versions of files within the label.

I believe the isolation offered between the Main and Dev branches should eliminate the need to do cherry picking for a Cert build

This isolation should also minimize the problem where a developer needs to wait while code is being stabilized and moved to production (stabilization happens in the Main branch while development happens in the Dev branch)

TFS work items do not seem to be similar to your points. As I indicated earlier, from what I understand, your points seem to be most similar to a Changeset ID which is generated on a check-in of one or more files.

When you check-in one or more files as part of a change-set you have the option in TFS of associating one or more work-items with the changeset. Typically these work-items would be tasks or bugs. For example if a bug is reported, when a developer makes a code change to resolve the bug, the bug work item would be associated with this check-in of the fixed code.

Typically you need a release branch to isolate released code from ongoing development. The Release branch is vCurrent (for example v1.0), the Development branch is vNext (for example v1.1 or v2.0) and the Main branch is used for stabilizing code from development to get it ready for release. If you have a post-release bug that you need fixed, having the Release branch with an exact copy of your production code enables you to quickly fix the bug. It is conceivable that the Main branch already has vNext code and it would not be advisable to do a hotfix for production here.

A Changest is not a snapshot of all code items at the time of a check-in. It is a record of the changes to files that are part of the check-in only. A *snapshot* in TFS is more along the lines of a label. Files that are not explicitly checked out and changed would never be associated with a changeset but would be associated with a label.

Regards,
Bill Heys
VS ALM Ranger

Nov 10, 2010 at 4:57 PM

Bill -

  I very much appreciate your quick response!     Coming from the VSS world I keep thinking in terms of shared and  pinned code and trying to apply that to TFS.    I need to remove my VSS lenses to actually see what TFS is.  :-).  I'll admit it has not been easy for me. 

  You are correct that *only* the code items checked-in are tied to a given point number.     The reason I thought they tied to work items was because our users create the point numbers which we then tie code files to.   A point can be a bug, new feature, etc.        As you pointed out, changesets are generated when the code is checked in.    

  To utilize our existing point tracking system I could hook into the TFS automation model and when a changeset is created tie it to a point number.   

  A few more questions....

  1.  How do you communicate to your testers what is ready for testing?  Users don't have a concept of changesets, but i'm assuming they do deal with work items or some issue tracking system.   But you integrate changesets.     So whoever is responsible for the QA build performs the integration and then queries what workitems just were included in the integrated changesets?   Or am I totally missing something?

  2.   When you say the isolation between the Main and Dev branches should eliminate the need to cherry pick for a cert build - but don't times exist when we don't want to push all changesets from Dev to Main?    Or am I still looking at things from a VSS perspective?    We have times when a larger change might be ready for QA but the testers are not ready to test it.     So we push other code to QA and when the users have more bandwidth for testing we push out the larger change.  Of course, we run into dependency issues where a larger change has to move into QA because it touches the same code files as other changes.

 3.    I have some questions on the paragraph that starts with  - Typically you need a release branch to isolate released code from ongoing development.     But I want to think it through some more before asking.

 Thanks for your help again Bill.

  Rob 

 

 

 

Developer
Nov 10, 2010 at 5:45 PM

Rob,

1. Yes. It is possible to do a Work Item query to determine all work items (tasks, bugs) that were associated with changesets since the last build deployed to QA. This is why it is very important for developers (and others) to follow the policy of associating all of the appropriate work items to a changeset at check-in time.

2. As a general rule, you would want QA to test all of the changes from DEV that have been pushed to MAIN. In this case you probably want to merge *All Changes up to Latest Version*. In your example, where you do not want all changes from Development to be sent to QA, cherry picking might be a good option. Be aware that when you cherry pick changes, you may be merging a code state that does not build or that does not include all of the changesets for a particular feature you want to test. There is also the possibility of future merge conflicts when you do a cherry picking merge followed by a merge from latest version, etc.

Regards,

Bill
VS ALM Ranger 

 

Developer
Nov 10, 2010 at 5:54 PM

Rob,

Trying to play devils advocate here.

When you do a merge you have several options:

  • Merge Selected Changesets
  • Merge All Changes up to:
    • the Latest Version
    • A Changeset
    • A Date
    • A Label
    • Workspace Versio

I am not sure if labelling helps you out here, or perhaps feature team branching where different features are developed in different development branches.

It maybe that the *larger change* you mention is part of one feature, but perhaps it is a set of features. Dividing the development into separate feature branches would allow you to merge the changes from one feature team branch (or deploy to qa directly from that branch) without including the changes from other features in other branches.

Regards,
Bill Heys
VS ALM Ranger.

Nov 10, 2010 at 6:02 PM

Bill -

  I very much appreciate your input!

 I'll digest all this information and continue to do some testing.  

 I will probably repost later when I have a better grasp of everything.

 Thanks again for your time Bill.

  Have a good day - 

  Rob