Communitygithub.com

lguidolin/résilience-et-sécurité-des-déploiements

Utilisez cette compétence lors de la planification d'un déploiement, de la conception d'un rollback, de la réponse à un incident ou de la rédaction d'un post-mortem. Mots-clés : sécurité de déploiement, rollback, artefact immuable, déploiement progressif, canary, rayon d'explosion, réponse aux incidents, post-mortem sans blâme, budget d'erreur.

Qu'est-ce que résilience-et-sécurité-des-déploiements ?

Cette compétence formalise les principes de résilience et de sécurité des déploiements pour les équipes d'ingénierie. Elle aborde la réversibilité des déploiements, l'utilisation d'artefacts immuables promus par digest (et non par tag), l'exposition progressive via canary ou rollout à santé contrôlée, et la séparation des modifications de schéma des déploiements de code. Elle définit également un processus de réponse aux incidents avec post-mortems sans blâme, un budget d'erreur qui priorise le travail sur la fiabilité, et une checklist de vérification avant déploiement en production. La compétence est conçue pour être indépendante de la plateforme : les mécanismes concrets (ex: sondes Kubernetes, canary, environnements par PR) sont délégués à des compétences de livraison spécifiques, tandis que les propriétés (build unique, promotion par digest, décision humaine avant production) restent universelles. Elle recommande de commencer tôt, même sur des projets locaux ou pré-lancement, puis d'activer les mécanismes appropriés lors de l'arrivée des premiers vrais utilisateurs.

Compatible avec~Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/resilience-and-deploy-safety
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Résilience et sécurité des déploiements

Vue d'ensemble

Les choses casseront. L'attitude n'est pas "empêcher toute panne" mais échouer petit, récupérer vite, et apprendre à chaque fois. La fiabilité n'est pas l'absence de panne ; c'est le rayon d'explosion limité et le temps de récupération court quand la panne survient.

Sécurité des déploiements — Chaque déploiement réversible et exposé progressivement

  • L'artefact est immuable et promu, pas reconstruit. Une seule image, construite une fois en CI et identifiée par son digest de contenu, se déplace preview → staging → production sans modification. Reconstruire par environnement revient à déployer quelque chose que vous n'avez jamais testé.
  • Les tags sont des pointeurs mutables ; le digest est l'identité. Un tag peut être écrasé et pointer silencieusement vers autre chose. Un digest de contenu ne le peut pas. Chaque environnement enregistre le digest qu'il a validé, et la production exécute seulement un digest qu'un environnement inférieur a validé — donc "l'objet exact que nous avons testé" est une propriété que le pipeline impose, pas une discipline que quelqu'un doit retenir.
  • Une décision humaine précède la production. Pour un mainteneur solo, c'est une pause délibérée et un enregistrement d'audit plutôt qu'une séparation des tâches. Dites clairement de quoi il s'agit ; ne le vendez pas trop.
  • La version en cours est injectée au moment du déploiement, jamais intégrée dans l'image. Une version intégrée comme argument de build force une reconstruction pour estampiller une release, et la reconstruction est exactement ce que la promotion vise à éviter.
  • Quand l'infrastructure vit dans son propre dépôt, coordonnez par expansion/contraction. L'infrastructure s'étend d'abord (de manière additive, rétrocompatible), l'application consomme la nouvelle capacité dans un déploiement ultérieur, et l'infrastructure se contracte seulement une fois qu'aucun artefact actif ne dépend de l'ancienne forme — la même discipline qu'un changement de schéma (voir zero-downtime-migrations). L'invariant : ne jamais livrer un artefact applicatif qui nécessite un changement d'infrastructure pas encore en place. Respecté, chaque dépôt est réversible indépendamment, ce qui rend le rollback gérable quand les deux sont décalés.
  • N'avancez que quand vous pouvez revenir en arrière. Un chemin de rollback existe et est testé avant qu'un changement risqué ne soit mis en production. "Comment annuler cela ?" est répondu dans le plan, pas pendant l'incident.
  • Le rollback consiste à redéployer le digest précédemment bon. Ce digest est toujours dans le registre et toujours immuable, donc revenir en arrière est une promotion inversée — jamais une reconstruction, et jamais une reconstruction "telle qu'elle était".
  • Exposition progressive. Les nouvelles versions atteignent les utilisateurs progressivement (déploiement à santé contrôlée, canary là où c'est supporté), donc une mauvaise release nuit à une fraction, pas à tout le monde.
  • Les modifications de schéma sont découplées des déploiements de code et suivent l'expansion/contraction (voir zero-downtime-migrations). Un déploiement ne doit jamais nécessiter une migration destructive simultanée.
  • Une checklist de préparation au déploiement vérifie la production : observabilité en place, rollback vérifié, migrations sûres pour l'expansion, SLOs non violés.

Réponse aux incidents — La panne est une entrée d'apprentissage

  • Classez par sévérité et répondez proportionnellement ; ayez un chemin connu pour impliquer les bonnes personnes.
  • Post-mortems sans blâme pour chaque incident visible par les utilisateurs. Chronologie écrite, causes contributives (systémiques, pas personnelles), actions concrètes. La question est "qu'est-ce que le système a permis qui a causé cela", jamais "qui a fait l'erreur".
  • Les actions sont suivies, pas oubliées — elles sont intégrées dans le document des considérations futures (voir recording-decisions) et deviennent du vrai travail.
  • Le budget d'erreur gouverne. Quand la fiabilité est épuisée, le travail de fiabilité prime sur les fonctionnalités jusqu'à ce que le budget se rétablisse.

Référence rapide

Avant un déploiement risquéÀ vérifier
ArtefactConstruit une fois en CI ; promu par digest ; le même que celui validé en staging
PorteUne décision humaine enregistrée avant la production
RollbackUn chemin existe et est testé
ExpositionGraduelle/canary, pas tout d'un coup
SchémaSécurisé pour l'expansion, découplé du déploiement de code
ObservabilitéPouvez-vous voir si ça tourne mal ?

Quand passer à l'échelle

Les projets locaux/pré-lancement écrivent ces règles maintenant, les activent dès les premiers vrais utilisateurs. Les propriétés sont portables — construire une fois, promouvoir ce que vous avez testé, décider avant la production, pouvoir revenir en arrière — mais les mécanismes ne le sont pas : une promotion par digest est pertinente sur un hôte conteneurisé et largement sans objet pour un site statique, et une plateforme managée peut fournir des environnements preview et un rollback instantané gratuitement. Nommez le mécanisme dans la compétence de livraison du projet ; conservez la propriété ici. Empilez les mécanismes (sondes Kubernetes, canary, environnements par PR) : cloud-delivery-aks.

Justification complète : Article XII de la constitution, regroupé dans engineering-constitution/references/engineering-constitution.md.

Individual skills in this repo

This repo contains 18 individual skills — each has its own dedicated page.

lguidolin/change-hygiene-and-code-craft

Use when writing or refactoring code, structuring a commit or PR, or deciding whether to abstract duplication. Symptoms — mixing reorg with logic changes, a PR doing several things at once, a file growing large, the second copy of similar code, or unsure whether to DRY something up.

lguidolin/cloud-delivery-aks

Use when deploying to Kubernetes or Azure Kubernetes Service (AKS), configuring cloud secrets, setting up progressive rollout/canary, per-PR ephemeral environments, or k8s health probes. Keywords — Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, canary, blue-green, liveness, readiness, PodDisruptionBudget, HPA, rollback, GHCR.

lguidolin/commit-history-rewrite

Use when an existing repository has messy commit history that needs to conform to conventional commits before adopting release-please, or when intermediate WIP/fixup/merge commits need to be cleaned up.

lguidolin/conventional-commits-and-releases

Use when committing, writing a commit message, opening a PR that will be squash-merged, or configuring automated versioning/changelogs. Keywords — conventional commits, release-please, semver, feat/fix/chore, breaking change, changelog.

lguidolin/defense-in-depth-security

Use when handling untrusted input, secrets, authentication/authorization, or dependencies — or threat-modeling a new surface. Keywords — STRIDE, threat model, least privilege, secrets management, supply chain, dependency scanning, input validation, audit log, defense in depth.

lguidolin/designing-before-building

Use when starting a feature, fixing a non-trivial bug, or about to write implementation code — before any code exists. Symptoms you need this: "this is simple, I'll just code it", reaching for the editor before a design is approved, or an idea that hasn't been turned into a spec and plan.

lguidolin/engineering-constitution

Use when starting work in a project that follows the engineering constitution, orienting to its rules, or deciding which engineering practice applies to a task — spec writing, commits, testing, security, deploys, database, or UI work.

lguidolin/graphql-contract-testing

Use when writing a GraphQL query/mutation that the UI and a test will share, or building route/schema contract or smoke tests. Symptoms — copying a query into a test, a test asserting on query text, schema change that didn't break the UI build, or RLS/permission drift. Keywords — graphql-codegen, typed document, contract test, route smoke test.

lguidolin/init-repo-CI

Use when setting up a new repository with conventional commits, release-please, and CI automation, or when retrofitting an existing repository that lacks automated versioning and PR validation workflows.

lguidolin/interface-craft-and-accessibility

Use when building or styling UI — components, layouts, forms, design tokens — or making accessibility decisions. Keywords — a11y, WCAG, keyboard navigation, focus state, contrast, design system, minimalist UI, component reuse, ARIA, semantic HTML.

lguidolin/merge-gates-and-automation

Use when setting up or changing CI, pre-push hooks, or a task runner, or deciding what must pass before merge. Symptoms — tempted to put authoritative checks only in a local hook, skip CI, bypass with --no-verify, or unsure what gates a merge vs. runs locally.

lguidolin/observability-and-slos

Use when adding logging, metrics, tracing, health checks, SLOs, or alerting — or when building a service surface that needs to be operable and debuggable. Keywords — structured logs, OpenTelemetry, correlation id, RED metrics, liveness, readiness, SLI, SLO, error budget, alerting.

lguidolin/performance-and-scale

Use when working on hot paths, list endpoints, pagination, data-access in loops, or public interfaces/schemas. Symptoms — unbounded queries, N+1 access, no latency budget, optimizing without measuring, or changing an interface many consumers depend on. Keywords — pagination, N+1, Hyrum's Law, performance budget, bundle size.

lguidolin/postgres-postgraphile-rls-and-sql

Use when writing PostgreSQL, PostGraphile config, Row-Level Security policies, SQL schema files, or working on the Browser→App→PostGraphile→Postgres data path. Keywords — RLS, SECURITY DEFINER, search_path, pgSettings, grants, roles, GraphQL depth limit, query cost, statement_timeout, SQL file organization.

lguidolin/recording-decisions

Use when a design or architecture decision has been made and needs to be captured — writing a decision record or ADR, updating a decision index, noting a deferred idea, or superseding a past decision. Keywords — ADR, decision record, rationale, rejected alternatives, dependency index.

lguidolin/ship-it

Use when the user wants to ship work — push, PR, archive decision records, merge, and clean up. Handles the full lifecycle from committing final changes through post-merge cleanup including converting specs/plans to compact decision records.

lguidolin/tests-as-a-control

Use when writing or modifying tests, when a test breaks during a refactor, or when testing permission/role rules. Symptoms — tempted to edit a test to make it pass, testing only the happy path, a deny-test that started passing, flaky tests, or unsure what to assert.

lguidolin/zero-downtime-migrations

Use when changing a database schema where data must survive the change — adding/removing/renaming columns, constraints, indexes, or backfilling. Symptoms — a destructive migration bundled with a code deploy, a NOT NULL column with a backfill, a table-locking UPDATE, or a rename. Keywords — expand/contract, parallel change, backfill, NOT VALID, CREATE INDEX CONCURRENTLY, graphile-migrate.

Skills associés

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community