Why split build and deployment

Many TeamCity setups deploy from build configurations. Over time those configurations collect deployment-only steps, and the deployment process ends up spread across step order and parameters that are hard to review.

With Jaws Deploy, TeamCity compiles, tests and packages. Jaws Deploy holds the deployment process and the environments with their variables, and records every deployment. Who can change or run a deployment is set in Jaws Deploy, separately from who can edit the build.

Release after every build

The last step of the build configuration creates a release, versioned with the build number, and deploys it to the first environment, usually Development. Promotion to Staging and Production happens in Jaws Deploy.

Release when you decide

TeamCity builds and publishes the package. People create releases in Jaws Deploy when they are ready, from the package versions already in the feed. This suits teams with a fixed release schedule.

What the TeamCity plugin does

Create and deploy Creates a release, versioned with the TeamCity build number unless you set another version, and deploys it to the environments or lifecycle phase you name. You can set a channel and release notes, and both can use TeamCity parameters.
Promote Promotes a given release, or the latest one, to the next environments. Use it in a separate build configuration when you want to promote from TeamCity.
Deployment log in TeamCity Follows each deployment and writes its log into the TeamCity build log. A failed deployment fails the build, and stopping the build cancels the deployment.
Credentials Uses a Jaws Deploy service account ID and API key, with the key stored in a TeamCity password field.

Where the package comes from

The plugin creates releases but does not upload packages. Upload the package in an earlier build step with the REST API, or add TeamCity's NuGet feed to Jaws Deploy as an external feed. Unless you pin versions, a new release uses the newest package versions its channel allows.

Using the PowerShell SDK instead

For more control, such as releasing only from certain branches, pinning several package versions or writing release notes from your issue tracker, call the PowerShell SDK from a PowerShell build step. Set env.JAWS_API_LOGIN to the service account ID and env.JAWS_API_PASSWORD to the API key, as a password parameter.

Import-Module ./JawsDeploySdk.psm1

$release = New-JawsRelease `
    -projectId       "<project id>" `
    -version         "%build.number%" `
    -packageVersions @{ "Shop.Web" = "%build.number%" }

Invoke-JawsDeployRelease -releaseId $release.releaseId -environmentName "Development"

Moving deployments out of TeamCity

Move one project at a time.

  1. Install the plugin and add a step that creates a release in Jaws Deploy after each successful build. Leave the existing TeamCity deployment steps in place.
  2. Build the project's deployment process in Jaws Deploy and deploy to Development from there. Then turn off the matching TeamCity steps.
  3. Repeat this for each remaining project.
  4. Delete the TeamCity build steps and configurations you no longer use.

Who does what

TeamCity builds, tests and packages, then starts the release. Jaws Deploy runs the deployment, resolves variables for each environment, promotes releases through the lifecycle and keeps the deployment history. We don't build a CI server, so the two tools don't overlap.