Deploy Requests

Overview

Deploy requests create and run deployments. Every release is a request that records the application, environment, version, target hosts, review, execution log and result, forming a complete audit trail.

The list can be filtered by environment, application and request time, and the status tabs (pending review, pending deploy, succeeded, failed, ...) switch quickly between states.

New request

Click New Request and pick the application and environment (i.e. a deploy configuration). The remaining fields depend on the deploy mode.

Standard deploy

• Title: the name of the request; including the version or a change summary is recommended.
• Branch / tag / version:
  • Branch: pick a branch and a Commit ID; the most recent commits are listed;
  • Tag: pick a tag of the repository;
  • Build repository: pick a finished version from the build repository and skip the build stage.
• Target hosts: the hosts of this request, chosen from the hosts of the deploy configuration; create several requests to release in batches.
• Remarks: optional.
• Scheduled deploy: deploy automatically at the given time (up to one minute of delay); requests that require review must be approved first.

Custom deploy

• Title: the name of the request.
• SPUG_RELEASE: a value available to the custom scripts as $SPUG_RELEASE, used for dynamic variables of this release.
• Upload: shown when the deploy configuration contains a data transfer action whose source is Upload on deploy.
• Target hosts / Remarks / Scheduled deploy: same as standard deploy.

Review

When the deploy configuration has review enabled, new requests start in Pending review. A user with the Review request permission clicks Review to approve or reject (with a reason). The result is sent as an in-app notification and through the notification channel of the deploy configuration. Rejected requests can be edited and resubmitted.

Deploying

Click Deploy on a request in Pending deploy to open the deploy console, which streams the server-side build stage and the output of every target host in real time. The icon next to a host name opens the web terminal of that host.

For requests that failed or only partially succeeded, clicking Deploy again offers three modes:

• All: deploy every host, including the ones that already succeeded.
• Retry: deploy only the hosts that failed last time.
• Canary: pick specific hosts to deploy first. The request ends in Canary succeeded, and the remaining hosts can be deployed later.

Rollback

Successful requests offer Rollback, which creates a new request based on a previous version; see Rollback.

Deleting requests

Requests cannot be deleted individually once they have been deployed. This is deliberate: in our experience deploy records are important clues when investigating incidents. Imagine a user releases a new version without proper testing, the version causes an outage, and the user quietly deletes the record afterwards; the deletion would only get in the way of the investigation. Therefore requests can only be removed in bulk with Batch delete, either by date or by the number of records to keep.

Statuses

Status	Description
Pending review	review is enabled and the request waits for approval
Rejected	review failed; the request can be edited and resubmitted
Pending deploy	ready to deploy
Deploying	deployment in progress
Succeeded	every target host deployed successfully
Canary succeeded	the selected hosts succeeded, the rest have not been deployed
Failed	at least one host failed; retry or deploy all again

Tip

• Requests created by webhook auto deploy have the type Webhook and take the first 20 characters of the commit message as their title (the tag name for tag triggers).
• Times are shown relative by default; hover to see the full timestamp.