| Canary | Low | Routing change | High-traffic production |
| Feature flags | Lowest | Toggle off | Decouple deploy from release |
| Rolling | Medium | Deploy previous | Stateless services |
+
+## 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:
```bash
pnpm add -D @changesets/cli @changesets/changelog-github
pnpm changeset init
```
+
+Example config (keep the schema version matched to the installed package):
```json
// .changeset/config.json
@@ −60 +74 @@
"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):
```yaml
# .github/workflows/release.yml
name: Release
+on:
+ push:
+ branches: [main]
+
+permissions:
+ contents: write # required to create tags/releases
−on: { push: { branches: [main] } }
+ pull-requests: write
−permissions: { contents: write, pull-requests: write }
jobs:
release:
runs-on: ubuntu-latest
− outputs:
− created: ${{ steps.rp.outputs.release_created }}
− tag: ${{ steps.rp.outputs.tag_name }}
steps:
+ - uses: actions/checkout@v4
− - uses: googleapis/release-please-action@7987652d64b4581673a76e33ad5e98e3dd56571f
+ - 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).
− publish:
+- Keep the action pinned to a major tag (e.g., @v4) and update regularly for security/permission changes.
