61 lines
2.8 KiB
Plaintext
61 lines
2.8 KiB
Plaintext
---
|
|
title: Principes de la CI/CD
|
|
description: Comprendre la chaîne qui transforme un changement en version déployable.
|
|
---
|
|
|
|
CI/CD désigne un ensemble de pratiques, pas un outil. GitHub Actions, GitLab CI ou Jenkins exécutent la chaîne, mais sa valeur vient surtout de règles simples : retours rapides, branche principale saine et livraison reproductible.
|
|
|
|
## CI et CD ne font pas le même travail
|
|
|
|
| Étape | Question | Résultat |
|
|
| --- | --- | --- |
|
|
| intégration continue (CI) | le changement est-il valide ? | code testé et branche principale saine |
|
|
| livraison continue | cette version peut-elle être livrée ? | artefact versionné et prêt |
|
|
| déploiement continu (CD) | la version doit-elle être mise en ligne ? | production mise à jour et vérifiée |
|
|
|
|
Une équipe peut automatiser la livraison tout en gardant une approbation manuelle avant la production. Le « D » de CD ne signifie donc pas toujours déploiement automatique.
|
|
|
|
## Les trois propriétés recherchées
|
|
|
|
### Une branche principale toujours livrable
|
|
|
|
Les branches restent courtes, les changements petits et les contrôles obligatoires avant fusion. Une erreur est plus simple à comprendre lorsqu'elle porte sur quelques commits.
|
|
|
|
### Des boucles de retour rapides
|
|
|
|
Lance d'abord les vérifications rapides : formatage, lint et tests unitaires. Les builds Docker et tests e2e plus coûteux viennent ensuite. Un développeur doit savoir rapidement si son changement peut avancer.
|
|
|
|
### Un artefact unique
|
|
|
|
La CI produit une image versionnée. La recette de production déploie cette même image ; elle ne reconstruit pas le projet sur le serveur.
|
|
|
|
```text
|
|
commit → contrôles → image versionnée → registry → déploiement → vérification
|
|
```
|
|
|
|
## Répartir les responsabilités
|
|
|
|
| Niveau | Exemples |
|
|
| --- | --- |
|
|
| poste du développeur | formatage, lint, tests ciblés, hooks Git |
|
|
| pull request | lint complet, tests, build, revue |
|
|
| branche principale | image candidate, scans et tests d'intégration |
|
|
| version | publication dans le registry |
|
|
| environnement | approbation éventuelle, déploiement, smoke test |
|
|
|
|
Les hooks Git améliorent le confort local, mais la CI reste la source de vérité : un hook peut être désactivé ou ne pas exister sur une autre machine.
|
|
|
|
## Une politique minimale efficace
|
|
|
|
- aucune fusion si un contrôle obligatoire échoue ;
|
|
- aucun déploiement depuis une branche non approuvée ;
|
|
- chaque image porte un tag immuable ;
|
|
- les secrets sont limités à l'environnement qui en a besoin ;
|
|
- un seul déploiement de production s'exécute à la fois ;
|
|
- chaque mise en ligne possède une vérification et un rollback.
|
|
|
|
<Callout title="La confiance vient de la répétition" type="info">
|
|
Une petite pipeline exécutée à chaque changement protège mieux qu'une longue procédure manuelle lancée seulement avant une grosse livraison.
|
|
</Callout>
|
|
|