菜单
Ships changes safely and often — pipelines, deployment strategies, feature flags, rollback, and database changes. Use this to design a deployment pipeline, reduce release risk, roll out a risky change gradually, plan a schema migration, or work out why releases are infrequent and frightening.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/cbrock84/headcount --skill release-and-deployment命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | release-and-deployment |
| description | Ships changes safely and often — pipelines, deployment strategies, feature flags, rollback, and database changes. Use this to design a deployment pipeline, reduce release risk, roll out a risky change gradually, plan a schema migration, or work out why releases are infrequent and frightening. |
Release risk is dominated by batch size. Large infrequent releases are dangerous because many changes land at once and nobody can tell which one broke it — so teams release less often, which makes each release larger. The loop is the problem.
Deploying code and exposing behavior to users are different acts, and coupling them forces every deployment to be a business decision.
Decouple with flags: deploy continuously, expose deliberately. This makes rollback a configuration change rather than a redeployment, which is the difference between seconds and minutes at the worst possible time.
Flags are inventory and rot. Give each an owner and a removal date; a codebase full of stale flags has combinatorial states nobody has tested.
Automate everything between commit and production, and let the pipeline reject. Manual steps get skipped under pressure, which is exactly when they matter.
Order gates fast-to-slow so failure is cheap: lint and unit tests, then integration, then anything requiring a deployed environment. A pipeline slow enough to be circumvented is worse than a fast one with fewer checks, because it will be circumvented.
Build once and promote the same artifact through environments. Rebuilding per environment means the thing you tested is not the thing you shipped.
Expose to a small population first and watch real signals before widening. Canary or percentage rollout turns a total failure into a contained one.
Define the abort condition before starting, with a threshold and a named decision-maker. Under pressure, and with the change fresh, the instinct is always to wait a little longer and see.
Code rolls back; data does not. Make schema changes backward-compatible and multi-step: add the new structure, write to both, migrate, switch reads, then remove the old — with the application tolerant of both shapes throughout.
Test the migration against production-scale data. A migration that is instant on a development dataset can lock a large table for a length of time nobody modeled.
Pipelines: GitHub Actions, GitLab CI, CircleCI, Buildkite, Jenkins, and similar.
Continuous delivery and progressive rollout: Argo CD, Flux, Spinnaker, and similar; feature flags for decoupling deploy from release — LaunchDarkly, Unleash, Split, and similar.
Schema migrations: Flyway, Liquibase, Alembic, and similar. Whichever you use, the property that matters is that migrations are versioned, ordered, and applied by the pipeline rather than by a person with a database client.
