Rollbacks

A bad deployment is undone by deploying the earlier commit again. Gigadrive Network builds it fresh, and the production URL moves to the result once it is Ready, which is the same path every other deployment takes.

How the URLs move

Publishing a deployment re-points the moving URLs and purges the CDN cache for each of them. Which ones move depends on where the deployment ran:

A moving URL only ever advances. An alias is never handed to a deployment older than the one it currently serves, which is what stops a slow build that finished second from overwriting a fast one that finished first. It is also why there is no button that points production at last week's deployment: aliases move forward, and going back means creating something newer.

Redeploying an earlier deployment

1. Find the deployment you want back

   Open the application's deployment list, or the Deployments page of the environment. Filter by branch or search by commit message, commit SHA, or the name of whoever pushed it.

2. Open it and choose Redeploy

   Redeploy lives under More actions in the deployment header, and appears on any deployment that is Ready or Failed.

3. Watch the new deployment

   The console opens the new deployment's Logs tab. It is a new deployment with its own id and its own permanent URL, carrying the same commit, branch, environment, and pull request link as the one you redeployed.

4. Confirm the switch

   When it reaches Ready, its Overview tab lists <name>.gigadrive.app among its domains, marked Current. The CDN cache for that hostname is purged as part of publishing, so visitors get the new build without waiting for anything to expire.

An upload has no commit to rebuild from, so Redeploy does not help there. Upload the files again through Drop, which offers Redeploy into the existing application.

From the API

Deploying a pinned commit is the same operation the console performs, and it works on any commit in the repository rather than only ones you have deployed before.

import { GigadriveClient } from '@gigadrive/sdk';

const client = new GigadriveClient();
const applicationId = '0197b2f1-2f4a-7a0b-8a2d-222222222222';

// The commit that was known good, on the branch Production claims.
const rollback = await client.deployments.create({
  applicationId,
  gitSource: { ref: 'main', sha: '4f0c1d9a2b3e5f6708192a3b4c5d6e7f80912a3b' },
});

let status = rollback.status;
while (status !== 'ACTIVE' && status !== 'FAILED') {
  await new Promise((resolve) => setTimeout(resolve, 2000));
  status = (await client.deployments.get(rollback.id)).status;
}

if (status === 'FAILED') {
  throw new Error(`Rollback deployment ${rollback.id} failed`);
}

const { items } = await client.deployments.getHostnames(rollback.id);
console.log(items.map((hostname) => `https://${hostname.hostname}`).join('\n'));

The branch matters as much as the commit: a deployment only takes over <name>.gigadrive.app if its branch resolves to the Production environment. Pinning a good commit on a feature branch gives you a preview of it, not a rollback.

What redeploying does not undo

The commit comes back. Nothing else does.

• Environment variables are resolved when the deployment is built and provisioned, so the redeploy gets today's values. Roll a variable back yourself if it was the cause.
• Storage objects are not versioned by a deployment. Files your application wrote stay written. File storage covers backups and trash, which are the tools for that.
• Anything your build pushed elsewhere, such as a database migration or a third-party API call, is outside the deployment.

Deployments marked Expired can be redeployed the same way: retention removed their static assets after a long period without traffic, and redeploying rebuilds the commit with a full set of assets. Deployment retention covers when a deployment expires.