1. Deployment Manager 1 documentation Requirements Getting started How Deployment Manager works

Size: px

Start display at page:

Download "1. Deployment Manager 1 documentation Requirements Getting started How Deployment Manager works"

Howard Burke
5 years ago
Views:

1 1. Deployment Manager 1 documentation Requirements Getting started How Deployment Manager works Installing and setting up Installing Deployment Manager Setting up environments Adding a target machine Licensing Upgrading Packages and package feeds Working with packages Creating and publishing application packages Working with package feeds Adding an API key for the Deployment Manager package feed Package version syntax The Visual Studio Deployment Manager Extension Installing the Deployment Manager Visual Studio Extension Using the Visual Studio Deployment Manager extension The SQL Server Management Studio Deployment Manager add-in Installing the SQL Server Management Studio add-in Using the SQL Server Management Studio Deployment Manager add-in Configuring deployments IIS websites PowerShell scripts Variables XML configuration files Deploying databases Working with database packages Creating and publishing database packages in SSMS Creating and publishing database packages using the command line Creating database packages in TeamCity Creating database packages with MSBuild Deploying database packages Worked example - setting up a database for deployment Automating Deployment Manager DeploymentManager.exe syntax Security Server and Agent communication Outbound requests Administrator privileges Finding your API key Troubleshooting Release notes and other versions Deployment Manager 1.x release notes Extending Deployment Manager to deploy SSAS databases

2 Deployment Manager 1 documentation About Deployment Manager With Deployment Manager, you can manage and automate software deployments into development, test, staging and production environments. Recent Deployment Manager updates Quick links New: Creating and publishing application packages Troubleshooting

3 Requirements Deployment Manager server The Deployment Manager server requires: Windows Server 2008, Windows Server 2008R2, Windows Server 2012, or Windows 7 Deployment Manager server is not supported on Windows Server 2003 but target machines are..net Framework 4.0 ( download the installer from Microsoft) Windows PowerShell 2.0 or later This is automatically installed on 2008 R2, but for 2008 pre-r2 you need to install it (x86 download, x64 download). Target machines Machines you want to deploy to require: Windows Server 2003 or later Windows Server 2003 servers require Windows Management Framework..NET Framework 4.0 ( download the framework installer from Microsoft) Windows PowerShell 2.0 or later This is automatically installed on 2008 R2, but for 2008 pre-r2 you need to install it (x86 download, x64 download).

4 Getting started With Deployment Manager, you can automate software deployments into development, test, staging and production environments. To get started, do the following: 1. Install the Deployment Manager server Download the Deployment Manager installer from the Red Gate website. On the server you want to use to host the Deployment Manager web interface, run the DeploymentManager.msi installer. Requirements For a list of software requirements for a Deployment Manager server, see Requirements. Follow the instructions to complete the installation. For more information, see Installing Deployment Manager. An administration tool is displayed when the installation is complete: In the administration tool, specify the port you want to use for the Deployment Manager web interface, and then click OK. The Deployment Manager web interface launches in your web browser. If you encounter a problem viewing the web interface, see Troubleshootin g. 2. Create an administrator user The first time you visit the web interface, you must create an administrator user account:

5 Enter details for the administrator, and click Create account. For a list of what administrator users can do, see Administrator privileges. 3. Add your target machines to the web interface Next, you need to add the machines you want to deploy to. In Deployment Manager, you add a machine to an environment. For example, this allows you to group several machines as Development, Staging or Production. For more information, see Setting up environments. To add an environment: 1. On the Environments tab, on the menu bar, click Add environment: 2. Enter a name for the environment, and click Create. To add a machine:

6 1. On the environment bar, click Add machine: You need to install the Agent service on the machines you want to deploy to before you can add them to Deployment Manager. Click Download agent installer. On the machine you want to deploy to, run the DeploymentAgent.msi installer, and follow the instructions to complete the installation. Requirements For a list of software requirements for a target machine, see Requirements. An administration tool is displayed when the installation is complete: In the Add machine dialog box, enter the name and URL of the machine you want to deploy to. In the Key box, paste the Agent key from the Agent administration tool:

7 6. In the Agent administration application, on the Security tab, under Server Keys, click Add:

8 7. In the Key box, paste the Deployment Manager server key:

9 8. Click Save.

10 4. Create deployment packages Next, you need to create and publish the packages you want to deploy. To deploy applications or databases using Deployment Manager, you need to create packages and publish them to a package feed. Deployment Manager package feed Deployment Manager can host packages in its own embedded package feed. The URL for the Deployment Manager package feed is < Deployment Manager server URL>/nuget/. For example: For information on how to create and publish packages, see: Creating and publishing application packages Creating and publishing database packages in SSMS 5. Create a project Once you've created and published the packages you want to deploy, you need to create a project. Projects contain the deployment steps you want Deployment Manager to perform. To create a new project: 1. On the Projects tab, click Create project: 2. Enter a name for the project, and click Add. To add deployment steps to a project: 1. In the Projects list, click your project: 2. On the Steps page, click Add package step:

Enter a version number for the release, select the version of the package you want to deploy, and then click Create

11 3. Specify the NuGet package you want to deploy, add the environments you want to deploy to, and then click Add. 6. Create and deploy a release Next, create a release: 1. On the Releases page, click Create release: 2. Enter a version number for the release, select the version of the package you want to deploy, and then click Create release.you can now deploy the release: 3. On the page for the release you want to deploy, on the menu bar, click Deploy this release:

Deployment Manager executes the deployment, and displays

12 4. Select the environment you want to deploy to, add any comments you want, and click Deploy release. Deployment Manager executes the deployment, and displays output logging information: You've now deployed your first release with Deployment Manager.

How Deployment Manager works Deployment Manager works by deploying packages from a feed to target machines. When you perform a deployment, Deployment Manager works through these steps: 1. 2. 3.

13 How Deployment Manager works Deployment Manager works by deploying packages from a feed to target machines. When you perform a deployment, Deployment Manager works through these steps: It gathers the packages to install from a package feed. It uploads them to the target machines they should be installed to. An Agent (a Windows service) on the remote machine installs them. When we say package, we really just mean a.zip file with a small manifest describing the contents. A package consists of all of the files needed by the application (for example, executables, DLLs, configuration files, CSS files, and so on). Deployment Manager uses the NuGet file format, created by Microsoft and used by Visual Studio. For more information on packages, see: Working with packages. The target machines are your web servers, application servers, database servers, and any other server on which you want to deploy your software. On them, you install a Windows service called the Agent. A Deployment Manager server can have many Agents. Communication between a Deployment Manager server and an Agent is always encrypted using a trust relationship based on public/private key cryptography. That makes it secure enough to use on production machines in the cloud or in remote data centers. In fact, machines don't even have to be on the same Active Directory domain - a common scenario is to run Deployment Manager on a local machine within your enterprise, but to have it deploying software to remote machines in the cloud. Bringing it all together is the Deployment Manager server, which consists of the web interface that users can use to configure their deployments, and a Windows service that co-ordinates the deployment process. Thus, the three main components that make up an Deployment Manager installation are: A central Deployment Manager server, with a web interface for configuring deployments. An Agent service, which runs on each of the machines you want to deploy software to. A package feed containing the packages (files) you want to deploy. Installing and setting up Deployment Manager Now that we have the background out of the way, let's install Deployment Manager. The steps are: Install the Deployment Manager server Add the environments you want to deploy to Add target machines to your environments Decide where to host your packages

14 Installing and setting up Installing Deployment Manager Setting up environments Adding a target machine

15 Installing Deployment Manager Your Deployment Manager server will host the web interface that you will use to configure deployments and trigger releases, as well as a Windows Service that coordinates releases. Requirements For a list of software requirements for a Deployment Manager server, see Requirements. Video tutorial Click for a video on how to install Deployment Manager Automatically installed requirements During the Deployment Manager installation, the following will be installed automatically: ASP.NET 4 IIS, with the following features: Installation Web Management Tools: IIS Management Console IIS Management Scripts and Tools World Wide Web Services > Application Development Features: ASP.NET.NET Extensibility World Wide Web Services > Common HTTP Features: Static Content Default Document HTTP Errors HTTP RedirectionWorld Wide Web Services > Security: Windows Authentication Download the Deployment Manager MSI. Install the MSI, following the instructions. An administration tool is displayed when the installation is complete:

3. Specify the port you want to use for the Deployment Manager web interface, and click OK. The Deployment Manager web interface is launched in your web browser.

16 3. Specify the port you want to use for the Deployment Manager web interface, and click OK. The Deployment Manager web interface is launched in your web browser. You can find the URL for the web interface at any time in the administration tool: Creating an administrator account The first user that visits the web interface will automatically be prompted to create an administrator account:

17 Enter details for the administrator, and click Create account. Configuring backups By default, Deployment Manager will automatically back up its own database every four hours into the data repository location you chose during installation. By default, the data repository is located at: C:\ProgramData\Red Gate\DeploymentManager\Data\ To change Deployment Manager backup settings: 1. In the web interface, on the Settings page, click Data Repository backups:

18 2. Click Change backup settings: 3. Make any changes, and then click Save. Common errors For a list of common Deployment Manager errors, see Troubleshooting.

Setting up environments In Deployment Manager, you add your target machines to an environment. Environments group related machines together (as Development, Stag ing, or Production, for example ).

19 Setting up environments In Deployment Manager, you add your target machines to an environment. Environments group related machines together (as Development, Stag ing, or Production, for example ). Adding an environment To add a new environment to Deployment Manager: In the web interface, click Environments. Click Add environment: The Add environment dialog box is displayed: 3. In the Name box, type a name for the new environment. You can optionally type a short description of the environment in the Description box, for example:

20 You can format your description using Markdown syntax. Descriptions are displayed under the environment name in the Environments tab: 4. Click Create. Adding machines to an environment See Adding a target machine. Re-ordering environments To change the order your environments are listed in the web interface: 1. On the Environments tab, click Re-order:

21 2. Click and drag the environments into the order you want: 3. Click Save: Deleting an environment To delete an environment: 1. On the Environments tab, on the environment you want to delete, click Edit: 2. Click Delete:

22 Deleting an environment also deletes any target machines in it from Deployment Manager. 3. On the confirmation dialog box, click OK.

Video tutorial Click for a video on how to add a target machine To add a target machine to Deployment Manager: 1. 2.

23 Adding a target machine To deploy software with Deployment Manager, you need to add target machines to the Deployment Manager web interface. A target machine is any computer that you want to deploy to. Requirements For a list of software requirements for a target machine, see Requirements. Video tutorial Click for a video on how to add a target machine To add a target machine to Deployment Manager: On the machine you want to deploy to, browse to the Deployment Manager web interface. In the Environments tab, in the environment you want to add the machine to, click Add machine: Installing the Agent service Next, you need to install the Deployment Agent service on your target machine: 1. In the Add machine dialog box, click Download agent installer: 2. Run the DeploymentAgent.msi installer, following the instructions. An administration tool is displayed when the installation is complete:

Linking a target machine to Deployment Manager Once you have installed the Agent service on your target machine, you need to link the machine to Deployment Manager: 1.

24 Linking a target machine to Deployment Manager Once you have installed the Agent service on your target machine, you need to link the machine to Deployment Manager: 1. In the Deployment Agent administration tool, on the Security tab, copy the Agent key: 2. In a web browser, navigate to the Deployment Manager web interface, and click the Environments tab:

On the environment menu bar, click Add machine: The Add machine dialog box is displayed: 6. 7. 8.

25 3. To create an environment to add the Agent to, in the Deployment Manager menu bar, click Add environment: 4. Specify a name for the environment, and click Create.In the example below, we have created a Staging environment: 5. On the environment menu bar, click Add machine: The Add machine dialog box is displayed: On the Add machine dialog box, specify a name and the URL for the target machine. In the Agent Key box, paste the Agent key you copied from the Deployment Agent administration tool. At the bottom of the dialog box, copy the Deployment Manager server key:

9. 10. Click Create. The target machine is added to the web interface.

11. In the Add Trusted Deployment Manager dialog box, paste the server key you copied from the

26 Click Create. The target machine is added to the web interface. In the Deployment Agent administration tool, on the Security tab, under Server Keys, click Add: 11. In the Add Trusted Deployment Manager dialog box, paste the server key you copied from the web interface, and click. Save A trust relationship between the target machine and the Deployment Manager server is now set up.

27 Licensing When you buy a Deployment Manager license, you will receive an invoice that contains your serial number to activate the product. Your invoice shows how many instances of a product the serial number can be used to activate. For information on how to activate, see Activating Deployment Manager serial numbers. Finding your serial number If you can't find your invoice, you can view your serial numbers at You will need to enter the address and password you provided when you bought the product. If you need to reinstall Deployment Manager on the same computer, for example following installation of a new operating system, you can reactivate using the same serial number. This does not affect the number of distinct activations for the serial number. For information on moving a serial number to a different computer, see Moving a serial number to a different computer. Activating Deployment Manager serial numbers Deployment Manager is licensed per machine you deploy to. You do not need to license the Deployment Manager web interface or the Deployment Manager server. To activate and deactivate serial numbers, and to see the licensing status of your machines, navigate to the Licensing page: 1. In the web interface, on the menu bar, click Settings: You must be an administrator to view Deployment Manager settings. 2. In the Settings list, click Licensing:

28 How licenses are allocated Machines are allocated licenses in the order they were added to Deployment Manager. For example, if you add webserver01 and then webserver02, and then activate a serial number for one license, only webserver01 will be licensed. Licensing an unlicensed machine To license a machine that has not been allocated a license automatically, you must either: 1. activate another serial number to get more licenses delete one or more of your licensed machines from the web interface To delete a machine from the web interface: On the Environments page, move the cursor over the machine you want to delete, and click Edit: 2. On the Edit machine dialog box, click Delete. Spare licenses As you add new machines to Deployment Manager, any spare licenses will be automatically allocated to the new machines, up to the maximum number of licenses you have. Moving a serial number to a different computer To move a serial number to a different machine, deactivate the serial number on the old computer, then use it to activate the product on the new computer. To deactivate a serial number: On the Deployment Manager Licensing page, for the serial number you want to deactivate, click Deactivate:

Upgrading To upgrade to a new release of Deployment Manager, you need to: 1. 2. 3.

Upgrading the Deployment Manager server Backing up the Deployment Manager database We recommend you back up the Deployment Manager database before

30 Upgrading To upgrade to a new release of Deployment Manager, you need to: Upgrade the Deployment Manager server Perform a health check Upgrade your target machines 1. Upgrading the Deployment Manager server Backing up the Deployment Manager database We recommend you back up the Deployment Manager database before upgrading: 1. In the Deployment Manager web interface, in Settings, click Data Repository backups: 2. Click Backup the database. To upgrade the Deployment Manager server: 1. n the Deployment Manager web interface, on the menu bar, click Upgrade: 2. On the Updates page, click Install now:

Click the Environments tab. Click Check health: 3.

31 Deployment Manager installs the update. 2. Performing a Health Check Once Deployment Manager has successfully installed the update, you need to perform a health check: Click the Environments tab. Click Check health: 3. Deployment Manager will connect to every target machine and check which version of the Agent service it is running. Once the health check is complete, go back to the Environments tab. Any machines that need to be upgraded will be highlighted: 3. Upgrading target machines If any machines require upgrading, on the Environments tab, click Upgrade all:

32 Deployment Manager upgrades the Agent service on all your target machines. After the upgrade completes, you can perform another health check to make sure all your target machines have been upgraded.

33 Packages and package feeds Working with packages Creating and publishing application packages Working with package feeds Adding an API key for the Deployment Manager package feed Package version syntax

34 Working with packages To deploy applications using Deployment Manager, you need to create packages and publish them to a package feed. Deployment Manager deploys NuGet (.nupkg) packages, a ZIP-based file format. For more information, see NuGet Overview (NuGet documentation). What packages should contain An application package should contain all of the executables, DLLs, configuration files, installation scripts, and anything else the application needs to run. Note NuGet encourages you to put compiled binaries into a lib folder, scripts into a tools folder, and everything else into a content fol der. However, Deployment Manager packages should look exactly as you want the files to be extracted on disk. For example: NuGet packages can't have dependencies. Any libraries you need to use must be included in the standard binaries folder of your package:

PowerShell Deployment Manager automatically replaces appsettings and connectionstrings, runs XML config transforms, and updates IIS websites during deployment.

35 PowerShell Deployment Manager automatically replaces appsettings and connectionstrings, runs XML config transforms, and updates IIS websites during deployment. If you want Deployment Manager to perform further deployment actions, you can include PowerShell scripts in your package. Creating and publishing packages For information on how to create and publish application packages, see Creating and publishing application packages. Database packages For information on how to create and deploy database packages, see Working with database packages.

36 Creating and publishing application packages To create application packages and publish them to a package feed, you can use the RgPublish.exe command line interface. Databases For information about creating database packages, see Creating and publishing database packages. To download RgPublish.exe: 1. In the web interface footer, click Deployment Manager tools: 2. Under RgPublish.exe, click Download: If you installed Deployment Manager to the default location, you can find RgPublish.exe in: C:\Program Files (x86)\red Gate\Deployment Manager\Tools.NET Framework 4.0 Machines running RgPublish.exe require Microsoft.NET Framework 4.0. You can download the framework here. Example: packaging and publishing a directory In the following example: the required files for the application we want to package are in C:\Source Code\My Web App\ For information about what packages should contain, and how to structure the directory you want to publish, see Working with packages. we want to publish to our Deployment Manager package feed at To publish the directory, at the command prompt, we navigate to the location of RgPublish.exe and run: RgPublish /source="c:\source Code\My Web App" /version=1.0 /packageid=mywebapp /target=feed: This creates a package MyWebApp-1.0.nupkg, and pushes it to the package feed. You can now use Deployment Manager to deploy this package. Example: packaging and publishing from a.nuspec file In the following example: the package.nuspec file describes the package we want to create Click to view the.nuspec file used in this example

37 package.nuspec <?xml version="1.0"?> <package xmlns=" <metadata> <id>widget_shop</id> <version>1.0.0</version> <authors>red Gate</authors> <description>web interface</description> </metadata> <files> <file src="bin\debug\*.dll" target="lib" /> </files> </package> For information about.nuspec files, see Nuspec reference (NuGet documentation) the file paths defined in package.nuspec are relative to the base directory C:/Source Code/ we want to publish to a package feed at using the feed API key apikey1 To publish the package, at the command prompt, we navigate to the location of RgPublish.exe and run: RgPublish /source="c:\source Code\My Web App\package.nuspec" /basedir="c:\source Code" /target=feed: /apikey=apikey1 This creates a package Widget_Shop nupkg, and pushes it to the package feed. You can now use Deployment Manager to deploy this package. Syntax Source /source=<path> Alias: /s Path to a directory to publish, or a.nuspec file. For example: /source="c:\my Project" or /source="c:\my Project\packages.nuspec" Package details You can specify details of the package using the following commands: /packageid=<package name> Alias: /id Name of the package. For example:

38 /packageid=widget_shop If you don t specify /packageid (or <id> in a.nuspec file), the directory name is used as the package name. /version=<version number> Alias: /v or /packageversion Version number for the package. For example: /version=1.0 /description=<description> A description of the package contents. For example: /description="web interface" If you don t specify /description (or <description> in a.nuspec file), Published by Red Gate Publishing Tool is used as the description. /author=<author name> Author of the package. For example: /author=redgate If you don t specify /author (or <authors> in a.nuspec file), the current Windows user is used as the author name. /basedir=<directory path> Base directory where files defined in a.nuspec file are located (the directory against which paths in <files> are resolved). For example: /basedir="c:\source Code" If the source is a.nuspec file and you don t specify /basedir, the directory where the.nuspec file is located is used as the base directory. Publishing to a directory By default, packages are published to the working directory. You publish the package to a different directory using the following commands: /target=<directory path> Alias: /t Path to a directory to publish to. For example: /target=c:\packages /overwrite Overwrites an existing package with the same name and version number.

39 If a package with the same name and version as you want to publish exists in the target directory and you don't specify, /overwrite package publishing will fail. Publishing to a package feed You can publish the package to a package feed using the following commands: /target=feed:<package feed URL> Alias: /t URL of a package feed to publish to. For example: /target=feed: If you publish to a package feed that requires an API key, specify: /apikey=<feed API key> API key for the package feed to publish to. For example: /apikey=apikey1

40 Working with package feeds A package feed is a location you use to host packages you want to deploy with Deployment Manager. When you set up Deployment Manager, you need to choose the feed(s) you want to use to host your packages. You can: use the Deployment Manager package feed set up and use your own package feed use an existing NuGet feed You can use as many package feeds as you want with Deployment Manager. Using the Deployment Manager package feed Deployment Manager can host packages in its own embedded package feed. This feed is useful if you don't have an existing feed and you don't want to set one up. You can enable the Deployment Manager package feed in the Deployment Manager administration tool: The URL for the Deployment Manager package feed is <Deployment Manager server URL>/nuget/. For example: NuGet feeds can be set up to require an API key (a password), to only allow users who know the key to push to the feed. By default, an API key is not required when you push packages to the Deployment Manager package feed. To add an API key, see Adding an API key for the Deployment Manager package feed. Removing the Deployment Manager package feed To remove the Deployment Manager package feed: In the Deployment Manager web interface, under Settings, click Package feeds. In the row for the Deployment Manager package feed, click Delete:

41 3. In the Deployment Manager administration application, clear the Enable the Deployment Manager package feed check box. This does not permanently delete the package feed. You can use the feed again if you select the check box in the administration application and add the feed back to Deployment Manager. Deleting packages from the Deployment Manager package feed To delete packages you've published to the Deployment Manager package feed: 1. On your Deployment Manager server, in Windows Explorer, navigate to the Deployment Manager data repository. By default, the data repository is located at: C:\ProgramData\Red Gate\DeploymentManager\Data\ 2. Open the feed folder. Packages published the Deployment Manager feed are listed. 3. Delete the packages you want to remove from the feed. Setting up your own package feed If you want to host your own NuGet package feed, you can set up: a remote feed available over HTTP See Creating remote feeds (NuGet documentation). a local feed available as a file share or local directory See Creating local feeds (NuGet documentation). a TeamCity server (version 7 and above) See Using TeamCity as a NuGet server (TeamCity documentation). To use your own package feed with Deployment Manager, you need to add the feed to Deployment Manager using the web interface. Adding a package feed to Deployment Manager To add a package feed: 1. In the Deployment Manager web interface, click Settings. You must be an administrator to view Deployment Manager settings. 2. Click Package feeds:

42 3. Click Add package feed: Specify a name and URL for the package feed and, if required, authentication details. Click Add.

43 Adding an API key for the Deployment Manager package feed By default, the embedded Deployment Manager package feed does not require an API Key. If you want to control who can push packages to the feed, you can add an API key: 1. On the computer where you installed the Deployment Manager server, go to the installation location. By default, this is: C:\Program Files (x86)\red Gate\Deployment Manager 2. Open the NuGet folder, and then open the web.config file in a text editor. 3. Under <appsettings>, change the key="requireapikey" value to "true". 4. For key="apikey", specify the value you want to use as the API key (password) for the feed. 5. Save your changes to web.config. The API key you specified will now be required when any user wants to push packages to the Deployment Manager feed.

44 Package version syntax Packages published to Deployment Manager's package feed or your own NuGet feed must have a version number. Valid version formats The formats allowed for the versions are numbers with 1, 2 or 3 decimal points. A version can also have a text suffix after a hyphen. This can be any text string. Format With suffix Examples a.b a.b-suffix 4.2, 1.7-alpha a.b.c a.b.c-suffix 1.1.5, testing a.b.c.d a.b.c.d-suffix , pre-release Publishing from Visual Studio or SQL Server Management Studio If you use the SQL Server Management Studio add-in or the Visual Studio extension to publish packages, the least significant number is automatically incremented each time. Publishing with continuous integration If you use the continuous integration build scripts, the build number can be passed to the script using a variable. If you're using a continuous integration bulid script, you need to make sure the format of your build number is a valid format for the package version. Learn more The version syntax is identical to NuGet's. For more information, see Versioning (NuGet documentation).

45 The Visual Studio Deployment Manager Extension Red Gate provide a free extension for Visual Studio 2012 which simplifies packaging of web applications. With the Extension, you can publish an application to Deployment Manager using the context menu in Visual Studio. Installing the Deployment Manager Visual Studio Extension Using the Visual Studio Deployment Manager extension

Installing the Deployment Manager Visual Studio Extension Download from the Visual Studio Gallery 1. 2. 3. Visit the Publish to Deployment Manager page on the Visual Studio Gallery.

46 Installing the Deployment Manager Visual Studio Extension Download from the Visual Studio Gallery Visit the Publish to Deployment Manager page on the Visual Studio Gallery. Click Download to get the RedGate.Deploy.VsExtension.Vsix file. Double-click the file. The VSIX Installer dialog is displayed: Click Install. The Installation Complete page is displayed Click Close. The Extension is now installed in Visual Studio 2012.

47 Using the Visual Studio Deployment Manager extension With the Visual Studio Deployment Manager extension, you can publish a web application directly to Deployment Manager from Visual Studio: Open your web project solution in Visual Studio. In Solution Explorer, right-click on a project in your solution. The context menu is displayed: You can also access this option from the Build menu in the Visual Studio title bar. 3. Click Publish for deployment. The Deployment Manager Details page of the wizard is displayed:

48 Type or paste your Deployment Manager server URL into the Deployment Manager URL box. Copy your API key from your user profile in Deployment Manager and paste it in to the API Key box. Click Next. The Package Details page is displayed:

49 7. 8. Type a name for the package or accept the default. Type a package version or accept the default. The extension automatically increments the least significant number of the version each time you publish Select a package feed from the Package feed to publish to box. For more information on package feeds, see Working with package feeds. Click Publish. The package is published and the Publish Application Package page is displayed:

50 11. Click Finish.

51 The SQL Server Management Studio Deployment Manager add-in Red Gate provide a free add-in for SQL Server Management Studio which simplifies packaging of databases. With the add-in you can publish an application to Deployment Manager using the context menu in SQL Server Management Studio Installing the SQL Server Management Studio add-in Using the SQL Server Management Studio Deployment Manager add-in

Installing the SQL Server Management Studio add-in Download from your Deployment Manager Server 1. 2. 3. 4. 5.

52 Installing the SQL Server Management Studio add-in Download from your Deployment Manager Server In the Deployment Manager web interface, click the Under SQL Server Management Studio add-in, click Download. Save the DeploymentManagerSSMSaddin.exe file. Double-click the file to run it. If a UAC prompt appears, click Yes. The Selecting the tools to install page is displayed: link in the bottom right corner. 6. Click Next. The License agreement page is displayed. 7. Click Next to accept the license. The Customizing the installation folder page is displayed:

53 Accept the default path or browse for a custom one. Click Install. The add-in is installed. Click Close.

54 Using the SQL Server Management Studio Deployment Manager add-in With the Visual Studio Deployment Manager Extension, you can publish a web application directly to Deployment Manager from Visual Studio: Open your web project solution in Visual Studio. In Solution Explorer, right click on the root of your solution. The context menu is displayed: 3. You can also access this option from the Build menu in the Visual Studio title bar. Click Publish for deployment... The Deployment Manager Details page of the wizard is displayed:

55 Type or paste your Deployment Manager server URL into the Deployment Manager URL field. Copy your API key from your user profile on Deployment Manager and paste it in to the API field. Click Next. The Package Details page is displayed:

56 7. 8. Type a name for the package or accept the default. Type a package version or accept the default The plugin automatically increments the least significant number of the version each time you publish. Select the Package feed to publish to from the drop-down Click Publish. The package is published and the Publish Application Package page is displayed:

57 11. Click Finish.

58 Configuring deployments IIS websites PowerShell scripts Variables XML configuration files

59 IIS websites If you are deploying an ASP.NET web application, Deployment Manager configure IIS for you. Deployment Manager can configure IIS 6, 7 and 7.5. Deployment Manager only supports basic IIS conguration. If your deployment needs to be more complicated (for example, creating web sites on the fly), you will need to use the PowerShell script support in conjunction with the Windows IIS 7 PowerShell modules. Changing the home directory If your NuGet package contains a web.config file, Deployment Manager will assume it is a web site, and will attempt to configure IIS for you. For example, before deployment, your IIS site might have pointed to: C:\Apps\Production\Acme.WebStore\1.0.0 After extracting and deploying version 2.0 of the package, the site's Home Directory will point to: C:\Apps\Production\Acme.WebStore\2.0.0 This change will cause IIS to start serving requests from the new location. If there is a problem, you can manually revert the IIS website to point to the old package, or re-deploy the old release with Deployment Manager. Variables If you want to override the IIS site name, specify a virtual directory, or customize the site/virtual directory used by the IIS convention, you can use the RedGateWebSiteName variable. If you don't specify the variable, the package name is used as the site name. If you want Deployment Manager to create a new IIS website for you, you can specify a port number for the site using the RedGateCreateWebS iteonport variable. For information on variables, see Variables.

60 PowerShell scripts As a convention-oriented deployment tool, Deployment Manager automatically takes care of replacing appsettings and connectionstrings, running XML config transforms, and updating IIS websites. Sometimes however you'll need to do more than this - and that's where PowerShell scripts come in. Scripts At the root of your NuGet package, you can add any of the following files: PreDeploy.ps1 Deploy.ps1 PostDeploy.ps1 After extracting your package, the Agent will detect these scripts and invoke them in a custom PowerShell host on the target machine. If your package contains multiple PreDeploy.ps1, Deploy.ps1, or PostDeploy.ps1 scripts, they will all be run during deployment. After deployment is complete, any extracted PowerShell scripts will be deleted from the target machine. Variables Deployment Manager allows you to define variables to parameterize your deployments. These variables, along with some predefined variables, will be available from within your PowerShell script. For example, a variable named MyApp.ConnectionString will be available as either: $MyAppConnectionString $Deployment ManagerParameters"MyApp.ConnectionString" The first form is not case-sensitive, while the second form is case-sensitive. Also, in the first form, special characters are removed, while in the second they appear just as they appear in the Deployment Manager web interface. Output When invoking a command in your PowerShell scripts, you'll need to pipe output to the Write-Host command. For example, this script will not show any output in the Deployment Manager deployment log: Get-ChildItem While this script will show output: Get-ChildItem Write-Host The same goes for invoking an external executable. For example: & "MyProgram.exe" "-arg1" "-arg2" Write-Host Examples This script uses the Service Control tool ( sc.exe) to create or update a Windows Service. It assumes some variables have been set in the Deployment Manager web interface:

61 # These variables should be set via the Deployment Manager web interface: # # ServiceName - Name of the Windows service # ServiceExecutable - Path to the.exe containing the service # # sc.exe is the Service Control utility in Windows $service = Get-Service $ServiceName -ErrorAction SilentlyContinue $fullpath = Resolve-Path $ServiceExecutable if (! $service) { Write-Host "The service will be installed" New-Service -Name $ServiceName -BinaryPathName $fullpath -StartupType Automatic } else { Write-Host "The service will be stopped and reconfigured" Stop-Service $ServiceName -Force & "sc.exe" config $service.name binpath= $fullpath start= auto Write-Host } Write-Host "Starting the service" Start-Service $ServiceName This script uses InstallUtil.exe to install custom Event Log sources and Windows Services: $NetFrameworkDirectory = $(System.Runtime.InteropServices.RuntimeEnvironment::GetRuntimeDirectory()) & (Join-Path $NetFrameworkDirectory "InstallUtil.exe") "path\to\my.dll" Write-Host Security One of the first commands performed by Agent's custom PowerShell host is to automatically set the execution policy to bypass. This means that PowerShell's inbuilt security measures, such as blocking execution of external scripts, will not apply. This also means there is no need to change the default system-wide execution policy when using Agent for deployment. Also, keep in mind that scripts are executed in the context of the account that the Agent Windows Service runs as. By default this is Local System, which has extensive local privileges, but usually cannot access file shares, remote SQL databases, or other external resources. If you need wider permissions, you'll need to configure Agent to run under a custom service account.

62 Variables As you promote your application through test, UAT, staging and production, there are going to be differences in: Database connection strings Application settings Web service URLs Many other parameters To make it easy to support different environments without hard-coding these configuration values, the Deployment Manager web interface allows you to create variables. These variables are used during your application deployment. For example, variables you define will be automatically substituted into XML configuration files, and made available to your PowerShell scripts. This allows you to create applications and deployment scripts that are agnostic of the target environment. Escaping The value of a variable should be the unescaped version. Quotes and other characters that would normally need to be escaped in XML should not be escaped in the Deployment Manager web interface. This is because they will be escaped when injected, and doing so could result in double escaping. Scoping A variable can be 'scoped' to zero or one of each of the following: An environment (most common) A specific machine A specific package For example, suppose these variables exist: Name Value Environment Machine Package LogLevel Info LogLevel Warn Production DBConnectionString Server=SQL-UAT1;Database=... UAT DBConnectionString Server=SQL-PROD;Database=... Production During deployment, Deployment Manager will try to select the most specifically scoped variable that applies. For example, when deploying to Production, the LogLevel property would be Warn. But to any other environment, it would fall back to the less-specific variable and have a value of Info instead. Predefined variables Deployment Manager automatically makes a number of common useful variables available during each deployment. All predefined variables have a Deployment Manager prefix. The available predefined variables are: Name Example Description RedGateEnvironmentName Production The name of the environment that was selected when this deployment was scheduled. RedGateMachineName ProdServer01 The name assigned to the machine in the Deployment Manager Environments page in the web interface. May or may not be the hostname of the actual machine. RedGateReleaseNumber 1.9 The release number entered when this release was created in the Deployment Manager web interface. RedGatePackageName AcmeCorp.Web The name of the NuGet package being deployed. RedGatePackageVersion The version number of the NuGet package. RedGatePackageNameAndVersion AcmeCorp.Web The above two values combined. RedGateProjectName ACME Website The name of the current project, as defined in the Deployment Manager web interface.

63 RedGateTaskId 157 An integer used to identity the current task in Deployment Manager. You can use this if you need to record something unique about each deployment. The following additional variables don't have a default value, but can be set by you to override Deployment Manager behavior: Name Example Description RedGatePackageDirectoryPath C:\MyApp A custom path that you can tell an Agent to extract your package to. If not set, it will have the value that an Agent extracted the NuGet package to. RedGatePurgePackageDirectoryBeforeCopy False If using RedGatePackageDirectoryPath, set this variable to 'True' to clean the target directory before copying. RedGateWebSiteName MySite or: MySite/MyVDir Override the IIS site, or use a forward slash to specify a virtual directory, if you want to customize the site/virtual directory used by the IIS convention. RedGateNotAWebSite True Set to True to tell an Agent to skip the IIS convention (i.e., don't configure any IIS sites). RedGateCreateWebSiteOnPort 8080 The port number to use when creating a new IIS website. Database variables When you are deploying databases, you can specify the following variables: Name Example value Description databaseserver localhost The database server you want to deploy to. databasename WidgetShopStaging The database you want to deploy to. databaseintegratedauthentication True If you want to use SQL Server authentication to connect to the SQL Server, specify the value True. If you use SQL Server authentication, you do not need to specify a username and password. databaseusername user The username for the database you want to deploy to. databasepassword password The password for the database you want to deploy to. mode upgrade or createnew The type of upgrade you want Deployment Manager to perform. You can specify either upgrade if you want to upgrade the database, or createnew if you want to drop and recreate the database. allowdynamicdatabaseupgrade True If you want Deployment Manager to perform a dynamic database upgrade, specify True. See: How Deployment Manager upgrades databases. allowpredeploydatabasevalidation True If you want Deployment Manager to validate the upgrade before deployment, specify True. See: Deployment validation. allowpostdeploydatabasevalidation True If you want Deployment Manager to validate the upgrade after deployment, specify True. See: Deployment validation. abortonhighseveritywarnings True If you want Deployment Manager to cancel a deployment if there are any serious deployment warnings, specify True. For more information, see: Deploying database packages.

64 XML configuration files One of the essential steps in deploying software is configuring it to work in a specific environment. This might mean pointing your application to the right database connection string, or tweaking settings to run in production. Deployment Manager does two things to make configuring your application easy: Automatically updating appsettings and connectionstrings Executing configuration file transformations App Settings and Connection Strings If a variable is defined in the Deployment Manager web interface, and an appsettings or connectionstring record exists for it in any of your.config files, the Agent will automatically replace the value after extracting your package. For example, suppose you have this configuration file: <configuration> <appsettings> <add key="awsaccesskey" value="testkey"/> <add key="awssecretkey" value="testsecret"/> </appsettings> <connectionstrings> <add name="dbconnectionstring" value="server=(local)\sqlexpress;database=onlinestore;integrated Security=SSPI" /> </connectionstrings> </configuration> And you have these variables defined in your Deployment Manager web interface: After deploying to an environment named Production, Deployment Manager will have updated the file to: <configuration> <appsettings> <add key="awsaccesskey" value="akiaixu765wqyxisjdk"/> <add key="awssecretkey" value="mfowqdsjwi8jdyc/6ymoahafz8jbybl9akscoslb"/> </appsettings> <connectionstrings> <add name="dbconnectionstring" value="server=sqlprod01;database=onlinestore;integrated Security=SSPI" /> </connectionstrings> </configuration> This only works for appsettings and connectionstrings elements.

65 Configuration File Transformations After deployment, Deployment Manager will also look for any files that follow the Microsoft web.config transformation process not web.config files (for example, YourService.exe.config). even files that are The configuration transformation files can either be named *.Release.config, or *.<Environment>.config. For example, suppose you have the following files in your package: Web.config Web.Release.config Web.Production.config Web.Test.config When deploying to an environment named Production, Deployment Manager will execute Web.Release.config, followed by Web.Productio n.config. An example web.config transformation that removes the <compilation debug="true"> attribute is below: <?xml version="1.0"?> <configuration xmlns:xdt=" <system.web> <compilation xdt:transform="removeattributes(debug)" /> </system.web> </configuration> The team at AppHarbor created a useful tool to help test configuration file transformations. PowerShell If these conventions aren't enough to configure your application, you can always use PowerShell to perform custom configuration tasks. Variables will be passed to your PowerShell script, and PowerShell has rich XML APIs.

66 Deploying databases Working with database packages Creating and publishing database packages in SSMS Creating and publishing database packages using the command line Creating database packages in TeamCity Creating database packages with MSBuild Deploying database packages Worked example - setting up a database for deployment

67 Working with database packages You can deploy SQL Server databases with Deployment Manager using database packages. This article describes: What database packages contain How Deployment Manager upgrades databases Deployment validation Extended properties Creating database packages Deploying database packages What database packages contain Database packages contain database object creation scripts representing the state of a database (including any static data). Packages can also contain: Upgrade scripts to upgrade a database from previous versions you have deployed with Deployment Manager Creation scripts to create a database HTML documentation of the database How Deployment Manager upgrades databases Deployment Manager upgrades a database in one of two ways: Dynamic upgrade (using SQL Compare during deployment) If you deploy a database package that does not contain a relevant upgrade script, Deployment Manager upgrades the database automatically, using the SQL Compare engine. Dynamic upgrades are useful when you are deploying to development or testing environments. Static upgrade (using an upgrade script) If you deploy a database package that contains a relevant upgrade script, Deployment Manager runs the script to upgrade the database. Static upgrades are useful when you are deploying to staging or production environments, because a build can validate the deployment and report any errors in the build log. Deployment validation Deployment Manager can validate a deployment by checking that the state of the database you are deploying to is identical to the state of the database in the package. There are two types of validation: Pre-deployment validation Deployment Manager validates the deployment before it is performed. Pre-deployment validation is useful because it can detect database drift. Database drift occurs when changes are made to the database outside of a Deployment Manager deployment. If Deployment Manager performs a dynamic upgrade, these changes will be lost. If Deployment Manager performs a static upgrade, there may be errors when the upgrade script is executed. If database drift is detected, the validation fails. The database is not updated, and the next deployment steps are not performed. Post-deployment validation Deployment Manager validates the deployment after it has been performed. Post-deployment validation is useful because it can confirm that the deployment was successful. The validation will also detect any changes made to the database schema or static data outside of the Deployment Manager deployment (if a DDL or DML trigger ran during the deployment, for example). If the deployment was not successful, or any unexpected changes are detected, the validation fails. The database has been updated, but the next deployment steps are not performed. Extended properties When you first deploy a database with Deployment Manager, two extended properties are added to the database: DeploymentManager Deployed Package ID The name, or ID, of the database package. DeploymentManager Deployed Package Version The version number of the database package. Deployment Manager uses these extended properties in future pre-deployment validations and static upgrades. In future pre-deployment validations, the extended properties will be used to ensure that the database is validated against the correct package version. In future static upgrades, the extended properties will be used to ensure that the correct upgrade script is used during the deployment.

68 The extended properties are updated automatically with each deployment. You cannot deploy SQL Azure databases with Deployment Manager because SQL Azure does not support extended properties. Creating and publishing database packages You can create and publish database packages from SQL Server Management Studio (SSMS) using the Deployment Manager add-in. For information, see: Creating and publishing database packages in SSMS If you are using TeamCity as your continuous integration server, see: Creating database packages in TeamCity If you are not using TeamCity, you can automate the creation of database packages with MSBuild: Creating database packages with MSBuild Deploying database packages To deploy database packages with Deployment Manager, you need to specify some variables in your project. For details, see: Deploying database packages

Creating and publishing database packages in SSMS You can use the Deployment Manager SQL Server Management Studio (SSMS) add-in to create and publish database packages.

69 Creating and publishing database packages in SSMS You can use the Deployment Manager SQL Server Management Studio (SSMS) add-in to create and publish database packages. You can then use Deployment Manager to deploy database packages to target SQL servers. For information on database packages, see Working with database packages. Installing the add-in Download the add-in installer. Run the installer and follow the instructions. Once the installation is complete, the add-in is available in SSMS. Publishing a database package In the SSMS Object Explorer, right-click the database you want to package, and click Publish <database name> for deployment: On the Deployment Manager Details page, specify the URL for your Deployment Manager server (the URL you use to view the web interface, for example and the API key for your user account: Click Next. On the Package Details page, specify a name and version number for the package you want to create:

5. Under Package feed to publish to, specify the feed you want to publish the package to. You can select from the list of feeds that have been added to Deployment Manager. 6.

70 5. Under Package feed to publish to, specify the feed you want to publish the package to. You can select from the list of feeds that have been added to Deployment Manager. 6. For more information, see Working with package feeds. Click Publish. When the package has been successfully published, the SQLCompare.exe and sqlci.exe commands used to publish the package are displayed:

You can use these commands as a starting point if you want to automate creating and publishing packages. For more information, see: Switches used in the SQL Compare command line Using the sqlci.

71 You can use these commands as a starting point if you want to automate creating and publishing packages. For more information, see: Switches used in the SQL Compare command line Using the sqlci.exe command line Deploying a package with Deployment Manager Now that you ve published a database package, you can deploy it using the Deployment Manager web interface or command line. More information on deploying database packages.

72 Creating and publishing database packages using the command line You can use the SQLCompare.exe and sqlci.exe command lines to create and publish database packages. You can then use Deployment Manager to deploy database packages to target SQL servers. Requirements You will need: A copy of the SQL Automation License. To install this: 1. Go to the Free Resources page and click Download Build scripts (beta). 2. Save sqlci.zip on your machine. 3. Unzip the contents of sqlci.zip to a folder. 4. Optionally, license sqlci.exe by running: sqlci.exe --licenseserialkey=[automation license serial number] If you don't license sqlci.exe, it'll start a 2 week trial. Access to a SQL server A database on the server to package Create a scripts folder with SQLCompare.exe To create a temporary scripts folder of your target database, use the SQL Compare command line: Open a command prompt. Change the working folder to the unzipped sqlci folder. Run the following command: SC\SQLCompare.exe /server1:[server] /database1:[database] /makescripts:temporary_folder Where: [server] is your target database server [database] is the name of the database you want to package and publish This creates a scripts folder of the database in a folder called temporary_folder. For more information, see Switches used in the SQL Compare command line. Publish the package with sqlci.exe To package and publish the database to Deployment Manager, run the following sqlci.exe command: sqlci.exe --scriptsfolder=temporary_folder --packageid=[package name] --packageversion=[version number] --packagerepository=[package repository] --apikeyforpackagepublish=[dm API key] --generatecreationscript Where: --scriptsfolder=temporary_folder tells sqlci.exe to use the scripts folder as the target to package. [package name] is what you want to name the package. Often the name of the database [version number] is the version number of the package that will appear in Deployment Manager [package repository] is the address of your NuGet package repository. Usually, this is your Deployment Manager URL with /nuget appended to it [DM API key] is the API key for your Deployment Manager server if it requires one. Otherwise this can be left blank --generatecreationscript generates a SQL creation script This will package and publish the scripts folder that you created with SQLCompare.exe.

73 For information, see Using the sqlci.exe command line. Cleaning up Use the command line to delete the temporary scripts folder you created. Run the following command: rd /s /q temporary_folder Where: /s removes the whole directory tree under temporary_folder /q sets quiet mode so it doesn't ask for confirmation when removing the directory tree temporary_folder sets the folder to delete This removes the temporary folder and all its subfolders. This is particularly useful if you want to script the unattended publishing of a package. You can also generate the script by using the SSMS add-in. On the last page of the wizard, it displays the script for you to copy and paste:

Creating database packages in TeamCity If you are using TeamCity as a continuous integration server, you can use the Red Gate TeamCity plugin to automate the creation of database packages.

75 Creating database packages in TeamCity If you are using TeamCity as a continuous integration server, you can use the Red Gate TeamCity plugin to automate the creation of database packages. To use the plugin, you must have: 1. a SQL Developer Bundle or SQL Toolbelt license an Automation license for continuous integration In the following example, we have already set up a build for our database in TeamCity. For information on how to install the plugin and set up a database build, see: Setting up a database build in TeamCity. To set up the TeamCity plugin to create packages: In the TeamCity plugin, under Source-controlled database, specify the location of your database folder. Your database folder is the folder where your database is stored in source control. In the example below, our database folder is our build VCS root in TeamCity: 2. Under Continuous Integration setup, select the Generate database creation script check box: 3. If you want to upgrade the database using static upgrade scripts, select the Generate upgrade scripts check box: More information on how Deployment Manager upgrades databases 4. Under Deployment Manager, select the Create a Database Package check box:

5. In the Package ID box, enter the name of the package you want the build to create. You cannot upgrade databases from previous versions that use a different package name. 6. 7.

76 5. In the Package ID box, enter the name of the package you want the build to create. You cannot upgrade databases from previous versions that use a different package name Packages are named with the convention <package ID>.<build number>, for example: WidgetDev.1.0.nupkg In the Server URL box, enter the URL for your Deployment Manager web interface, for example: In the DM API key box, enter the API key for your Deployment Manager user account. For information on how to find your API key, see: Finding your API key. Your TeamCity build is now set up to create database packages. Publishing packages If you are using TeamCity as a NuGet server, packages are automatically published to the TeamCity NuGet feed when the build runs. To enable the TeamCity NuGet server: 1. In TeamCity Administration, under Integrations, click NuGet Settings:

If you want to publish the database packages to a different feed, you need to add a NuGet Publish build step to your

77 2. On the NuGet Server tab, click Enable: The URLs for your TeamCity NuGet feed are displayed. To use this feed with Deployment Manager, you need to add it as a package feed in the Deployment Manager web interface. If you want to publish the database packages to a different feed, you need to add a NuGet Publish build step to your database build in TeamCity. Deploying database packages To deploy database packages, you need to specify some variables in Deployment Manager.

78 Creating database packages with MSBuild If you are not using TeamCity, you can create database packages using a Redgate MSBuild script. To use the script, you must have: a SQL Developer Bundle or SQL Toolbelt license an Automation license for continuous integration Example: packaging WidgetDev In the following example, we will run the Redgate MSBuild script to package our WidgetDev database for deployment. For more information on using MSBuild, see: MSBuild reference (Microsoft documentation). The example has three steps: Downloading and unzipping sqlci.zip Editing the sqlci.targets file Running MSBuild 1. Downloading and unzipping sqlci.zip 1. Download the build script from the Redgate website: 2. Unzip sqlci.zip to a location on your computer.in this example, we are using D:\Database Packages. sqlci.zip contains the files required to create database packages. To specify the database you want to package, and where you want the package to be created, you need to edit the sqlci.targets XML file. 2. Editing the sqlci.targets file When you edit sqlci.targets, you must specify a value for at least the following XML elements: <scriptsfolder> The location of your database (scripts) folder. In this example, we have checked out our database from source control to a local working folder: <scriptsfolder>d:\databases\widgetdev</scriptsfolder> For information about scripts folders and source control, see: Working with scripts folders (SQL Compare documentation) <generatecreationscript> Specify <generatecreationscript>true</generatecreationscript> to generate a SQL script to create the database. The creation script is included in the package. <packageversion> The version number for the database package. In this example, our database is at version 1.0, so we specify <packageversion>1.0</packageversion> If we specify a version number, we need to update sqlci.targets when we want to create a package with a different version number.

79 If you want to run the build script from a continuous integration server, you can specify a variable. For example, $(build_num ber) for TeamCity, or $(CCNetLabel) for CruiseControl.NET. <packageid> The name (or ID) for the database package. In this example, we specify <packageid>widgetdevdatabase</packageid> If you specify a value for only these four elements, when you run MSBuild the package will be created in the folder where you unzipped sqlci.zip. In our example, we want to publish the package to a feed. To do this, we also specify values for: <packagerepository> The URL of your package feed. In this example, we specify <packagerepository> <apikeyforpackagepublish> The API key for your package feed. In this example, we specify <apikeyforpackagepublish>apikey</apikeyforpackagepublish> 3. Running MSBuild For information on package feeds, see: Working with package feeds. Now we have specified the required values in sqlci.targets, we can run MSBuild to package our database. You can run MSBuild from a continuous integration server (for example Team Foundation Server, CruiseControl.NET, or Jenkins), or from the command line. To run MSBuild from the command line: 1. In Windows Start menu, click All Programs. 2. In the Microsoft Visual Studio folder, under Visual Studio Tools, click to run the Visual Studio Command Prompt. 3. From the command prompt window, navigate to the folder where you unzipped sqlci.zip. In our example, this is D:\Database Packages. 4. Run msbuild. MSBuild runs, creates the package, and publishes it to the package feed. Deploying the package To deploy the package we have created, we need to specify some variables in Deployment Manager.

80 Deploying database packages If you are deploying an application and a database at the same time, we recommend that you add the database as the first deployment step. There are two reasons for this: Variables Failed database deployments are rolled back The SQL script Deployment Manager uses to deploy a database runs inside a transaction. If the scripts fails, any changes are rolled back automatically, and Deployment Manager does not perform the next deployment steps. Database deployments can take longer than application deployments While Deployment Manager is deploying multiple components, there will be a period of time when only part of a deployment has been completed. For example, if your web application package step is before your database package step, there will be a period during the deployment when the website has been updated, but the database upgrade is still in progress. Database deployments can take a long time, so if you deploy the database first, you minimize the period of time when components are out of sync during the deployment. To deploy database packages with Deployment Manager, you need to specify the following variables: databaseserver The SQL Server you want to deploy to. databasename The database you want to deploy to. You also need to specify how to connect to the SQL Server: databaseintegratedauthentication If you want to use Windows authentication to connect to the SQL Server, specify True. If you do not use Windows authentication, you need to also specify a username and password. databaseusername The username you want to use to connect to the SQL Server. You do not need to specify a username if databaseintegratedauthen tication is set to True. databasepassword The password to connect to the SQL Server. You do not need to specify a password if databaseintegratedauthentication is set to True. Optionally, you can also specify: mode The type of upgrade you want Deployment Manager to perform. You can specify either upgrade if you want to upgrade the database, or c reatenew if you want to drop and recreate the database. allowdynamicdatabaseupgrade If you want Deployment Manager to perform a dynamic database upgrade, specify True. However, Deployment Manager will always perform a static upgrade if the package contains an upgrade script it can use, even if this this variable is set to True. For more information, see: How Deployment Manager upgrades databases. allowpredeploydatabasevalidation If you want Deployment Manager to validate the upgrade before deployment, specify True. Deployment Manager can only validate a static upgrade (validating dynamic upgrades before deployment is not currently supported). allowpostdeploydatabasevalidation If you want Deployment Manager to validate the upgrade after deployment, specify True. abortonhighseveritywarnings If you want Deployment Manager to cancel a deployment if there are any serious deployment warnings, specify True. Example: upgrading WidgetDev For example, if we want to upgrade our WidgetDev database, we specify the following: Name databaseserver databasename databaseusername Value localhost WidgetDev user

81 databasepassword mode allowdynamicdatabaseupgrade password upgrade True

Worked example - setting up a database for deployment Overview This worked example demonstrates how to set up Deployment Manager to deploy a database.

82 Worked example - setting up a database for deployment Overview This worked example demonstrates how to set up Deployment Manager to deploy a database. First we will create a database package, then we will deploy it to a separate database server running a Deployment Manager Agent. Then we will deploy a change to the database on the agent. Requirements A Windows server with SQL 2008 R2 SP1 to run the Deployment Manager server on (called DPDB in this example) A Windows server with SQL 2008 R2 SP1 to run the Deployment Manager Agent on (called DPDB2 in this example) The WidgetShop database. You can download a creation script for this here SQL Server Management Studio (SSMS) The Red Gate Continuous Integration build scripts. You can download them here Source-controlling the database We need to create a scripts folder of the database which we will use to create the package and deploy it with Deployment Manager. To do this we will link the database to SQL Source Control. Open SSMS. In the Object Explorer, right-click the WidgetShop database, and click Link database to source control. The Link to Source Control dialog box is displayed: Under Source control system, select your source control system. In Repository URL, type or paste the URL for the root of your source control repository. The repository URL is case sensitive. 5. Depending on your source control system, you may need to specify extra information. See Linking to Source Control. Click Browse. The Select Scripts Folder Repository dialog box is displayed:

A dialog box is displayed for you to supply a commit comment for the creation

83 6. 7. Click Create Folder. The Create Folder dialog box is displayed: 8. Type WidgetShop and click Create. A dialog box is displayed for you to supply a commit comment for the creation of the new folder in source control: Type a comment, and click OK. Select the WidgetShop folder and click Create Folder.

84 The Create Folder dialog is displayed again. 11. Type Scripts and click Create. A dialog box is displayed for you to supply a commit comment for the creation of the new folder in source control. 12. Type a comment, and click OK. 13. On the Select Scripts Folder Repository dialog, click Select. 14. On the Link to Source Control dialog, select Dedicated Database. 15. Click Link. 16. Use your source control system to check out the database scripts folder at WidgetShop\scripts to C:\WidgetShop\scripts. WidgetShop is now in source control and you've got a copy of the scripts folder checked out to your local disk. Installing the Deployment Manager Server We will be installing this on DPDB. To install the Deployment Manager Server, follow this tutorial: Installing Deployment Manager Now we need to install the Deployment Manager agent on DBDP2, following the instructions in this article: Installing Deployment Manager Agent We now have the server DBDP2 set up in an environment in Deployment Manager: Creating the database package We need to create a database package for Deployment Manager to use. In this example we will create the package manually. You can also set this up as automated process on a build system On the DPDB server, unzip the Red Gate Continuous Integration build scripts. Open a command prompt as Administrator. Navigate to the location where you extracted sqlci.exe and run the following command:

$sqlci.exe --packageid="widgetshop" --generatecreationscript --packageversion=1.0 --scriptsfolder="c:\widgetshop\scripts" 3. 4.$

85 sqlci.exe --packageid="widgetshop" --generatecreationscript --packageversion=1.0 --scriptsfolder="c:\widgetshop\scripts" Where C:\WidgetShop\scripts is the location you checked out the WidgetShop scripts folder to. This creates a NuGet package named WidgetShop_RG-1.0.nupkg in the working folder. Create a folder named C:\NuGetPackages. Copy WidgetShop_RG-1.0.nupkg to C:\NuGetPackages. Setting up the initial database Deployment Manager can be set to upgrade databases or to drop existing ones and create new ones in their place. In this example we will set it to upgrade a database. We need to make an initial database or the deployment will fail as it will have nothing to upgrade. 1. On the Deployment Manager Agent server, open SSMS. Add a new database by right clicking the Databases folder: 2. Click New Database. The New Database dialog is displayed:

86 3. Type WidgetShop as the database name and click OK. A default database is created. Setting up the Package Repository 1. On the menu bar, in the Deployment Manager web interface, click Settings:

87 2. Click Package repositories. The NuGet page is displayed:

88 3. Click Add NuGet package repository. The New Feed page is displayed:

$4. Name the repository WidgetShop and set the repository path as C:\NuGetPackages on the Deployment$

89 4. Name the repository WidgetShop and set the repository path as C:\NuGetPackages on the Deployment Manager server. Leave the username and password blank. 5. Click Add. The following page is displayed:

90 The new package repository is listed. Setting up the project 1. In the top menu, click Projects. The create project page is displayed:

91 2. Click Create Project. The create new project page is displayed:

92 3. Name the project WidgetShopDatabase and click Save. The project overview page is displayed:

93 4. Click Steps. The steps page is displayed: 5. Click Add package step. The add step page is displayed:

6. 7. 8. In the NuGet package box, type WidgetShop.

94 In the NuGet package box, type WidgetShop. Select the DPDB2 machine and click Add > to move it to the Included section. Click the Add button at the bottom of the page. The steps page is displayed:

95 9. Click Variables. The variables page is displayed:

96 10. Click Edit Variables, then click Add new. A new variable is displayed:

97 Name the new variable databaseintegratedauthentication and type the value false. This means Deployment Manager will use SQL authentication. In the same way, add the following variables: Name databaseusername databasepassword databaseserver databasename allowdynamicdatabase mode Value <your SQL server username> <your SQL server password> <your SQL server name> <your database name> True Upgrade

98 13. In the green box, click Save. Creating the release For more information about variables in Deployment Manager, see Variables. 1. Click Releases. The releases page is displayed:

99 2. Click Create release. The create release page is displayed:

3. 4. 5. Make sure 1.0 is entered in the Version box. Under Packages, make sure 1.

100 Make sure 1.0 is entered in the Version box. Under Packages, make sure 1.0 is selected in the Version dropdown. Click the Create Release button at the bottom. A page for the release is displayed:

101 6. Click Deploy this release. The create deployment page is displayed: You have now created your first release. Deploying the release 1. Click Deploy release. The release process happens and the database is deployed. The deploy page is displayed and you can view the progress on it:

102 2. Expand Stage 3: Installation to review the log: On the Deployment Manager Agent, in the SSMS Object Explorer, expand the WidgetShop database. Expand the Tables folder. The deployment has created three new tables: WidgetPrices, WidgetReferences and Widgets.

You have now successfully deployed a database with Deployment

On the Deployment Manager server, in the SSMS Object Explorer,

Right-click the Tables subfolder of WidgetShop and click New

103 You have now successfully deployed a database with Deployment Manager. Deploying a new version of the database On the Deployment Manager server, in the SSMS Object Explorer, expand the WidgetShop database. Right-click the Tables subfolder of WidgetShop and click New Table: 3. A new tab is opened in SSMS. Name two columns name and widgetid and clear the Allow Nulls checkbox for each:

$4. 5. Save the table as WidgetNames. Commit the changes to SQL Source Control: 6. 7. To get the version of the database scripts folder from SQL Source Control, update the C:\WidgetShop\scripts folder.$

104 4. 5. Save the table as WidgetNames. Commit the changes to SQL Source Control: To get the version of the database scripts folder from SQL Source Control, update the C:\WidgetShop\scripts folder. To make a package with the new version of the database, run the following command: sqlci.exe --packageid="widgetshop" --generatecreationscript --packageversion=2.0 --scriptsfolder="c:\widgetshop\scripts" Copy the package WidgetShop_RG-2.0.nupkg to C:\NugetPackages. On the Deployment Manager menu bar, click Projects. Click WidgetShopDatabase. Click Create Release. The create release page is displayed: Make sure 2.0 is entered in the Version box. Under Packages, make sure 2.0 is selected in the Version dropdown. Click the Create Release button at the bottom. A page for the release is displayed:

105 15. Click Deploy this release. The create deployment page is displayed: 16. Click Deploy release. The deployment will run. The deploy page is displayed:

17. 18. On the Deployment Manager Agent, in the SSMS Object Explorer, expand the WidgetShop database. Expand Tables.

106 On the Deployment Manager Agent, in the SSMS Object Explorer, expand the WidgetShop database. Expand Tables. The deployment has added a new table: The new table has been deployed to the copy of WidgetShop on DPDB2. You have now successfully deployed a new version of a database with Deployment Manager.

107 Automating Deployment Manager You can use the DeploymentManager.exe command line interface to automate Deployment Manager server tasks. If you installed Deployment Manager to the default location, you can find DeploymentManager.exe in: C:\Program Files (x86)\red Gate\Deployment Manager\Tools Examples using Deployment Manager.exe In the following examples: Creating a release our Deployment Manager server URL is the API key for our user account is NRN94PPM3DZGHCQSIJRAPWE7TG the project we want to deploy is MyProject To create a release, at the command prompt, we navigate to the location of DeploymentManager.exe and then run: deploymentmanager create-release --server= --apikey=nrn94ppm3dzghcqsijrapwe7tg --project=myproject Creating and deploying a release To create and then deploy the release to our Staging environment, we run: deploymentmanager create-release --server= --apikey=nrn94ppm3dzghcqsijrapwe7tg --project=myproject --deployto=staging --waitfordeployment Deploying a release with specific package versions If we want to deploy the release using a specific version (v , in this example) of our WidgetDatabase package, we run: deploymentmanager deploy-release --server= --apikey=nrn94ppm3dzghcqsijrapwe7tg --project=myproject --deployto=staging --packageversion=widgetdatabase= releaseversion=2.0 --waitfordeployment Command line syntax For a full list of DeploymentManager.exe commands and options, see: DeploymentManager.exe syntax.

108 DeploymentManager.exe syntax You specify DeploymentManager.exe syntax as a command, followed by a number of options: deploymentmanager <command> <option> <option> Commands You can use the following commands with DeploymentManager.exe: create-release Creates and optionally deploys a release deploy-release Deploys a release list-envrionments Lists all the environments you can deploy to You can specify any number of the available options with each command. Each command has a number of required options. Options --server=<server URL> (required) The URL of your Deployment Manager server. For example: --server= The create-release, deploy-release and list-environments commands require this option. --apikey=<api key> (required) The API key of your Deployment Manager user account. For example: --apikey=jbikpfsah2bzec8ttzyslnbeu The create-release, deploy-release and list-environments commands require this option. --project=<project name> (required) The name of the Deployment Manager project you want to use. For example: --project="widget Shop" The create-release and deploy-release commands require this option. --deployto=<environment> (required with deploy-release) The environment you want to deploy to. For example:

109 --deployto=staging The deploy-release command requires this option, but it is optional with create-release. --releaseversion=<version> (required with deploy-release) The version number for the new release. For example: --releaseversion=1.0 or --releaseversion=1.%build.number% If you don't specify this option, the highest version number of all the packages you're deploying is used as the release version. If you want to use the build number from a continuous integration server (for example TeamCity), you can specify a variable or parameter. The deploy-release command requires this option, but it is optional with create-release. --user=<username> (optional) Your Deployment Manager account username. For example: --user=administrator You can specify this option with the create-release, deploy-release and list-environments commands. --pass=<password> (optional) Your Deployment Manager account passowrd. For example: --pass=password You can specify this option with the create-release, deploy-release and list-environments commands. --packageversion=<package name>=<version> (optional) The version number for a package you want to deploy. For example: --packageversion="widget Shop"=1.1 or --packageversion=1.1 You can use --packageversion=<version> to set a version number for all packages that you have not specified a version for. If you do not specify this option, the latest available version of a package will be used. You can specify this option with the create-release command.

110 --releasenotes=<notes> (optional) The release notes for the new release. For example: --releasenotes="patch to fix bug BG-399" You can specify this option with the create-release command. --releasenotesfile=<path> (optional) The path to a file that contains release notes for the new release. For example: --releasenotesfile="c:\deployments\release notes\release_notes.txt" You can specify this option with the create-release command. --deploymenttimeout=<time> (optional) The maxiumum time a deployment can take. For example: --deploymenttimeout=00:30:00 Specify the value in the format hh:mm:ss. The default value is 00:10:00. You can specify this option with the create-release and deploy-release commands. --deploymentchecksleepcycle=<time> (optional) The amount of time between deployment status checks. For example: --deploymentchecksleepcycle=00:00:30 Specify the value in the format hh:mm:ss. The default value is 00:00:10. You can specify this option with the create-release and deploy-release commands. --waitfordeployment (or -w) (optional) If specified, the command will wait for the deployment to complete before returning. You can specify this option with the create-release and deploy-release commands.

111 Security Server and Agent communication Outbound requests Administrator privileges Finding your API key

Server and Agent communication This page describes how Deployment Manager and Agent servers communicate in a secure way. Background Some deployment technologies have no security at all.

112 Server and Agent communication This page describes how Deployment Manager and Agent servers communicate in a secure way. Background Some deployment technologies have no security at all. Some require machines to be on the same Active Directory domain, or on the same LAN. Others require you to set up usernames and passwords, and to store them in configuration files. When designing Deployment Manager, we wanted to make it easy to have secure deployments out of the box, without expecting machines to be on the same domain. A common example is when the Deployment Manager server is running in your local LAN, close to your developers, while your production servers are running in the cloud or at a remote data center. We achieve this security using public-key cryptography. Deployment Manager/Agent communication The Agent service listens on TCP port by default, though this can be changed during the installation. Deployment Manager sends commands to it in the form of HTTP requests. These requests are encrypted using a pair of X509 certificates. This establishes a trust relationship between the two machines: Your Deployment Manager server will only issue commands to the Agents that it trusts. Your Agents only accept commands from a Deployment Manager they trust. When you install the Agent service, you add a key for the Deployment Manager servers it should trust. When you register a machine in Deployment Manager, you'll add the Agent key. In the diagram below, you can see the Deployment Manager web interface where machines are registered, and the Agent administration application: Since this is all based on public-key cryptography, it creates a highly secure way for the two machines to communicate without exchanging passwords, and works much like an SSH connection in the UNIX world. If necessary you can further restrict access using IPSec or VPNs, though this usually isn't necessary. Agent permissions The Agent service by default runs as Local System. This is because during installation of your applications you usually need to perform tasks that require a high-degree of access to the machine. For the sake of security, however, it's better to create a custom Windows user that has only the permissions you know you'll need. You can then configure the Deployment Manager Agent Windows service to run under that account.

113 Outbound requests This page describes the outbound requests made by Deployment Manager and deployment Agents. Outbound requests by Deployment Manager Deployment Manager makes the following outbound requests: Pushing packages and deployment instructions, and checking the health, of Agents Downloading packages from NuGet feeds (you choose the feeds) Outbound requests by Agents For security reasons, the Agent services make no outbound requests. The only outbound requests you may see is for certificate revocation list checking, which is a security feature of the.net framework. It's possible that PowerShell scripts in your packages may make outbound requests; in this case you should take care when deploying packages created by a third party.

114 Administrator privileges Deployment Manager administrators are users with privileges to manage the Deployment Manager application. Only administrators can do the following: Create new users Edit other users' details (including passwords) Edit authentication certificates Add and edit new NuGet feeds Upgrade Deployment Manager from a trial version Update version of the Deployment Manager server and Agents Take database backups Edit database backup schedule View a link to the database directly from the web interface

In the Deployment Manager web interface, on the menu bar, move the cursor over your user

115 Finding your API key If you are using tools that use the Deployment Manager API, you will need to specify an API key. To find the API key for your Deployment Manager user account: 1. In the Deployment Manager web interface, on the menu bar, move the cursor over your user name: 2. Click My profile: The API key for your user account is displayed at the bottom of the page:

116

Troubleshooting This page describes the following common errors: 'Unable to generate a temporary class (result=1)' error 'Could not load type 'System.Management.Automation.PowerShell'.

117 Troubleshooting This page describes the following common errors: 'Unable to generate a temporary class (result=1)' error 'Could not load type 'System.Management.Automation.PowerShell'...' error 'SocketException: No connection could be made...' error 'A required anti-forgery token was not supplied...' error 'There was a problem processing your request...' error 'A Deployment Manager error has occurred and this deployment has failed' error 'This package does not work with versions of Deployment Manager older than <version>...' error Deployment Manager server/machine communication 'The remote server returned an error: (405) Method Not Allowed' error 'Unable to generate a temporary class (result=1)' error If the IIS_IUSRS group does not have permission to read/write from the Windows Temp folder, you will see the following error when browsing the web interface: Unable to generate a temporary class (result=1) Fix To grant permission to the IIS_IUSRS group: In Windows Explorer, browse to C:\Windows. Right-click on the Temp folder, and then click Properties. The Temp Properties dialog box is displayed. On the Security tab, click Advanced: 4. The Advanced Security Settings for Temp dialog box is displayed. On the Permissions tab, click Continue:

118 5. Under the Permission entries list, click Add: 6. The Select User, Computer, Service Account, or Group dialog box is displayed. Click Locations:

119 7. 8. Select the local machine, and then click OK. In the Enter the object name to select box, type IIS_IUSRS, and then click Check Names: The IIS_IUSRS object name is expanded and underlined. 9. Click OK. The Permission Entry for Temp dialog box is displayed. 10. Under Permissions, select the check box to allow List folder / read data:

that is displayed, click Yes: 'Could not load type 'System.Management.Automation.PowerShell'.

120 Click OK. On the Advanced Security Settings for Temp dialog box, click OK, and then on the confirmation dialog box that is displayed, click Yes: 'Could not load type 'System.Management.Automation.PowerShell'...' error If the computer you have installed Deployment Manager on does not have Windows PowerShell 2 (or later) installed, you will see the following error when you launch the server administration application:

0.0.1:10930 The causes for this may be: The Deployment Manager service is not running. To start the service manually: a. b. In the Start menu, type services.msc, and then click Services.

121 Fix You need to install Windows PowerShell 2: x86 download x64 download 'SocketException: No connection could be made...' error You may receive this error when Deployment Manager server or the web interface are starting up: SocketException: No connection could be made because the target machine actively refused it :10930 The causes for this may be: The Deployment Manager service is not running. To start the service manually: a. b. In the Start menu, type services.msc, and then click Services. In the Services dialog box, right-click the Red Gate Deployment Manager service, and then click Start: Some kind of anti-virus or other security software is preventing the connection. You have multiple IP addresses, and HTTP.SYS is only bound to one of them. This is a common configuration when you are using, for example, a Tomcat-based service (like TeamCity) and Deployment Manager on the same machine. You can check this via: netsh http show iplisten

$To solve it, either add 127.0.0.1 to the list of IP addresses HTTP.SYS can listen on using: netsh http add iplisten 127.0.0.1 Or, in the registry under HKLM\Software\Deployment Manager, you can add the following string value: Deployment Manager.$

122 To solve it, either add to the list of IP addresses HTTP.SYS can listen on using: netsh http add iplisten Or, in the registry under HKLM\Software\Deployment Manager, you can add the following string value: Deployment Manager.Raven.HostName = <host name or IP address to use> 'A required anti-forgery token was not supplied...' error You may receive this error when trying to log in to the Deployment Manager web interface: A required anti-forgery token was not supplied or was invalid The causes for this error may be: Cookies are disabled in your web browser. For information on how to enable cookies, refer to your web browser's documentation: Manage your cookies and site data (Chrome documentation) How to manage cookies in Internet Explorer 9 (Internet Explorer documentation) Enable and disable cookies (Firefox documentation) Session cookies have expired. This can happen if you leave the Deployment Manager web interface on the Login page for several hours before trying to log in. If your session cookies have expired, you need to refresh the Deployment Manager Login page before you can log in. 'There was a problem processing your request...' error You may see the following error when adding a package step, or testing a package feed:

123 This error occurs when Deployment Manager has a problem connecting to a package (NuGet) feed. Fix To avoid this error, make sure that: You have specified the correct URL for your feed in the Deployment Manager web interface. Your feed is running. Your Deployment Manager server can see the machine your feed is running on. Your feed and network are not overloaded. You can check that your feed is running, and that Deployment Manager can see the machine the feed is running on, by navigating to the feed URL in a web browser.

124 'A Deployment Manager error has occurred and this deployment has failed' error This error is caused by problems with the Deployment Manager installation. It can occur if: The Deployment Manager plugin on the agent has been deleted. The Deployment Manager plugin on the agent has been moved or renamed. The Deployment Manager plugin on the agent has become corrupt. To fix this, try removing and reinstalling your agent. If this does not fix the error, contact support.

125 'This package does not work with versions of Deployment Manager older than <version>...' error This error may occur if: Your Deployment Manager server is out of date The agent handling the deployment is out of date (but your Deployment Manager server is up to date) If your Deployment Manager server is out of date You can check the version of Deployment Manager you are running on the bottom of any page in the web interface: If you need to upgrade Deployment Manager, see: Upgrading. If the Deployment Manager server is up to date but the error still occurs, you may need to upgrade the agents. If your agents are out of date If you need to upgrade Deployment Manager or its agents, see: Upgrading. If none of the above advice fixes your problem, contact support. Deployment Manager server/machine communication You can test whether Deployment Manager is able to reach a target machine (traversing firewall rules, etc.) by remoting to the Deployment Manager server, and pointing your web browser at (or whichever port you chose for machine to listen on). If you see this error: System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: An error occurred when verifying security for the message. It can sometimes happen because the clock on one of the two machines is out-of-sync. 'The remote server returned an error: (405) Method Not Allowed' error When deploying to a private NuGet feed, you may get the following error:

126 sqlci error occurred: System.InvalidOperationException: Failed to process request. 'Method Not Allowed'. The remote server returned an error: (405) Method Not Allowed.. A detailed error report has been saved to: C:\Users\%USER%\AppData\Local\Temp\%Filename%.saencryptedreport If this is blocking you, then you can that file to support@red-gate.com for us to investigate. This is caused by WebDAV being enabled on the private NuGet feed. To resolve the error, you need to disable WebDAV: Go to IIS Manager. Right-click on the NuGet feed, click on Explore. Open the web.config file for editing. Inside the module tag, add the following: <remove name="webdavmodule" /> Click here to see the how the modules section should look <system.webserver> <validation validateintegratedmodeconfiguration="false" /> <modules runallmanagedmodulesforallrequests="true"> <remove name="webdavmodule" /> <add name="errorlog" type="elmah.errorlogmodule, Elmah" precondition="managedhandler" /> <add name="errormail" type="elmah.errormailmodule, Elmah" precondition="managedhandler" /> <add name="errorfilter" type="elmah.errorfiltermodule, Elmah" precondition="managedhandler" /> </modules> <staticcontent> You should now be able to publish to your private NuGet feed.

127 Release notes and other versions Version 2.4 February 13th, 2014 Release notes Documentation Version 2.3 October 31st, 2013 Release notes Version 2.2 August 21st, 2013 Release notes Version 2.1 July 16th, 2013 Release notes Version 2.0 June 17th, 2013 Release notes Version 1.1 March 12th, 2013 Release notes Documentation

128 Deployment Manager 1.x release notes 30 th May (Version ) Copy Project - you can now easily duplicate an existing project with all its steps and settings Variable usability improvements improved discoverability of web application deployment variables Initial creation of website if an IIS website does not exist on deployment, it will now be automatically created. For more information, see IIS websites. Raven DB upgrade Deployment Manager now uses Raven DB version 2, which includes improved security SQL Server database deployment bug fixes Bug fixes 22 nd April (Version 1.1.8) RgPublish.exe, the incorporated packaging tool, is now able to package files based on a.nuspec file For more details on how to use RgPublish.exe to create packages to deploy, see Creating and publishing application packages. New 'Downloads' page that makes it easy to access tools associated with Deployment Manager This can be found at [Deployment Manager URL]/configuration/downloads and contains links to download packaging tools and the REST api tool Users who want to utilize these tools in their continuous integration process can download them from this location at build time, removing the need to move these files onto build agents in advance and ensuring they are always using the newest version We now precompile all of our stylesheets, rather than doing it dynamically This should improve page load times after an app pool recycle, and fix issues seen on some machines where failure of dynamic compilation leads to pages with no styling Bug fixes 8 th April (Version 1.1.6) New command line tool for creating NuGet packages of a given folder. For more information, see our support pages. Deployment Manager executable is no longer reliant on other dlls Bug fixes 12 th March (Version 1.1.0) Deployment Manager package feed Deployment Manager can now host packages in its own integrated package feed. If you're using Red Gate's Continuous Integration resources for SQL Server and want to use the new feed, you must update to the latest version of the resources ( avail able for download here). Streamlined agent installation Bug fixes Package and publish database changes from SQL Server Management Studio You can use the new Deployment Manager SQL Server Management Studio (SSMS) add-in to create and publish database packages. D ownload the beta version of the Deployment Manager SSMS add-in. How to get started with the Deployment Manager SSMS add-in. 28 th February (Version ) Support for activating serial numbers when your server has no internet access Usability Improvements Bug fixes 14 th February (Version ) Command line improvements, including: Specify distinct version numbers for each package in a release "waitforrelease" switch is now available Bug fixes 5 th February (Version ) Native support for deploying SQL Server databases alongside your application Deployment Manager now includes Red Gate SQL Compare technology in its agents, to allow you to automatically update SQL Server databases as part of a release In order to benefit from this new functionality, you will need to package your database changes using the latest version of Red

129 Gate s Continuous Integration component for SQL Server from For more information about this new feature, see Working with database packages. Usability improvements Bug fixes 16 th January (Version ) Improved installation experience, including automatic IIS installation and configuration Usability improvements Dashboard no longer wraps Login using address as well as username Hint text removed from input fields Action links in tables are always visible Tasks tab is now a part of Settings Release number links in Project > Releases are now correctly styled as links Bug fixes 18 th December (Version ) Feature usage reporting Deployment Manager can now collect anonymous information on how you use the application, to help us improve future versions Lots of bug fixes 30 th November (Version ) Improved interoperability with Red Gate's TeamCity plug-in for SQL Server continuous integration Bug fixes 14 th November (Version 1.0.8) Usability improvements Improved NuGet Package auto-complete Settings page layout Descriptive 404 page Better unlicensed agent reporting Duplicate Password/My Profile page removed New Project goes straight to project page Health check button behavior fixed Improvements to the "Linking Deployment Manager to Agents" help page Impoved tab order setting is now above tasks Performance enhancements Bug fixes 1 st November (Version 1.0.6) The first full release of Deployment Manager! The product is out of its Early Access phase and can now be purchased through the Red Gate website. What's new in Deployment Manager v1.0.6? Full licensing - you are now able to fully license your Deployment Agents Performance enhancements Improved reporting of missing prerequisites Bug fixes We've also added some new Getting Started guidance.

130 Extending Deployment Manager to deploy SSAS databases David Pond, Red Gate software engineer January 2013 At Red Gate s 2012 SQL in the City US tour, a question many people asked was: How can I deploy x with Deployment Manager? At the time, I was investigating Microsoft s business intelligence stack for Red Gate's SSAS Compare tool, and I began wondering if you could use Deployment Manager to deploy SSAS databases. This article will walk you through my solution and hopefully inspire you to create your own deployment solutions. You can download a zip containing the files used in this example here. Who might find this paper useful Deployment Manager users interested in extending Deployment Manager functionality Business intelligence developers deploying SSAS databases to several environments, and want to automate the process Overview To deploy a SSAS database with Deployment Manager, we'll: Create a NuGet package containing the SSAS files and a PowerShell deployment script Put the NuGet package on a NuGet server Get Deployment Manager to pull the latest package from the NuGet server Tell Deployment Manager to deliver the package along environment specific variables to a Deployment Manager Agent The Deployment Manager Agent will unpack the package and run the PowerShell deployment script with the environment variables.

131 Technologies used We ll be using the following technologies: Deployment Manager A Red Gate tool that manages your deployment process. Its main functionality is the deployment of web applications and their databases, but, as we ll learn, it can be extended to deploy almost anything. SQL Server Analysis Services (SSAS) databases Part of Microsoft s business intelligence stack. SSAS databases pull in data from multiple sources and process it, so users can easily query data, manipulate it in pivot tables, and draw conclusions from it. NuGet Microsoft s open-source package manager for the.net Framework. A NuGet package is essentially a zip file with some additional metadata. You may have used NuGet before to add libraries to Visual Studio projects, but we ll be using them for a broader purpose. PowerShell

Using the SQL CI TeamCity plugin in SQL Automation Pack

Using the SQL CI TeamCity plugin in SQL Automation Pack We recommend upgrading to the DLM Automation Suite so you can take advantage of the latest features and fixes. For more information, see Upgrading.