5.1 - CI/CD et intégration continue
L'objectif 5.1 du Cloud+ CV0-004 couvre les pipelines CI/CD. L'intégration continue (CI) construit et teste automatiquement le code à chaque commit pour attraper les problèmes tôt, tant que les changements sont petits et faciles à corriger. La livraison continue garde chaque build réussi prêt à publier avec une approbation manuelle, tandis que le déploiement continu pousse automatiquement chaque build réussi jusqu'en production sans validation manuelle. En développement trunk-based, les développeurs commitent surtout sur une seule branche principale par petits changements fréquents plutôt que de maintenir de longues branches de fonctionnalité ; fusionner souvent réduit surtout les conflits de fusion douloureux. Tu dois aussi connaître les pipelines, les étapes, les tests automatisés et les artefacts. Attends-toi à des mises en situation décrivant build+test à chaque commit, publication auto en production, ou une stratégie de branches, et demandant la bonne pratique.
Build + test à chaque commit = intégration continue. Pousser auto chaque build réussi en prod (sans validation) = déploiement continu (avec validation = livraison continue). Commiter sur une branche principale, petit + souvent = trunk-based (moins de conflits de fusion).
Questions d'entraînement
1. Compiler et tester le code automatiquement à chaque commit pour détecter tôt les problèmes, c'est :
- Intégration continue (bonne réponse)
- Surveillance continue
- Dérive de configuration
- Livraison manuelle
L'intégration continue (CI) fusionne et compile/teste automatiquement les changements fréquemment, détectant tôt les défauts. La livraison/le déploiement continu automatisent ensuite la mise en production.
2. Les développeurs commettent de petits changements directement sur une seule branche principale partagée plusieurs fois par jour. Ce modèle est :
- Développement basé sur le tronc (bonne réponse)
- Modèle de branches GitFlow
- Flux basé sur les forks
- Stratégie de branches de version
Le développement basé sur le tronc garde une seule ligne principale à branches éphémères avec de petites fusions fréquentes, facilitant l'intégration continue. GitFlow utilise plutôt des branches develop et release durables.
3. Pousser automatiquement chaque build validé jusqu'en production sans validation manuelle, c'est :
- Intégration continue
- Déploiement continu (bonne réponse)
- Surveillance continue
- Sauvegarde continue
Le déploiement continu met en production chaque changement qui passe les tests automatisés. La livraison continue s'arrête à un artefact prêt nécessitant une approbation manuelle.
4. Fusionner fréquemment une branche de fonctionnalité vers la ligne principale par petits changements réduit surtout :
- La couverture de tests
- Les conflits de fusion (bonne réponse)
- L'historique de commits
- La vitesse de build
Des fusions fréquentes et petites gardent les branches proches de la principale, donc les conflits restent petits et rares, une pratique clé de la CI. Les branches longues divergent et créent des fusions pénibles.
5. Garder des branches courtes fusionnées dans la principale derrière des drapeaux masqués est une forme de :
- Une livraison big-bang groupée
- Dérive de configuration
- Développement basé sur le tronc (bonne réponse)
- Validation manuelle par approbation
Le développement basé sur le tronc fait intégrer tout le monde fréquemment dans la principale, masquant le travail inachevé derrière des drapeaux pour éviter les branches longues. Cela soutient l'intégration continue.
6. Dans un pipeline CI/CD, quelle étape s'exécute en général juste après l'étape de build ?
- Provisionner le matériel
- Archiver sur bande
- Tests automatisés (bonne réponse)
- Rotation de clés
Après le build, le pipeline exécute des tests automatisés pour valider l'artefact avant l'empaquetage et le déploiement. La rotation de clés et l'archivage sur bande ne sont pas des étapes standard.