addyosmani/agent-skills

Livraison et Lancement

Aperçu

Livrez en toute confiance. L'objectif n'est pas seulement de déployer, mais de déployer en toute sécurité, avec une surveillance en place, un plan de rollback prêt et une compréhension claire de ce à quoi ressemble le succès. Chaque lancement doit être réversible, observable et incrémental.

Quand l'utiliser

• Déploiement d'une fonctionnalité en production pour la première fois
• Publication d'un changement significatif pour les utilisateurs
• Migration de données ou d'infrastructure
• Ouverture d'un programme bêta ou d'accès anticipé
• Tout déploiement qui comporte des risques (ils en comportent tous)

La Liste de Contrôle Pré-Lancement

Qualité du Code

• Tous les tests passent (unitaires, intégration, e2e)
• La build réussit sans avertissements
• Linting et vérification de types passent
• Code relu et approuvé
• Aucun commentaire TODO qui devrait être résolu avant le lancement
• Aucune instruction console.log de débogage dans le code de production
• La gestion des erreurs couvre les modes de défaillance attendus

Sécurité

• Aucun secret dans le code ou le contrôle de version
• L'audit des dépendances de l'écosystème (npm audit, pip-audit, cargo audit, ...) ne montre aucune vulnérabilité critique ou élevée
• Validation des entrées sur tous les points de terminaison exposés aux utilisateurs
• Vérifications d'authentification et d'autorisation en place
• En-têtes de sécurité configurés (CSP, HSTS, etc.)
• Limitation de débit sur les points de terminaison d'authentification
• CORS configuré pour des origines spécifiques (pas de caractère générique)

Performances

• Core Web Vitals dans les seuils "Bon"
• Pas de requêtes N+1 dans les chemins critiques
• Images optimisées (compression, tailles responsives, chargement différé)
• Taille du bundle dans le budget
• Les requêtes de base de données ont des index appropriés
• Mise en cache configurée pour les actifs statiques et les requêtes répétées

Accessibilité

• La navigation au clavier fonctionne pour tous les éléments interactifs
• Le lecteur d'écran peut transmettre le contenu et la structure de la page
• Le contraste des couleurs respecte WCAG 2.1 AA (4.5:1 pour le texte)
• La gestion du focus est correcte pour les modales et le contenu dynamique
• Les messages d'erreur sont descriptifs et associés aux champs du formulaire
• Aucun avertissement d'accessibilité dans axe-core ou Lighthouse

Infrastructure

• Variables d'environnement définies en production
• Migrations de base de données appliquées (ou prêtes à être appliquées)
• DNS et SSL configurés
• CDN configuré pour les actifs statiques
• Journalisation et signalement d'erreurs configurés
• Point de terminaison de vérification de santé existe et répond

Documentation

• README mis à jour avec les nouvelles exigences d'installation
• Documentation de l'API à jour
• ADR rédigés pour toute décision architecturale
• Changelog mis à jour
• Documentation destinée aux utilisateurs mise à jour (le cas échéant)

Stratégie de Feature Flag

Livrez derrière des feature flags pour découpler le déploiement de la publication :

// Vérification du feature flag
const flags = await getFeatureFlags(userId);

if (flags.taskSharing) {
  // Nouvelle fonctionnalité : partage de tâches
  return <TaskSharingPanel task={task} />;
}

// Comportement par défaut : comportement existant
return null;

Cycle de vie d'un feature flag :

1. DÉPLOYER avec le flag OFF     → Le code est en production mais inactif
2. ACTIVER pour l'équipe/bêta     → Tests internes dans l'environnement de production
3. DÉPLOIEMENT PROGRESSIF          → 5% → 25% → 50% → 100% des utilisateurs
4. SURVEILLER à chaque étape       → Surveiller les taux d'erreur, les performances, les retours utilisateurs
5. NETTOYER                        → Supprimer le flag et le code mort après le déploiement complet

Règles :

• Chaque feature flag a un propriétaire et une date d'expiration
• Nettoyez les flags dans les 2 semaines suivant le déploiement complet
• N'imbriquez pas les feature flags (crée des combinaisons exponentielles)
• Testez les deux états du flag (activé et désactivé) dans l'IC

Déploiement Progressif

La Séquence de Déploiement

1. DÉPLOYER sur staging
   └── Suite de tests complète dans l'environnement de staging
   └── Test manuel de vérification des flux critiques

2. DÉPLOYER en production (feature flag OFF)
   └── Vérifier que le déploiement a réussi (vérification de santé)
   └── Vérifier la surveillance des erreurs (aucune nouvelle erreur)

3. ACTIVER pour l'équipe (flag ON pour les utilisateurs internes)
   └── L'équipe utilise la fonctionnalité en production
   └── Fenêtre de surveillance de 24 heures

4. DÉPLOIEMENT CANARY (flag ON pour 5% des utilisateurs)
   └── Surveiller les taux d'erreur, la latence, le comportement des utilisateurs
   └── Comparer les métriques : canary vs. ligne de base
   └── Fenêtre de surveillance de 24 à 48 heures
   └── Avancer uniquement si tous les seuils sont respectés (voir tableau ci-dessous)

5. AUGMENTATION PROGRESSIVE (25% -> 50% -> 100%)
   └── Même surveillance à chaque étape
   └── Possibilité de revenir au pourcentage précédent à tout moment

6. DÉPLOIEMENT COMPLET (flag ON pour tous les utilisateurs)
   └── Surveiller pendant 1 semaine
   └── Nettoyer le feature flag

Seuils de Décision de Déploiement

Utilisez ces seuils pour décider d'avancer, de maintenir ou de revenir en arrière à chaque étape :

Métrique	Avancer (vert)	Maintenir et enquêter (jaune)	Revenir en arrière (rouge)
Taux d'erreur	Dans les 10% de la ligne de base	10 à 100% au-dessus de la ligne de base	>2x la ligne de base
Latence P95	Dans les 20% de la ligne de base	20 à 50% au-dessus de la ligne de base	>50% au-dessus de la ligne de base
Erreurs JS côté client	Aucun nouveau type d'erreur	Nouvelles erreurs à <0,1% des sessions	Nouvelles erreurs à >0,1% des sessions
Métriques métier	Neutre ou positif	Baisse <5% (peut être du bruit)	Baisse >5%

Quand Revenir en Arrière

Revenez en arrière immédiatement si :

• Le taux d'erreur augmente de plus de 2x la ligne de base
• La latence P95 augmente de plus de 50%
• Les problèmes signalés par les utilisateurs augmentent
• Des problèmes d'intégrité des données sont détectés
• Une vulnérabilité de sécurité est découverte

Surveillance et Observabilité

Ce qu'il faut Surveiller

Métriques applicatives :
├── Taux d'erreur (total et par point de terminaison)
├── Temps de réponse (p50, p95, p99)
├── Volume de requêtes
├── Utilisateurs actifs
└── Métriques métier clés (conversion, engagement)

Métriques d'infrastructure :
├── Utilisation du CPU et de la mémoire
├── Utilisation du pool de connexions à la base de données
├── Espace disque
├── Latence réseau
└── Profondeur de la file d'attente (le cas échéant)

Métriques client :
├── Core Web Vitals (LCP, INP, CLS)
├── Erreurs JavaScript
├── Taux d'erreur d'API du point de vue client
└── Temps de chargement de la page

Signalement d'Erreurs

// Mettre en place une boundary d'erreur avec signalement
class ErrorBoundary extends React.Component {
  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Signaler au service de suivi des erreurs
    reportError(error, {
      componentStack: info.componentStack,
      userId: getCurrentUser()?.id,
      page: window.location.pathname,
    });
  }

  render() {
    if (this.state.hasError) {
      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
    }
    return this.props.children;
  }
}

// Signalement d'erreurs côté serveur
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  reportError(err, {
    method: req.method,
    url: req.url,
    userId: req.user?.id,
  });

  // Ne pas exposer les détails internes aux utilisateurs
  res.status(500).json({
    error: { code: 'INTERNAL_ERROR', message: 'Une erreur est survenue' },
  });
});

Vérification Post-Lancement

Dans la première heure après le lancement :

1. Vérifier que le point de terminaison de santé renvoie 200
2. Vérifier le tableau de bord de surveillance des erreurs (aucun nouveau type d'erreur)
3. Vérifier le tableau de bord de latence (aucune régression)
4. Tester manuellement le flux utilisateur critique
5. Vérifier que les journaux circulent et sont lisibles
6. Confirmer que le mécanisme de rollback fonctionne (essai à sec si possible)

Porte de Libération par Budget d'Erreur

Le budget d'erreur de votre service (la fraction de requêtes ou de temps que votre SLO autorise à échouer) détermine s'il est sûr de livrer. Utilisez-le comme une porte objective, pas une négociation :

Budget restant > 20%  →  Livrer normalement ; surveiller attentivement
Budget restant 0–20%  →  Déploiements lents uniquement ; pas de changements à haut risque
Budget épuisé         →  Geler le travail sur les fonctionnalités ; se concentrer uniquement sur la fiabilité
Budget réinitialisé   →  Reprendre le rythme normal ; intégrer le correctif qui l'a récupéré

Un taux de consommation élevé pendant un canary (consommant le budget plus rapidement que le rythme de base) est un signal de maintien dans le tableau des seuils de déploiement ci-dessus — traitez-le comme un taux d'erreur élevé.

Stratégie de Rollback

Chaque déploiement a besoin d'un plan de rollback avant d'avoir lieu :

## Plan de Rollback pour [Fonctionnalité/Lancement]

### Conditions de Déclenchement
- Taux d'erreur > 2x ligne de base
- Latence P95 > [X]ms
- Signalements d'utilisateurs de [problème spécifique]

### Étapes de Rollback
1. Désactiver le feature flag (si applicable)
   OU
1. Déployer la version précédente : `git revert <commit> && git push`
2. Vérifier le rollback : vérification de santé, surveillance des erreurs
3. Communiquer : notifier l'équipe du rollback

### Considérations sur la Base de Données
- La migration [X] a un rollback : `npx prisma migrate rollback`
- Données insérées par la nouvelle fonctionnalité : [conservées / nettoyées]

### Délai de Rollback
- Feature flag : < 1 minute
- Redéploiement de la version précédente : < 5 minutes
- Rollback de base de données : < 15 minutes

Voir Aussi

• Pour la Définition de Fini à l'échelle du projet que chaque changement doit respecter avant cette checklist, voir ../../references/definition-of-done.md
• Pour les vérifications de sécurité pré-lancement, voir ../../references/security-checklist.md
• Pour la checklist de performances pré-lancement, voir ../../references/performance-checklist.md
• Pour la vérification de l'accessibilité avant le lancement, voir ../../references/accessibility-checklist.md
• Pour les règles d'alerte et les seuils liés au SLO, voir observability-and-instrumentation

Rationalisations Courantes

Rationalisation	Réalité
"Ça marche en staging, ça marchera en production"	La production a des données, des modèles de trafic et des cas limites différents. Surveiller après le déploiement.
"Nous n'avons pas besoin de feature flags pour ça"	Chaque fonctionnalité bénéficie d'un interrupteur d'arrêt d'urgence. Même les changements "simples" peuvent casser des choses.
"La surveillance, c'est de la surcharge"	Ne pas avoir de surveillance, c'est découvrir les problèmes par les plaintes des utilisateurs au lieu des tableaux de bord.
"Nous ajouterons la surveillance plus tard"	Ajoutez-la avant le lancement. Vous ne pouvez pas déboguer ce que vous ne pouvez pas voir.
"Revenir en arrière, c'est admettre un échec"	Revenir en arrière, c'est de l'ingénierie responsable. Livrer une fonctionnalité cassée, c'est l'échec.
"Le taux d'erreur a l'air correct, continuons à livrer"	Vérifiez le taux de consommation, pas seulement le taux d'erreur actuel. Consommer le budget plus rapidement que la ligne de base est un signal de maintien, même si les seuils individuels sont verts.

Drapeaux Rouges

• Déployer sans plan de rollback
• Aucune surveillance ou signalement d'erreurs en production
• Lancements big-bang (tout à la fois, sans staging)
• Feature flags sans date d'expiration ni propriétaire
• Personne ne surveille le déploiement pendant la première heure
• Configuration de l'environnement de production faite de mémoire, pas par code
• "C'est vendredi après-midi, livrons-le"
• Budget d'erreur épuisé mais le travail sur les fonctionnalités continue inchangé

Vérification

Avant de déployer :

• Checklist pré-lancement complétée (toutes les sections vertes)
• Feature flag configuré (si applicable)
• Plan de rollback documenté
• Tableaux de bord de surveillance mis en place
• Équipe notifiée du déploiement

Après le déploiement :

• La vérification de santé renvoie 200
• Le taux d'erreur est normal
• La latence est normale
• Le flux utilisateur critique fonctionne
• Les journaux circulent
• Rollback testé ou vérifié prêt

Pour chaque service livré :

• Politique de budget d'erreur en place : savoir quelle action entreprendre lorsque le budget descend en dessous de 20 % et lorsqu'il est épuisé