Example 3

How can I use the backup module within TeamCity?

TeamCity has a bundled PowerShell runner which can be used to execute the backups.

You just have to configure the runner properly and have access to the WDP.Backup PowerShell module. The following example will show you how to accomplish that.

---

1. Get access to the PS module

You can either:

1. use NuGet Install-Package WDP.Backup. (preferred way)

• note: this installs a solution-level NuGet package and the PS file will be placed in the packages folder.

2. or manually download the PS file to a desired location and add it to source control.

A word on using NuGet

If you decide to use NuGet , which I'd recommend btw, the package is installed as a solution-level package.

That means that the package won't be installed into any project but instead added to 'global/solution' packages.config file. NuGet package restore will however not work OOB with solution-level packages.

So to get the PS module to work within TeamCity you'd have to use either one of these methods:

1. use package restore on the TeamCity server.

• I've written two posts on this topic that can be found here and here if you're interested.

2. add the WDP.Backup.[version] package (folder) to version control (not recommended).

---

2. Configure the PowerShell runner

Add a new build step and select the PowerShell runner.

• I'm assuming that the PS module is downloaded via NuGet.

1. I'd recommend leaving the working directory empty (checkout directory is default).

2. Select Source Code mode

OK, now it's time to execute the backup.

3. Import the module: Import-Module .\packages\WDP.Backup.%WDP.Backup.Version%\wdp.backup.psm1

You might notice that I've used a parameter for the package version (%WDP.Backup.Version%). I'll explain why in a moment.

4. Select which IIS applications/sites to backup via .publishsettings files:

Set-Properties @{ SourcePublishSettingsFiles = @("%cfg.ServersToBackup%")}

• note: the paths to the files are stored in a configuration parameter (%cfg.ServersToBackup%), like so:

• note: not required but makes it easier to maintain

5. Execute the backup via Invoke-Backup

The backup (.zip) is automatically added to the build artifacts.

---

A word on handling NuGet versions

Instead of hard-coding the version into the path to the script, like so:

You can instead extract the package version into a configuration parameter that can be changed and overridden.

The benefit being that you now also have the ability to "test/try" new NuGet versions by running a custom build and changing the parameter for that build only.

---

I've written an entire blog post on this that shows some more details if you're interested.