Questions d'entretien CI/CD
1. Quelle est la difference entre CI, CD (Delivery) et CD (Deployment) ?
CI (Continuous Integration) : les developpeurs fusionnent leur code frequemment (plusieurs fois par jour) dans une branche commune. Chaque merge declenche un build automatique et des tests. Objectif : detecter les erreurs rapidement. CD (Continuous Delivery) : le code est toujours dans un etat deployable en production. Le deploiement reste une decision 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. Decrivez un pipeline CI/CD complet et ses etapes.
Pipeline typique : 1. Checkout (recuperer le code), 2. Install (dependances), 3. Lint/Format (qualite du code), 4. Tests unitaires (rapides, premiere defense), 5. Build (compilation, creation de l'artefact), 6. Tests d'integration (avec services externes), 7. Security scan (SAST, dependances vulnerables), 8. Push artefact (image Docker vers un registry), 9. Deploy staging (environnement de pre-production), 10. Tests E2E/smoke (verification fonctionnelle), 11. Deploy production (avec strategie canary/blue-green), 12. Post-deploy checks (health, metriques).
3. Comparez GitHub Actions, GitLab CI et Jenkins.
GitHub Actions : natif GitHub, YAML, marketplace d'actions, runners gratuits (2000 min/mois), ideal 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 tres riches, mais maintenance lourde (serveur a gerer), Groovy/Jenkinsfile. Pour les nouveaux projets, GitHub Actions ou GitLab CI sont recommandes pour leur simplicite.
4. Comment gerer 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'acces aux variables secretes, rotez regulierement, et utilisez des tokens a duree de vie courte.
5. Qu'est-ce que le trunk-based development et comment l'implementer ?
Le trunk-based development est une strategie de branchement ou tous les developpeurs travaillent sur une seule branche principale (main/trunk). Les branches de feature sont courtes (< 1-2 jours) et mergees frequemment. Avantages : integration continue reelle, moins de conflits de merge, deploiements frequents. Implementation : feature flags pour les fonctionnalites incompletes, revue de code sur les PR courtes, tests automatises robustes, et un pipeline CI rapide (< 10 minutes).
6. Comment implementer le deploiement blue-green et canary ?
Blue-Green : deux environnements identiques. Deployez la nouvelle version sur l'environnement inactif, testez, puis basculez le trafic (load balancer ou DNS switch). Rollback instantane en rebasculant. Necessite le double de ressources temporairement. Canary : deployez sur un petit pourcentage de serveurs/pods (5-10%), surveillez les metriques (erreurs, latence), puis augmentez progressivement (25%, 50%, 100%). Implementation : Kubernetes avec Istio/Argo Rollouts, AWS CodeDeploy, ou Flagger.
7. Comment accelerer un pipeline CI/CD lent ?
Strategies : paralleliser les etapes independantes (tests, linting, scans en parallele), cache les dependances (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 (arreter le pipeline des le premier echec critique), et split les tests sur plusieurs runners (parallelisme de sharding).
8. Qu'est-ce que GitOps et comment l'implementer ?
GitOps utilise Git comme source de verite pour l'infrastructure et les deployments. Un operateur (ArgoCD, Flux) surveille un repository Git et reconcilie l'etat du cluster avec le contenu du repo. Workflow : le developpeur modifie un manifeste Kubernetes (ou Helm chart), cree une PR, l'equipe review, le merge declenche la reconciliation automatique. Avantages : audit complet (historique Git), rollback simple (revert), collaboration via PR. Implementation typique : ArgoCD pour Kubernetes, avec des repos separes pour le code et les manifestes.
9. Comment gerer 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 (meme 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 metriques surveiller pour evaluer l'efficacite de la CI/CD ?
Les 4 metriques DORA (DevOps Research and Assessment) : Deployment Frequency (frequence des deployments en production — objectif : plusieurs fois par jour), Lead Time for Changes (temps entre le commit et le deploiement en production — objectif : < 1 heure), Change Failure Rate (pourcentage de deployments causant un incident — objectif : < 15%), Time to Restore (temps pour restaurer le service apres un incident — objectif : < 1 heure). Ces metriques sont les meilleurs indicateurs de la maturite DevOps d'une organisation.