Deployment strategies

Recent platform changes to know

• GitHub Copilot cloud agent now signs commits (commits appear Verified). If you use agent-driven release automation, confirm commit-signing and author attribution meet your audit requirements. (GitHub changelog, Apr 2026)
• GitHub Actions updates (early-April 2026): service container entrypoint/command overrides, OIDC custom properties, and VNET failover options — review your action security and networking permissions when automating releases. (GitHub changelog, Apr 2026)
• The repository-level Security tab was renamed to "Security & quality" — code-quality and security findings are colocated there. Check that automated release checks surface in this view. (GitHub changelog, Apr 2026)
• Vercel supports instant rollbacks via vercel rollback and promotion via vercel promote; hobby-plan restrictions apply (you can only roll back to the previous production deployment on hobby). Use these commands in CI for fast recovery. (Vercel docs, Mar 2026)
• Linear released Triage Intelligence to help prioritize and tag issues; integrate release notes with your PM tool to make changelogs actionable for product and support teams. (Linear docs, Apr 2026)

Workflow

Step 1 — Changesets for version management

Use Changesets in monorepos to collect per-PR change metadata and produce consistent version bumps and changelogs.

Install:

pnpm add -D @changesets/cli @changesets/changelog-github
pnpm changeset init

Example config (keep the schema version matched to the installed package):

// .changeset/config.json
{
  "$schema": "https://unpkg.com/@changesets/config@3.1.1/schema.json",
  "changelog": ["@changesets/changelog-github", { "repo": "org/repo" }],
  "commit": false,
  "access": "public",
  "baseBranch": "main",
  "updateInternalDependencies": "patch"
}

Notes:

• Pin the schema to a changesets version you install, or omit the version to reference the latest.
• Changesets reduce changelog drift in monorepos — include a changeset in every PR that changes public behavior.

Step 2 — Automated releases with release-please

Use Release Please to generate changelogs, open release PRs, and create GitHub Releases based on conventional commits.

Minimal release job example (use the v4 line of the action):

# .github/workflows/release.yml
name: Release
on:
  push:
    branches: [main]

permissions:
  contents: write   # required to create tags/releases
  pull-requests: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: googleapis/release-please-action@v4
        id: rp
        with:
          release-type: node
          package-name: my-app

Guidance:

• Grant least-privilege permissions the action needs (contents: write is commonly required for tags/releases).
• Keep the action pinned to a major tag (e.g., @v4) and update regularly for security/permission changes.

Step 3 — GitHub Release API via CLI

Create and manage releases with the GitHub CLI when you need manual control:

gh release create v1.2.0 --title "v1.2.0" --notes-file CHANGELOG.md --target main
gh release create v2.0.0-beta.1 --prerelease --notes "Beta for new API"
gh release upload v1.2.0 dist/app.zip dist/checksums.txt
gh release list --limit 10

If you use agentic tooling (Copilot SDK or Copilot agents) in your release flow, remember Copilot cloud agent now signs commits — verify how these signed commits appear in your audit logs and branch protection rules.

Step 4 — Feature flags with Vercel Edge Config

Use Edge Config for low-latency flag checks and gradual rollouts. Example client pattern:

import { get } from "@vercel/edge-config";

type FeatureFlags = {
  newDashboard: boolean;
  rolloutPercentage: number;
};

async function getFlags(): Promise<FeatureFlags> {
  return (await get<FeatureFlags>("featureFlags")) ?? {
    newDashboard: false,
    rolloutPercentage: 0,
  };
}

function hashUserId(id: string): number {
  let h = 0;
  for (let i = 0; i < id.length; i++) h = ((h << 5) - h + id.charCodeAt(i)) | 0;
  return Math.abs(h);
}

async function isEnabled(flag: keyof FeatureFlags, userId?: string): Promise<boolean> {
  const flags = await getFlags();
  const val = flags[flag];
  if (typeof val === "boolean") return val;
  return userId ? hashUserId(userId) % 100 < (val as number) : false;
}

Notes:

• Edge Config propagation is fast (generally sub-second) but tests should account for short propagation windows.
• Always set an owner and expiry for rollout flags to avoid orphaned feature flags.

Step 5 — Canary deploy with health-check soak (Vercel example)

Use a canary channel and automated health-checks, then promote or rollback using Vercel CLI. Vercel provides vercel rollback and vercel promote for instant recovery; hobby plan includes limitations on how far back you can roll back.

# .github/workflows/canary.yml
name: Canary Deploy
on:
  push:
    branches: [canary]

jobs:
  canary:
    runs-on: ubuntu-latest
    environment: canary
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: pnpm install --frozen-lockfile && pnpm build
      - run: npx vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }} --build-env NEXT_PUBLIC_RELEASE_CHANNEL=canary
      - name: Soak test (5 min)
        run: |
          for i in {1..5}; do
            STATUS=$(curl -so /dev/null -w "%{http_code}" https://canary.example.com/api/health)
            [ "$STATUS" != "200" ] && echo "Health check failed ($STATUS)" && exit 1
            echo "Check $i/5 passed"; sleep 60
          done
      - if: failure()
        name: Auto-rollback
        run: vercel rollback --token=${{ secrets.VERCEL_TOKEN }}

Refer to the official Vercel CLI docs for vercel rollback and vercel promote; hobby plans may restrict rollback to the immediate previous production deployment.

Step 6 — Rollback procedures

Prefer platform instant rollback when available (Vercel), and use database-safe expand-contract migrations:

# Vercel instant rollback
vercel rollback [deployment-id or url] --token=$VERCEL_TOKEN

# Promote a previous deployment (undo a rollback)
vercel promote [deployment-id or url] --token=$VERCEL_TOKEN

# Git-based rollback to redeploy a previous tag
git revert HEAD --no-edit && git push origin main

# Force-run a deploy workflow with an explicit version
gh workflow run deploy.yml -f version=v1.1.9

Examples

Example 1 — Conventional commits driving release-please

git commit -m "feat: add user profile page"           # → minor bump
git commit -m "fix: resolve login redirect loop"       # → patch bump
git commit -m "feat!: redesign auth API

BREAKING CHANGE: /auth/login returns session object instead of raw token."
# → major bump
# release-please opens a Release PR with version + CHANGELOG, merging it creates the GitHub Release

Example 2 — Edge Config middleware for maintenance mode

import { createClient } from "@vercel/edge-config";
import { NextRequest, NextResponse } from "next/server";

const ec = createClient(process.env.EDGE_CONFIG);

export async function middleware(req: NextRequest) {
  if (await ec.get<boolean>("maintenanceMode")) {
    if (!req.nextUrl.pathname.startsWith("/maintenance"))
      return NextResponse.rewrite(new URL("/maintenance", req.url));
  }
  const beta = await ec.get<string[]>("betaUsers");
  const uid = req.cookies.get("userId")?.value;
  if (req.nextUrl.pathname.startsWith("/beta") && (!uid || !beta?.includes(uid)))
    return NextResponse.redirect(new URL("/", req.url));
  return NextResponse.next();
}

Example 3 — Release + deploy + Slack notify

name: Release & Notify
on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: googleapis/release-please-action@v4
        id: rp
        with:
          release-type: node
  deploy:
    needs: release
    if: steps.rp.outputs.release_created == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}
  notify:
    needs: [release, deploy]
    if: steps.rp.outputs.release_created == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: slackapi/slack-github-action@v3
        with:
          payload: '{"text":"Released ${{ needs.release.outputs.tag }} to production"}'
        env:
          SLACK_WEBHOOK_URL: "${{ secrets.SLACK_WEBHOOK }}"

Decision tree

1. External consumers? → Yes: strict semver. No: simplified versioning.
2. Monorepo? → Yes: changesets. Single package: release-please.
3. Publishing to registry? → Yes: automate publish in release workflow.
4. Need gradual rollout? → Yes: feature flags + canary deploys.
5. Need instant rollback? → Yes: Vercel rollback or blue-green. No: git revert.
6. Multiple environments? → Yes: GitHub environments with approval gates.

Edge cases and gotchas

• Changeset merge conflicts — multiple PRs creating changesets for the same package conflict; resolve by keeping both files (they merge at version time).
• Tag protection — restrict tag creation to the release workflow; manual tags desync from changelogs.
• Edge Config propagation — changes typically propagate quickly (sub-second to low hundreds of milliseconds); health checks may see brief stale values.
• Rollback + migrations — code rollback does not undo schema changes; use expand-contract pattern for safe migrations.
• Orphaned flags — flags left enabled after full rollout are invisible tech debt; set owner and expiry on every flag.
• Changelog drift — manual changelogs diverge within weeks; always automate from commits or changesets.
• Agent-signed commits — Copilot cloud agent now signs commits. If you rely on agent-created commits/releases, confirm how signed commits interact with your branch-protection rules and audit requirements (GitHub changelog, Apr 2026).

Evaluation criteria