CI/CD is one acronym hiding two jobs. CI - Continuous Integration - is about building and testing. CD - Continuous Delivery or Deployment - is about getting the result into environments. Jaws Deploy owns the CD half.
// CI owns
Build and verify
Compile, run unit tests, run integration tests, produce a versioned artefact. CI tools - TeamCity, GitHub Actions, GitLab, Jenkins, Azure Pipelines - are excellent at this.
// Jaws Deploy owns
Release and promote
Create an immutable release from the artefact, resolve variables per environment, execute deployment steps on targets, stream live logs, and record what happened.
The hand-off
A successful CI build calls into Jaws Deploy to create a release. The call carries three things: the project, the package version, and any release notes. Jaws Deploy snapshots the current deployment process and variables into a numbered release.
From there, CI's job is over. Promotion - Dev to Staging to Production - is owned by Jaws Deploy, driven from the UI, the REST API, or the PowerShell SDK.
How CI typically triggers a release
A single PowerShell step at the end of the build configuration. Same pattern works for GitHub Actions, GitLab, Jenkins, and Azure Pipelines.
Connect-JawsDeploy `
-Url "https://app.jawsdeploy.net" `
-ApiKey $env:JAWS_API_KEY
New-JawsDeployRelease `
-Workspace "default" `
-Project "checkout-service" `
-Version "2026.5.17.%build.number%" `
-Packages @{ "Checkout.Web" = "2026.5.17" }Why the split is worth keeping
It's tempting to push deployment into CI because CI runs anyway. The cost shows up later: the same Production deployment now lives in YAML, in a script someone wrote two engineers ago, and in everyone's memory of how the rollback worked last time. Splitting build and deploy gives both pieces room to specialise and a clean interface in between.