Questions d'entretien CI/CD
1. Quelle est la différence entre CI, CD (Delivery) et CD (Deployment) ?
CI (Continuous Intégration) : les développeurs fusionnent leur code fréquemment (plusieurs fois par jour) dans une branche commune. Chaque merge declenche un build automatique et des tests. Objectif : détecter les erreurs rapidement. CD (Continuous Delivery) : le code est toujours dans un état déployable en production. Le déploiement reste une décision humaine (un clic). CD (Continuous Deployment) : chaque changement qui passe les tests est automatiquement deploye en production. La plupart des entreprises visent la Continuous Delivery.
2. Décrivez un pipeline CI/CD complet et ses étapes.
Pipeline typique : 1. Checkout (récupérer le code), 2. Install (dépendances), 3. Lint/Format (qualité du code), 4. Tests unitaires (rapides, première défense), 5. Build (compilation, création de l'artefact), 6. Tests d'intégration (avec services externes), 7. Security scan (SAST, dépendances vulnérables), 8. Push artefact (image Docker vers un registry), 9. Deploy staging (environnement de pre-production), 10. Tests E2E/smoke (vérification fonctionnelle), 11. Deploy production (avec stratégie canary/blue-green), 12. Post-deploy checks (health, métriques).
3. Comparez GitHub Actions, GitLab CI et Jenkins.
GitHub Actions : natif GitHub, YAML, marketplace d'actions, runners gratuits (2000 min/mois), idéal si votre code est sur GitHub. GitLab CI : natif GitLab, YAML (.gitlab-ci.yml), excellent pour le DevOps complet (registry, environments, monitoring integres), auto DevOps. Jenkins : open source, le plus ancien et flexible, plugins très riches, mais maintenance lourde (serveur à gérer), Groovy/Jenkinsfile. Pour les nouveaux projets, GitHub Actions ou GitLab CI sont recommandés pour leur simplicité.
4. Comment gérer les secrets dans un pipeline CI/CD ?
Ne jamais stocker de secrets en clair dans le code ou les fichiers de pipeline. Solutions : variables secretes du CI/CD (GitHub Actions secrets, GitLab CI variables marked as protected/masked), coffre-fort externe (HashiCorp Vault) avec injection dynamique, OIDC pour l'authentification cloud sans secret (GitHub Actions OIDC avec AWS/Azure/GCP). Bonnes pratiques : masquez les secrets dans les logs, limitez l'accès aux variables secretes, rotez régulièrement, et utilisez des tokens a durée de vie courte.
5. Qu'est-ce que le trunk-based development et comment l'implémenter ?
Le trunk-based development est une stratégie de branchement ou tous les développeurs travaillent sur une seule branche principale (main/trunk). Les branches de feature sont courtes (< 1-2 jours) et mergees fréquemment. Avantages : intégration continue réelle, moins de conflits de merge, déploiements fréquents. Implémentation : feature flags pour les fonctionnalités incompletes, revue de code sur les PR courtes, tests automatises robustes, et un pipeline CI rapide (< 10 minutes).
6. Comment implémenter le déploiement blue-green et canary ?
Blue-Green : deux environnements identiques. Déployez la nouvelle version sur l'environnement inactif, testez, puis basculez le trafic (load balancer ou DNS switch). Rollback instantané en rebasculant. Nécessite le double de ressources temporairement. Canary : déployez sur un petit pourcentage de serveurs/pods (5-10%), surveillez les métriques (erreurs, latence), puis augmentez progressivement (25%, 50%, 100%). Implémentation : Kubernetes avec Istio/Argo Rollouts, AWS CodeDeploy, ou Flagger.
7. Comment accélérer un pipeline CI/CD lent ?
Stratégies : paralleliser les étapes indépendantes (tests, linting, scans en parallèle), cache les dépendances (node_modules, pip, Maven repository), incremental builds (ne reconstruire que ce qui a change), tests selectifs (ne lancer que les tests affectes par les changements), runners puissants (plus de CPU/RAM), Docker layer caching pour les builds d'images, fail fast (arrêter le pipeline des le premier échec critique), et split les tests sur plusieurs runners (parallélisme de sharding).
8. Qu'est-ce que GitOps et comment l'implémenter ?
GitOps utilise Git comme source de verite pour l'infrastructure et les deployments. Un opérateur (ArgoCD, Flux) surveille un repository Git et reconcilie l'état du cluster avec le contenu du repo. Workflow : le développeur modifie un manifeste Kubernetes (ou Helm chart), cree une PR, l'équipe review, le merge declenche la reconciliation automatique. Avantages : audit complet (historique Git), rollback simple (revert), collaboration via PR. Implémentation typique : ArgoCD pour Kubernetes, avec des repos séparés pour le code et les manifestes.
9. Comment gérer les environnements (dev, staging, production) dans la CI/CD ?
Approches : branches par environnement (develop -> staging, main -> production — simple mais rigide), promotion d'artefacts (un seul artefact progresse dev -> staging -> prod — recommande), GitOps avec des dossiers par environnement (overlays Kustomize ou values Helm). Bonnes pratiques : les artefacts sont immutables (même image Docker partout), seule la configuration change par environnement (variables d'environnement, config maps), et les secrets sont injectes par l'environnement cible.
10. Quelles métriques surveiller pour évaluer l'efficacité de la CI/CD ?
Les 4 métriques DORA (DevOps Research and Assessment) : Deployment Frequency (fréquence des deployments en production — objectif : plusieurs fois par jour), Lead Time for Changes (temps entre le commit et le déploiement en production — objectif : < 1 heure), Change Failure Rate (pourcentage de deployments causant un incident — objectif : < 15%), Time to Restore (temps pour restaurer le service après un incident — objectif : < 1 heure). Ces métriques sont les meilleurs indicateurs de la maturité DevOps d'une organisation.