TeamCity builds and tests. A build step at the end of the build configuration creates a Jaws Deploy release, and Jaws Deploy promotes it from Development to Production.
Two integration paths
Use the plugin for a build step configured through form fields, or the PowerShell SDK when you want the logic in a script.
// Path A
The TeamCity plugin
Install the Jaws Deploy plugin in TeamCity and add a Jaws Deploy build step. Create & Deploy creates a release and deploys it. Promote moves an existing release to the next environments. The step writes the deployment log into the build log and fails the build if the deployment fails.
// Path B
PowerShell SDK
Add a PowerShell build step that imports the PowerShell SDK and calls New-JawsRelease. No plugin is needed, and the script can live in your repository next to the rest of the build.
Plugin step settings
| Setting | What to enter |
|---|---|
| API Base URL | https://app.jawsdeploy.net, or your own server for Jaws Deploy Stack |
| Login | The service account ID |
| API Key | The service account's API key. The field is stored as a TeamCity password. |
| Operation | Create & Deploy, or Promote |
| Project ID | The Jaws Deploy project |
| Version | The release version. Defaults to %build.number%. For Promote, leave it empty to promote the latest release. |
| Channel Name | Optional. Defaults to the project's default channel. |
| Phase Name or Environments | Where to deploy: a lifecycle phase, or a comma-separated list of environments |
| Release notes | Optional text. TeamCity parameters such as %build.vcs.number% are filled in. |
| Exclude step names | Optional comma-separated list of steps to skip in this deployment |
The plugin does not upload packages and does not pin package versions. A release it creates uses the newest package versions the channel allows, so upload the package before this step.
Drop this into a final "Create release" build step
Define env.JAWS_API_LOGIN (the service account ID) and env.JAWS_API_PASSWORD (the API key, password type) as TeamCity parameters, and pass the build number as the release version.
Import-Module ./JawsDeploySdk.psm1 # github.com/JawsDeploy/powershell-sdk
# JAWS_API_LOGIN and JAWS_API_PASSWORD come from the env.* parameters
New-JawsRelease `
-projectId "<project id>" `
-version "%build.number%" `
-packageVersions @{ "Checkout.Web" = "%build.number%" } `
-notes (Get-Content ./CHANGELOG.md -Raw)Where the package comes from
Two common setups:
- Push to Jaws Deploy's built-in feed. Add a step before release creation that uploads the package with the REST API (
POST /api/packagestore/package). The release then uses the version you just pushed. - Use TeamCity's NuGet feed. Add TeamCity's NuGet feed to Jaws Deploy as an external NuGet feed. Pin the package version to the build number in the SDK call, or let the release take the newest version the channel allows.
Storing the API key
Keep the API key in a password-type TeamCity parameter, not as a literal in the build configuration. TeamCity masks it in build logs. One service account key can serve every build configuration that creates releases.