Use the TFS MSBuild scripts This example describes how to set up a database deployment pipeline using TFS and Redgate tools. You'll use the DLM Automation TFS MSBuild scripts to build, test, sync and publish a NuGet package to your release management tool. Most of this tutorial describes how to set up TFS and SQL Source Control. If you're only interested in how the DLM Automation TFS Build plugin works, start from step 7, Configure the properties files. 1. Install software and download demo files Make sure you have the following: Access to Team Foundation Server (TFS) 2010, 2012, 2013 or 2015. This tutorial series uses TFS 2012. Visual Studio 2010, 2012, 2013 or 2015. This tutorial series uses Visual Studio 2012. For details of which TFS and Visual Studio versions can work together, see Compatibility between Team Foundation clients and Team Foundation Server (MSDN article). If you want to publish test results in MSTest format, you'll need to have Visual Studio Premium, Ultimate or Test Pro installed on the machine running your build agent. SQL Server Management Studio (SSMS) 2008 (RTM, SP1, SP2, R2, R2 SP1, and R2 SP2), 2012, or 2014 (CTP2) Access to a SQL Server 2012 or 2014 instance with common language runtime (CLR) integration enabled. For more information, see Enabling CLR integration (MSDN article). This tutorial uses SQL Server 2012. Redgate SQL Source Control installed on the same machine as SSMS. See SQL Source Control The WidgetShop demo files. Download the WidgetDevelopmentDatabaseCIDemo.zip file, and extract the contents. .NET 4.5 installed on your local machine. This program is installed automatically with Visual Studio 2012 and 2013. If you're using Visual Studio 2010, you'll need to install it manually. See Microsoft .NET Framework 4.5 (Microsoft Download Center) DLM Automation, installed on the machine running the build agent. See Installing (DLM Automation documentation). Redgate's DLM Automation TFS MSBuild scripts copied to the machine running the build agent. See Setting up the TFS MSBuild scripts. Error rendering macro 'excerpt-include' User 'null' does not have permission to view the page. 6. Set up the build in Visual Studio 1. In Team Explorer, click Home and then click Builds. 2. Click New Build Definition, if your are using TFS 2015 click New Xaml Build Definition: 3. On the General tab: a. in the Build definition name text box, type WidgetDevelopment. b. 3. b. under Queue processing, select Disabled. We'll enable this once configuration is complete. 4. Click Trigger and select Continuous Integration: 5. Click Workspace. Make sure the $/WidgetShop source control folder is displayed. If it isn't: a. Click in the Source Control Folder field, and then browse to and select the WidgetShop folder. b. Click OK. 6. 6. Click Build Defaults. Under Staging location, select Copy build output to the following drop folder and enter the shared location that you want to use as your drop folder. 7. Click Process. You need to configure a number of build process parameters on this page. a. Under 1. Required > Items to Build > Projects to Build, click the browse button. Click Add and select DLMAutomation.proj, then click OK on each of the two dialogs. If you can't see the project file, select MSBuild Project files (*.*proj) from the Items of type drop-down list. b. Under 2. Basic > Build Number Format, replace the default format with 1.0$(Rev:.r) This means your builds will be numbered 1.0.1, 1.0.2, 1.0.3, and so on. The second '.' is added automatically before the final digit, because it's defined in (Rev:.r). c. Under 3. Advanced > Agent Settings, click the expand arrow. Click Name Filter and select the TFS server name from the drop-down list, for example, dptc12 - Agent1. d. Scroll down to the 3. Advanced properties list and click MSBuild Platform. Select X86 from the drop-down list. The Process page should look similar to this: 8. Press Ctrl+S to save the build definition. 9. Under Default Template near the top of the page, click Show details. The build process XAML file and version control path are displayed: 9. 10. You need to configure the XAML file so that TFS passes the build number and binaries directory as variables. To do this, complete the instructions in Passing TFS Build properties to MSBuild using TFS 2010 or later. The build definition is now set up. 7. Configure the properties files Properties files contain commands that configure your TFS build steps. The properties files are: DLMAutomation.global.properties DLMAutomation.build.properties DLMAutomation.test.properties DLMAutomation.sync.properties DLMAutomation.publish.properties In this example, we're going to configure the global and build properties files. Configure the global properties file Global commands are required by every TFS build step. You can use most of the default option settings. 1. In Visual Studio, go to Source Control Explorer and open $\WidgetShop\dlmAutomation-steps\DLMAutomation.global.properties. 2. Set WidgetPackage as the package ID. For example,<packageId>WidgetPackage</packageId> This is the name of the package you're going to create. 3. At the licenseSerialKey option, enter your DLM Automation license key if you have one. For example, <licenseSerialKey>123-456- 789012-ABCD</licenseSerialKey> If the license has been activated on this machine already, the key is displayed. If you don't have a serial number, leave this option blank and a 28 day free trial will start automatically. 4. Press Ctrl+S to save the file. Configure the build properties file Build commands create and validate the SQL creation script used to generate the NuGet package. For more information, see Build step command options. If you're using Redgate's DLM Dashboard (version 1.4.4.313 or later), you can send information to it about the packages DLM Automation builds. Once the packages are deployed, they're displayed on the dashboard as recognized schema. For more information, see DLM Automation integration (DLM Dashboard documentation). 1. Open $\WidgetShop\dlmAutomation-steps\DLMAutomation.build.properties. 2. At the scriptsFolder option enter the path to the database scripts folder in source control relative to the project file. For example: <scriptsFolder>.\WidgetShop\Database\ScriptsFolder</scriptsFolder> 3. If you're using DLM Dashboard: a. at the dlmDashboardHost option enter the name or IP address of the machine hosting DLM Dashboard. For example: <dlmDashboardHost>localhost</dlmDashboard> b. at the dlmDashboardPort option, enter the port number. Ignore this if you're running the DLM Dashboard on default port 19528. 4. If you want to include SQL Doc database documentation in the NuGet package, at the includeDocs option, change the value from False to True so that it looks like this: <includeDocs>True</includeDocs> Including database documentation will increase the size of the NuGet package and the time it takes to build, particularly for large databases. The documentation is stored in db > docs > main.html in the NuGet package. If you're using DLM Dashboard version 1.6.3 or later and have set up DLM Dashboard integration, you can also view the documentation directly from DLM Dashboard. See DLM Automation integration (DLM Dashboard documentation). For help understanding SQL Doc documentation, see What's in the documentation? 5. Press Ctrl+S to save the file. In this example, the temporaryDatabaseServer option will use LocalDB by default. If you didn't install LocalDB on the build agent or you want to use a different temporary server, you'd need to specify it here. If you want to run full-text queries against your tables, you'll need to use a different temporary server because LocalDB doesn't support Full-Text Search. For example: <temporaryDatabaseServer>\SqlServer2012</temporaryDatabaseServer>. You'll also need to enter a username and password for the database. In Source Control Explorer, select the edited property files, right-click and select Check in Pending Changes. Configure the test properties file If you want to publish test results in MSTest format, you'll need to have Visual Studio Premium, Ultimate or Test Pro installed on the machine running your build agent. Test commands generate test data using SQL Data Generator and run tSQLt tests (such as static analysis, unit or integration tests) against a temporary version of your database. You'll use the WidgetTestData.sqlgen file extracted from the downloaded WidgetDevelopmentDatabaseCIDemo.zip file. For more information, see Test step command line options. The database schema for WidgetShopDevelopment includes four basic SQL Cop tests that will check for: procedures named SP_ procedures using dynamic SQL without sp_executesql procedures with @@Identity procedures with SET ROWCOUNT To configure the file: 1. Open $\WidgetShop\dlmAutomation-steps\DLMAutomation.test.properties. 2. Set the disabled option to False. For example, <disabled>False</disabled> 3. Set the generateTestData option to True. For example, <generateTestData>True</generateTestData> 4. At the dataGeneratorProjectFile option, enter the path to the SQL Data Generator file in source control relative to the project file. For example, <da taGeneratorProjectFile>.\WidgetShop\Database\WidgetTestData.sqlgen</dataGeneratorProjectFile> This will populate the temporary database with test data from the file. For more information about SQL Data Generator, see SQL Data Generator 3 documentation. 5. Press Ctrl+S to save the file. Again, the temporaryDatabaseServer option will use LocalDB by default. If you didn't install LocalDB on the build agent or you want to use a different temporary server, you need to specify it here. Test results are output in JUnit XML format and saved in the drop folder you specified when setting up your build definition. In Source Control Explorer, select the edited property files, right-click and select Check in Pending Changes.