IT Toolbox AI
CI/CD · Bonnes pratiques

Bonnes pratiques et Troubleshooting

Sécurisez vos pipelines et diagnostiquez méthodiquement build, tests, runners, artifacts et déploiements.

Leçon disponible
20 min

Objectifs

  • Appliquer les bonnes pratiques CI/CD de production.
  • Reconnaître dix causes d’échec fréquentes.
  • Suivre une méthode de diagnostic en dix étapes.
  • Protéger code, secrets, runners, dépendances et environnements.

Bonnes pratiques et Troubleshooting

Une pipeline fiable est versionnée, reproductible, observable et auditée. Elle traite de petits changements, arrête tôt les erreurs critiques et promeut un artifact immuable avec des permissions proportionnées.

Le troubleshooting commence par le stage en échec et la première erreur réelle. Relancer sans comprendre peut masquer un runner instable, consommer des ressources et répéter un déploiement dangereux.

Checklist de bonnes pratiques

Chaque contrôle doit répondre à un risque identifié et produire une preuve lisible. Les exceptions sont limitées, approuvées et traçables.

  • Versionner les pipelines dans Git et protéger les branches importantes.
  • Livrer de petits changements fréquents avec reviews.
  • Créer des builds reproductibles à partir de dépendances maîtrisées.
  • Automatiser tests, lint, analyse statique et scans adaptés.
  • Publier un artifact immuable puis promouvoir la même version.
  • Garder tokens et passwords hors du code dans un secret store.
  • Appliquer le moindre privilège aux jobs, runners et environnements.
  • Maintenir des environnements cohérents et une configuration séparée.
  • Ajouter logs, métriques, traces, health checks et alertes exploitables.
  • Exiger une approbation selon la criticité, pas par automatisme.
  • Préparer et tester rollback ou roll-forward avant PROD.
  • Conserver commit, artifact, approvals et déploiements pour l’auditabilité.

Sécurité de la chaîne CI/CD

Une pipeline exécute du code et accède parfois à des environnements sensibles. Elle fait donc partie de la surface d’attaque de la production.

  • Ne jamais hardcoder de token, password, clé ou credential.
  • Masquer les secrets dans les logs et éviter les commandes qui les réaffichent.
  • Valider et versionner les actions, plugins, images et dépendances tiers.
  • Isoler, mettre à jour et surveiller les runners auto-hébergés.
  • Utiliser des credentials temporaires et liés au job lorsque possible.
  • Restreindre qui peut modifier la pipeline et déployer en production.

Dix problèmes fréquents

Le statut du job indique où chercher, mais la cause utile se trouve souvent dans la première erreur et non dans les messages en cascade.

  • 1. Build failed : compilation, configuration ou script invalide.
  • 2. Dependency unavailable : registry, proxy, réseau ou version absente.
  • 3. Tests failed : régression réelle, environnement ou test instable.
  • 4. Runner unavailable : capacité, labels, maintenance ou connectivité.
  • 5. Permission denied : token, filesystem ou rôle insuffisant.
  • 6. Secret missing : nom, scope, environnement ou protection incorrects.
  • 7. Artifact missing : build non publié, expiré ou mauvaise version.
  • 8. Deployment timeout : rollout bloqué, capacité ou dépendance lente.
  • 9. Health check failed : port, path, configuration ou application non prête.
  • 10. Production deployment failed : cible, permission, configuration ou incompatibilité.

Méthode de diagnostic en dix étapes

Travaillez sur une copie sûre des logs et ne publiez jamais une valeur sensible. Corrigez la cause minimale, puis relancez uniquement les jobs nécessaires lorsque la plateforme le permet.

  • 1. Identifier le stage et le job en échec.
  • 2. Lire les logs complets du job concerné.
  • 3. Repérer la première erreur réelle avant les erreurs en cascade.
  • 4. Vérifier commit, branche, tag et version de pipeline.
  • 5. Vérifier lockfiles, registries, réseau et dépendances.
  • 6. Vérifier variables et présence des secrets sans les afficher.
  • 7. Vérifier version, checksum, provenance et disponibilité de l’artifact.
  • 8. Vérifier droits, capacité, configuration et santé de l’environnement cible.
  • 9. Reproduire dans un environnement sûr avec les mêmes entrées maîtrisées.
  • 10. Corriger, documenter puis relancer seulement ce qui est nécessaire.

Ne relancez pas aveuglément une pipeline. Un nouvel essai peut répéter un effet partiel, masquer la cause ou aggraver un incident de production.

Décider et vérifier

Si l’échec survient avant publication, corrigez le source ou l’environnement de build. Si l’artifact est publié mais non déployé, vérifiez sa provenance. Si PROD est impactée, appliquez la procédure d’incident et choisissez rollback ou roll-forward.

  • Conserver les logs utiles avec leurs timestamps et identifiants de job.
  • Comparer la dernière exécution réussie et le premier échec.
  • Vérifier après correction les smoke tests et métriques métier.
  • Transformer l’incident en test, alerte ou garde-fou durable.

Mini résumé

  • Pipelines versionnées, petits changements, tests et artifacts immuables rendent le flux prévisible.
  • Secret stores, moindre privilège, reviews et runners protégés réduisent le risque de chaîne logicielle.
  • Les dix problèmes fréquents couvrent build, dépendances, tests, runner, droits, secrets, artifacts et déploiement.
  • Le diagnostic suit une preuve à la fois et ne relance que le périmètre nécessaire.

Outils associés

Analyser les logs d’un job

Utilisez Log Analyzer pour repérer localement erreurs, warnings et problèmes fréquents dans les logs d’une pipeline ou d’un déploiement.

Ouvrir l’outil

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Où faut-il conserver un token de déploiement ?
2. Quel élément faut-il chercher en priorité dans des logs en échec ?
3. Pourquoi éviter une relance aveugle de pipeline ?