Deploying a Release

Create an immutable release, deploy to an environment, test, and roll back if needed.

Overview

Releases are immutable snapshots of your app configuration. Deploying a release binds that snapshot to an environment (e.g., staging or production), making it live for all traffic to that environment. This guide walks through the full workflow.

Deployment Workflow

Create a Release

Open your pipeline in the pipeline editor
Click the Create Release button in the toolbar
The Create Release dialog appears with:
- Release Tag (required) -- a version identifier (e.g., v1.0.0, 2024-03-15-fix)
- Description -- release notes describing what changed
Optionally toggle Deploy after release to immediately deploy when the release is created:
- When enabled, a dropdown appears to select the target Environment
Click Create Release (or Release & Deploy if deploying immediately)

The release captures your entire app state -- pipelines, stages, steps, endpoints, tool configurations -- as an immutable snapshot.

Immutable Snapshots

Once created, a release cannot be modified. This guarantees that what you deploy is exactly what you tested. Any further changes require a new release.

Deploy to an Environment

If you did not toggle "Deploy after release" in the previous step:

The newly created release appears with a Ready state
From the release's Actions menu, select Deploy to Environment
Choose the target environment from the dropdown (e.g., "staging", "production")
Confirm the deployment -- it takes effect atomically and instantly

Verify the Deployment

After deploying, confirm everything works:

Send test requests to your endpoint, specifying the environment
Check the execution logs for errors or unexpected behavior
If using Cortex, verify the chat experience against the deployed environment

curl -X POST https://api.mechamental.com/v1/trigger/chat \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-Environment: staging" \
  -d '{"message": "Test message"}'

Promote to Production

Once staging validation passes:

Open the same release (or create a new one if you made additional changes)
Deploy it to your production environment using the same Actions > Deploy to Environment flow
Verify production traffic is handled correctly

Staging First

Always deploy to a staging environment first and run your validation checks before promoting to production. This catches issues before they affect live traffic.

Roll Back if Needed

If something goes wrong after deploying:

Navigate to the environment or the releases list
From the previous release's Actions menu, select Rollback to Previous
The environment instantly reverts to the prior release

Rollbacks are atomic -- the previous release's configuration takes effect immediately. No data is lost because releases are immutable snapshots.

Release States

State	Meaning
Ready	Release created, not yet deployed
Deployed	Actively serving traffic in at least one environment
Superseded	A newer release has been deployed to the same environment

Best Practices

Use descriptive release tags -- include dates, version numbers, or ticket references so you can identify releases at a glance
Write release descriptions -- document what changed so reviewers and operators can understand the release without reading diffs
Deploy to staging first -- validate behavior before promoting to production
Keep releases small -- frequent, small releases are easier to debug than large batches of changes

On this page