locked
Conditional build in TFS CI RRS feed

  • Question

  • I am planning to introduce gated checkins in TFS 2015 for our project. Our product consists of one database, one web service and one web front-end. The database “build” and deploy take like 60 minutes. When that is done we generate C# source code for our Web service using meta data in the just deployed database.

    We the build the Web server and start it.

    Next step we generate C# source code for the Web front-end using the services in our running Web service.

    Now, I would like to avoid building and deploying the database whenever possible. I other words I would like TFS to “ask me”, custom script of software” if the database should be built and deployed. This could be done using C# code, perl, python Windows batch file or other scripting/coding, exit code 1 is perform the build, exit code 0 don’t or whatever.

    So, basically some feature in TFS that conditionally performs a build. I guess it could be two different builds, one with all steps and one with just Web service and Web frontend build. Please note that the database build is just a set of plain Windows batch files, two files to be precise.

    Is this supported in some way?

    Tuesday, April 12, 2016 12:23 PM

Answers

  • Hi Mikael R Carlsson,

    Thanks for detail. 

    In general TFS doesn't support such scenario out of the box but logically it is possible to implement these scenario. Below are my suggestions that you can try. however not sure if it will sound feasible to you.

    Scenario 1 - Single build definition approach: In this case you can

    1. Use variable for example ExecuteSQLScript with default value False in build definition.

    2. Select "Allow at Queue Time" check box for this variable.

    3. Create one more script powershell or vbscript or whatever you prefer to execute your database scripts.

    4. Take ExecuteSQLScript variable as parameter and implement if/else condition in script created in step 3. If ExecuteSQLScript is true then execute scripts else not execute.

    5. Implement build step to execute script created in step 3 and pass ExecuteSQLScript variable as argument.

    6. Add other build steps to perform required actions for Web Service and Web Front-end.

    7. Save and Queue new build.

    8. When you queue build, a popup window opens. In Popup window you can set variable value. So based on True or False value your script will be executed.

    Scenario 2 - Multiple Build Definition: In this case you can

    1. Create a build definition say BuildDefinition1 only for database script execution.

    2. Create another build definition say BuildDefinition2 for web service and web front-end operations.

    3. Perform some checkin as part of BuildDefinition1. Possibly you can create a version.txt file in which you can write build or release version on every successful build and check this file in back to source control. This approach will allow you to create a CI trigger for BuildDefinition2.

    4. Configure a CI trigger for BuildDefinition2 which will monitor path of version.txt and subscribe checkin event.

    This approach will allow you to run both build definition sequentially as well as independently. Meaning once BuildDefinition1 execution completes and database is deployed, it will trigger CI for BuildDefinition2 which will perform operation for web service and web front-end. Also, if you want to execute only BuildDefinition2 multiple times then you can execute it without affecting database part.

    Hope this helps.

    Regards,

    Shikhar Jain

    Wednesday, April 13, 2016 7:46 AM

All replies

  • Hi Mikael R Carlsson,

    Thanks for your question.

    Please clarify following:

    1. Do you wish to perform all operations sequentially using one build definition? Or

    2. You wish to create one build definition for database project and one for Web Service & Web front-end?

    Regards,

    Shikhar Jain

    Tuesday, April 12, 2016 1:04 PM
  • Hi!

    I do not know.

    I see no reason for restricting to only one build definition. I just want to make sure everything builds fine. If something is broken it will fail, correct?

    So if there is some support in TFS to handle the condition/decision if we need to build the database, one build definition is fine. If not I guess we have no choice but to include it into one large build and have the condition in the build script, or do you see any other way?

    One more thing, the database build is not a Visual studio project. It is a set of sql files. They are concatenated to larger sql scripts during the database "build", this is done in a Windows batch file. The "deploy script just executes the sql-script on the deployment server, also done in a Windows batch file. So it is very rudimentary.

      / Mikael

    Tuesday, April 12, 2016 3:05 PM
  • Hi Mikael R Carlsson,

    Thanks for detail. 

    In general TFS doesn't support such scenario out of the box but logically it is possible to implement these scenario. Below are my suggestions that you can try. however not sure if it will sound feasible to you.

    Scenario 1 - Single build definition approach: In this case you can

    1. Use variable for example ExecuteSQLScript with default value False in build definition.

    2. Select "Allow at Queue Time" check box for this variable.

    3. Create one more script powershell or vbscript or whatever you prefer to execute your database scripts.

    4. Take ExecuteSQLScript variable as parameter and implement if/else condition in script created in step 3. If ExecuteSQLScript is true then execute scripts else not execute.

    5. Implement build step to execute script created in step 3 and pass ExecuteSQLScript variable as argument.

    6. Add other build steps to perform required actions for Web Service and Web Front-end.

    7. Save and Queue new build.

    8. When you queue build, a popup window opens. In Popup window you can set variable value. So based on True or False value your script will be executed.

    Scenario 2 - Multiple Build Definition: In this case you can

    1. Create a build definition say BuildDefinition1 only for database script execution.

    2. Create another build definition say BuildDefinition2 for web service and web front-end operations.

    3. Perform some checkin as part of BuildDefinition1. Possibly you can create a version.txt file in which you can write build or release version on every successful build and check this file in back to source control. This approach will allow you to create a CI trigger for BuildDefinition2.

    4. Configure a CI trigger for BuildDefinition2 which will monitor path of version.txt and subscribe checkin event.

    This approach will allow you to run both build definition sequentially as well as independently. Meaning once BuildDefinition1 execution completes and database is deployed, it will trigger CI for BuildDefinition2 which will perform operation for web service and web front-end. Also, if you want to execute only BuildDefinition2 multiple times then you can execute it without affecting database part.

    Hope this helps.

    Regards,

    Shikhar Jain

    Wednesday, April 13, 2016 7:46 AM