Update to Headcount: Technology

{
  "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.",
  "included_files": [
    {
      "relative_path": "references/sources.md",
      "size_in_bytes": 882
    }
  ],
  "name": "release-and-deployment",
  "skill_md_contents": "---\nname: release-and-deployment\ndescription: 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.\n---\n\n# Release and deployment\n\nRelease risk is dominated by batch size. Large infrequent releases are dangerous because many changes\nland at once and nobody can tell which one broke it — so teams release less often, which makes each\nrelease larger. The loop is the problem.\n\n## Separate deploy from release\n\nDeploying code and exposing behavior to users are different acts, and coupling them forces every\ndeployment to be a business decision.\n\nDecouple with flags: deploy continuously, expose deliberately. This makes rollback a configuration\nchange rather than a redeployment, which is the difference between seconds and minutes at the worst\npossible time.\n\nFlags are inventory and rot. Give each an owner and a removal date; a codebase full of stale flags\nhas combinatorial states nobody has tested.\n\n## The pipeline is the quality gate\n\nAutomate everything between commit and production, and let the pipeline reject. Manual steps get\nskipped under pressure, which is exactly when they matter.\n\nOrder gates fast-to-slow so failure is cheap: lint and unit tests, then integration, then anything\nrequiring a deployed environment. A pipeline slow enough to be circumvented is worse than a fast one\nwith fewer checks, because it will be circumvented.\n\nBuild once and promote the same artifact through environments. Rebuilding per environment means the\nthing you tested is not the thing you shipped.\n\n## Roll out gradually\n\nExpose to a small population first and watch real signals before widening. Canary or percentage\nrollout turns a total failure into a contained one.\n\nDefine the abort condition **before** starting, with a threshold and a named decision-maker. Under\npressure, and with the change fresh, the instinct is always to wait a little longer and see.\n\n## Database changes are the asymmetric risk\n\nCode rolls back; data does not. Make schema changes backward-compatible and multi-step: add the new\nstructure, write to both, migrate, switch reads, then remove the old — with the application tolerant\nof both shapes throughout.\n\nTest the migration against production-scale data. A migration that is instant on a development\ndataset can lock a large table for a length of time nobody modeled.\n\n## Sources\n\n`references/sources.md` in this skill lists the outside authorities that settle the questions\nhere — what each one is authoritative for, and what you may do with it. Check them before\nanswering on anything they cover, and cite what you used. Most are free to read and not free\nto reproduce; the use note on each is binding.\n\n## Tooling\n\nPipelines: GitHub Actions, GitLab CI, CircleCI, Buildkite, Jenkins, and similar.\n\nContinuous delivery and progressive rollout: Argo CD, Flux, Spinnaker, and similar; feature flags\nfor decoupling deploy from release — LaunchDarkly, Unleash, Split, and similar.\n\nSchema migrations: Flyway, Liquibase, Alembic, and similar. Whichever you use, the property that\nmatters is that migrations are versioned, ordered, and applied by the pipeline rather than by a\nperson with a database client.\n\n## Never\n\n- Couple deploying code to exposing behavior.\n- Promote a different artifact than the one that was tested.\n- Begin a rollout without a defined abort condition.\n- Ship a schema change that requires the application and database to deploy simultaneously.\n"
}