# The Role of Jaws Deploy in CI/CD Workflows

Source: https://www.jawsdeploy.net/guides/role-of-jaws-deploy-in-ci-cd

CI builds and tests. Jaws Deploy promotes the same release through Dev, Staging, and Production.

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.

**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.

**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" }
```

> **// The most common mistake - Don't put deployment logic inside the CI pipeline.**
> 
> Teams that paste a `deploy-to-prod.ps1` into their GitHub Actions workflow lose every benefit of having a release model: no immutable snapshot, no variable scoping, no promotion gate, no clean rollback. Let CI build. Let Jaws Deploy deploy.

## 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.