Docs / Shipping code
Deployments and rollback
Request a deployment, have it approved, read its log, and roll back.
A deployment builds the application’s image with its build strategy, stores it in the cloud account the cluster runs in, and commits the application’s Kubernetes files to your cluster configuration repository under SysJ’s name. Argo CD on the cluster then applies them. SysJ does not check that the application is running; open its address or the cluster to see that.
Committing needs write access to the cluster configuration repository, granted under Cluster configuration. Without it the image is still built, and the deployment reads Built, not committed.
Request a deployment
- Open Deployments, or an application’s page, and choose Deploy.
- Choose the application and the environment.
- Choose a branch, and optionally pin a commit. Without one, SysJ uses whatever the branch points at.
Approval
In an environment that requires approval, the deployment waits as Waiting for approval, and its row links to Approvals. Someone else with deployment.approve approves or rejects it there; the person who asked can never approve their own. Rejected deployments build nothing.
Approvals names who asked for each deployment and the deployments table names who decided. A person without user.read sees “another member of this workspace” instead of a name.
States
| State | Meaning |
|---|---|
| Waiting for approval | Nothing is built until someone else approves it. |
| Queued | Accepted, and about to be handed to the workflow engine. |
| Running | The workflow is running. |
| Committed | The image was built and SysJ committed it to your repository. Argo CD on the cluster applies it. |
| Built, not committed | The image was built, and SysJ did not commit it, so nothing on the cluster changes. |
| Finished | The workflow finished with no build report, as a rollback does. |
| Failed | A step stopped. The log opens on the step that failed. |
| Rejected | An approver refused it. |
Build reports
Each build has a report under Build reports: its build strategy, the image it produced, the image scan, and the commit SysJ made. A deployment’s row shows one line of the scan and links to its report.
The scan is done by your workspace’s registry and shown as counts by severity, from critical to unknown. If the registry has not finished or did not scan the image, the report says so rather than showing zeros.
Reading the log
Each deployment has a log with one panel per step, with the failing step open. The log stays readable after the run’s pods are gone.
Rolling back
Roll back from the environment, for one application, to return to the version before the one running there. Nothing is rebuilt. It needs deployment.rollback.
The target is the newest version that deployed successfully there and differs from the one running. A rollback that failed is ignored when choosing it. If a forward deployment failed last, the rollback redeploys the version still running.
In an environment that requires approval, a rollback goes ahead without a second approval when someone has approved that exact image there before. Any other target waits for an approver, such as a version deployed before the environment required approval.
A rollback is refused when only one version has ever deployed there, or when the target would be the version already running. The dialog names the version it will return to, and whether it will wait, before you confirm.