locked
TFS Build and Deploy in different machine RRS feed

  • Question

  • All,

    We are currently using a MACHINE-A to build the C# Project, BizTalk project in that machine. And install all the Artefacts which are generated from the build into the same machine. Run the Unit Testing on the machine to validate every unit test passed or not....

    But we would like to go with a approach of Build all the stuff in the MACHINE-A as currently doing and Install all the output assemblies into a new machine called MACHINE-B which is clean machine and run the unit test in the MACHINE-A.

    Please advice this approach is possible if so how to achieve this. Any ideas/help/link/resources will be greatly appreciated.

    Cheers
    Raj
    Monday, December 8, 2008 5:19 AM

Answers

  • Hi Raj,

    Just to be clear.  The build on Machine A and the windows service on Machine B are not directly connected.  Machine B's service "wakes up" every so often and polls TFS to see what the name of the last good build of a given Build Definition is.  It then checks to see if it has already processed that build.  If it hasn't processed that build then it goes off and requests the build outputs (DLLs, EXEs, ASPX, MSI, etc) from the build's Drop Location and installs them onto Machine B, Machine  A plays no part in this.  Machine B's windows service is running as an autonomous system with a specific purpose and workflow as defined by your custom windows service code (or better yet Windows Workflow code).

    On machine B you would need the following:

    1. VSTS Developer, Tester or Suite.  Since you have Suite on your Machine A, I would say that Suite would work fine on Machine B.

    2. Team Explorer of the same version as your TFS.  This installs the TFS Client API dlls.

    3. You may need to install SQL Server or some other database to support your test schema and data.

    4. A custom Windows Service that you write that polls TFS for the "last good build" of a specific Build Definition.  This can be
          done entirely through the TFS Client API.  This windows service would need to do the following:

        a. Check TFS app tier throug the API for the name of the last good build of a given build definition. 
                You may have to get them all and iterate over the names or dates looking for the latest date.
        b. Deploy your databse and populate with test data
        c. Spawn a process to run the MS Testing framework command-line that will run your tests.
        d. Use the TFS Client API to publish the test run results against this build
        e. (Optional) Use the TFS Client API to change the build quality of this build to something like [Functional Test Passed] or [Functional Test Failed]


    Now to answer your questions:

    1. As stated above, Machine B is autonomous and "pulls" the info it needs from TFS and the Drop location.

    2. Yes.  The custom Service you write has to poll TFS to determine if it goes back to sleep or processes a new build.  This can work with any kind of build because the Service will just keep polling until it finds a new build.  So if you want to run this against Nightly builds, you just schedule the build to occur at say Midnight.   When midnight rolls around the build automatically kicks off.  At some arbitrary point after the build ends the Service on Machine B wakes up and notices a new build, it then runs through its workflow to deploy and test this build.  When it is done it goes back to sleep until tomorrow.

    3. Yes.  If you use the TFS Client API to publish your test results against the build being tested, those results will be "swept" into the warehouse the next tim the Warehouse Service runs (usually every hour).  So given the scenario in Answer 2 (above), you would likely have the Test Results available in the warehouse by the time you get into work in the morning.

    4. No.  Team Build does not need to be installed on Machine B.  This is not doing any building.  See the list above for Machine B's needs.

    - Steve
    Development Process Consultant - Notion Solutions - http://sstjean.blogspot.com
    Monday, December 15, 2008 2:14 PM
  • Hi Raj,
     
    I've worked with a team that has done something similar.  In our case we wanted to run extensive automated functional tests on our code after a CI build was completed.  We didn't want these long-running tests to impact the CI build so we did the following:

    Machine A - CI Build box
     - Runs the CI build and basic unit tests on every dev check-in.

    Machine B - Functional Test box
     - Create a windows service that polls TFS for the latest good CI build of a given type
     - If found, it installs the app on Machine B and deploys the test database
     - Once deployment is done it runs the suite of functional tests
     - When complete it changes the Build Status of the CI build tested to "Passed Validation" or "Failed Validation"
     - Repeat from top with latest good CI build

    This process doesn't test every CI build, since Testing on Machine B can take 20 - 30 mins but it does give the Dev lead a number of tested builds that can be promoted to QA.

    So the key component here is the custom Windows Service that polls TFS for the lastest good build, deploys it and the database and then runs the tests.

    - Steve

    Development Process Consultant - Notion Solutions - http://sstjean.blogspot.com
    • Proposed as answer by Bill.Wang Friday, December 12, 2008 3:54 AM
    • Marked as answer by Bill.Wang Monday, December 15, 2008 2:26 AM
    • Unmarked as answer by Senthilraj Krishnan Monday, December 15, 2008 5:01 AM
    • Marked as answer by Senthilraj Krishnan Thursday, December 18, 2008 9:50 AM
    Wednesday, December 10, 2008 1:19 AM
  •   Hi Steve,

    Thanks for your detailed explanation.. It is really good..

    The approach you suggested involves knowledge on TFS API's, Developmental and Testing work on the Windows API.

    To over come these effort I am having following approach. Please advice will it work..

    1. Create two TFS Build project - One for Building the entire project and second one for Installing and unit testing the Builded assemblies.
    2. Machine A - Builds the complete projects
    3. After completing build steps, call the install and unit test which will run on the Machine B
    4. In this approach it is not necessary to develop any windows service also automatically the unit testing publishing will happen with TFS build framework.

    Please correct me if I am missing any thing obvious.

    Cheers
    Raj

    Tuesday, December 16, 2008 4:28 AM

All replies

  • Hi Raj,
     
    I've worked with a team that has done something similar.  In our case we wanted to run extensive automated functional tests on our code after a CI build was completed.  We didn't want these long-running tests to impact the CI build so we did the following:

    Machine A - CI Build box
     - Runs the CI build and basic unit tests on every dev check-in.

    Machine B - Functional Test box
     - Create a windows service that polls TFS for the latest good CI build of a given type
     - If found, it installs the app on Machine B and deploys the test database
     - Once deployment is done it runs the suite of functional tests
     - When complete it changes the Build Status of the CI build tested to "Passed Validation" or "Failed Validation"
     - Repeat from top with latest good CI build

    This process doesn't test every CI build, since Testing on Machine B can take 20 - 30 mins but it does give the Dev lead a number of tested builds that can be promoted to QA.

    So the key component here is the custom Windows Service that polls TFS for the lastest good build, deploys it and the database and then runs the tests.

    - Steve

    Development Process Consultant - Notion Solutions - http://sstjean.blogspot.com
    • Proposed as answer by Bill.Wang Friday, December 12, 2008 3:54 AM
    • Marked as answer by Bill.Wang Monday, December 15, 2008 2:26 AM
    • Unmarked as answer by Senthilraj Krishnan Monday, December 15, 2008 5:01 AM
    • Marked as answer by Senthilraj Krishnan Thursday, December 18, 2008 9:50 AM
    Wednesday, December 10, 2008 1:19 AM
  • Thanks for Steve's help. Your replies in TFS forums are very valuable. :)


    Please mark the replies as answers if they help and unmark them if they provide no help.
    Monday, December 15, 2008 2:26 AM
  • Hi Steve,

    In this case

    Machine A
        Following software installed.
    1. VSTS - Suite edition
    2. BizTalk
    3. TFS Build Component
    4. etc.,

    My build tfsbuild.proj file initiated this build and it puts all the binaries and also wix packaged file in the location.

    Question:

    1. How to connect the Machine B in this build project because end of the test it needs to come in the test results as a common build results?
    2. By default I want to run the Unit Test for all of the builds.. In this case is it required to write the Windows service for poll the TFS? (We are not using Contineous Integration build)
    3. In your environment are you able to publish the test results in the data ware house? If so how you acheived that?
    4. Machine B - Also the TFS Build components needs to be installed? Is it the same set of software required like build machine?

    Please advice.

    Cheers
    Raj

    Monday, December 15, 2008 5:01 AM
  • Hi Raj,

    Just to be clear.  The build on Machine A and the windows service on Machine B are not directly connected.  Machine B's service "wakes up" every so often and polls TFS to see what the name of the last good build of a given Build Definition is.  It then checks to see if it has already processed that build.  If it hasn't processed that build then it goes off and requests the build outputs (DLLs, EXEs, ASPX, MSI, etc) from the build's Drop Location and installs them onto Machine B, Machine  A plays no part in this.  Machine B's windows service is running as an autonomous system with a specific purpose and workflow as defined by your custom windows service code (or better yet Windows Workflow code).

    On machine B you would need the following:

    1. VSTS Developer, Tester or Suite.  Since you have Suite on your Machine A, I would say that Suite would work fine on Machine B.

    2. Team Explorer of the same version as your TFS.  This installs the TFS Client API dlls.

    3. You may need to install SQL Server or some other database to support your test schema and data.

    4. A custom Windows Service that you write that polls TFS for the "last good build" of a specific Build Definition.  This can be
          done entirely through the TFS Client API.  This windows service would need to do the following:

        a. Check TFS app tier throug the API for the name of the last good build of a given build definition. 
                You may have to get them all and iterate over the names or dates looking for the latest date.
        b. Deploy your databse and populate with test data
        c. Spawn a process to run the MS Testing framework command-line that will run your tests.
        d. Use the TFS Client API to publish the test run results against this build
        e. (Optional) Use the TFS Client API to change the build quality of this build to something like [Functional Test Passed] or [Functional Test Failed]


    Now to answer your questions:

    1. As stated above, Machine B is autonomous and "pulls" the info it needs from TFS and the Drop location.

    2. Yes.  The custom Service you write has to poll TFS to determine if it goes back to sleep or processes a new build.  This can work with any kind of build because the Service will just keep polling until it finds a new build.  So if you want to run this against Nightly builds, you just schedule the build to occur at say Midnight.   When midnight rolls around the build automatically kicks off.  At some arbitrary point after the build ends the Service on Machine B wakes up and notices a new build, it then runs through its workflow to deploy and test this build.  When it is done it goes back to sleep until tomorrow.

    3. Yes.  If you use the TFS Client API to publish your test results against the build being tested, those results will be "swept" into the warehouse the next tim the Warehouse Service runs (usually every hour).  So given the scenario in Answer 2 (above), you would likely have the Test Results available in the warehouse by the time you get into work in the morning.

    4. No.  Team Build does not need to be installed on Machine B.  This is not doing any building.  See the list above for Machine B's needs.

    - Steve
    Development Process Consultant - Notion Solutions - http://sstjean.blogspot.com
    Monday, December 15, 2008 2:14 PM
  •   Hi Steve,

    Thanks for your detailed explanation.. It is really good..

    The approach you suggested involves knowledge on TFS API's, Developmental and Testing work on the Windows API.

    To over come these effort I am having following approach. Please advice will it work..

    1. Create two TFS Build project - One for Building the entire project and second one for Installing and unit testing the Builded assemblies.
    2. Machine A - Builds the complete projects
    3. After completing build steps, call the install and unit test which will run on the Machine B
    4. In this approach it is not necessary to develop any windows service also automatically the unit testing publishing will happen with TFS build framework.

    Please correct me if I am missing any thing obvious.

    Cheers
    Raj

    Tuesday, December 16, 2008 4:28 AM
  • Hi Raj,

    I think it is entirely possible to do what you suggest, but I'm not sure if it is more or less effort than creting a simple Windows Service project in VB.Net or C#.  From your comments, it sounds like you don't have access to development resources and aren't comfortable doing the development yourself.  In that case I can understand your reluctance to build out the testing service.

    I don't see any obvious caveats to using MSBuild for this other than needing to have the Team Build custom tasks installed on Machine B so that you have access to the test running and publication tasks. You will still need to have a Visual Studio Team System version installed to have the test runners.

    It sounds like an interesting project.  Post a note when you get done and let us know how it went. :)

    - Steve
    Development Process Consultant - Notion Solutions - http://sstjean.blogspot.com
    Tuesday, December 16, 2008 1:41 PM
  •  Thanks Steve for helpful replies..

    Cheers
    Raj
    Thursday, December 18, 2008 9:50 AM