Intégration et déploiement continus (CI/CD)

Questions fréquentes

C'est quoi l'intégration continue ?

L'intégration continue (CI) est une pratique de développement : chaque développeur intègre son travail dans la branche commune plusieurs fois par jour, et chaque intégration est vérifiée automatiquement par un pipeline qui installe les dépendances, analyse le code et lance les tests. Une erreur est ainsi détectée quelques minutes après le commit, au lieu du jour de la livraison. Les outils les plus courants sont GitHub Actions, GitLab CI et Jenkins (la CI/CD expliquée).

Quelle est la différence entre CI et CD ?

La CI vérifie automatiquement chaque modification du code (construction, analyse, tests). Le CD prolonge la CI jusqu'à la mise en ligne : en livraison continue, chaque version validée est prête et déployée en recette, mais la mise en production reste une décision humaine ; en déploiement continu, elle part automatiquement en production. La seule différence entre les deux CD est cette barrière humaine (livraison et déploiement continus).

C'est quoi un pipeline CI/CD ?

Un pipeline est la suite automatisée d'étapes qui transforme un commit en version livrée : récupération du code, installation, lint, tests, construction, analyse de sécurité, empaquetage, publication, déploiement. Chaque étape est une commande ; si elle renvoie un code d'erreur, le pipeline s'arrête. On place les étapes rapides en premier pour échouer vite (les étapes d'un pipeline).

GitHub Actions est-il gratuit ?

Oui pour les dépôts publics : les runners standards de GitHub y sont gratuits et illimités. Pour les dépôts privés, l'offre gratuite inclut chaque mois un crédit équivalent à environ 2 000 minutes sur Linux et 500 Mo de stockage d'artefacts ; Windows et macOS consomment ce crédit plus vite. Les étudiants obtiennent GitHub Pro avec le GitHub Student Developer Pack (les runners et leur coût).

Quelle différence entre GitHub Actions et GitLab CI ?

Les notions sont les mêmes (pipeline, jobs, runners, artefacts, secrets), la syntaxe diffère. GitHub Actions répartit le pipeline dans plusieurs fichiers .github/workflows/*.yml et réutilise des actions publiées ; GitLab CI utilise un seul .gitlab-ci.yml, organisé en stages, où chaque job tourne dans une image Docker. GitLab s'installe facilement dans l'entreprise, ce qui explique sa présence dans les administrations (GitLab CI et ses équivalences).

Comment stocker un mot de passe dans un pipeline ?

Jamais dans le fichier du workflow ni dans le code : dans les secrets de la forge (Settings, Secrets and variables, Actions sur GitHub ; Settings, CI/CD, Variables sur GitLab). Le secret est chiffré, injecté au moment de l'exécution et masqué dans les journaux. Pour la production, range-le dans un environnement protégé par une approbation, et pour un cloud, préfère OIDC, qui évite tout secret permanent (secrets et variables).

C'est quoi le déploiement blue-green et le déploiement canary ?

En blue-green, deux environnements de production identiques coexistent : on déploie la nouvelle version sur celui qui ne reçoit pas de trafic, puis on bascule tout le trafic d'un coup ; le retour arrière consiste à rebasculer. En canary, la nouvelle version ne reçoit d'abord qu'une petite part du trafic (5 ou 10 %), et on l'augmente par paliers si les indicateurs restent bons. Les deux évitent la coupure, mais demandent un schéma de base compatible entre les versions (stratégies de déploiement).

C'est quoi DevSecOps ?

DevSecOps consiste à intégrer la sécurité à chaque étape du développement plutôt qu'à la fin, en automatisant des contrôles dans le pipeline : analyse du code (SAST), des dépendances (SCA), détection des secrets, analyse des images Docker, tests de l'application en recette (DAST). Il protège aussi le pipeline lui-même : droits minimaux, actions épinglées, secrets cloisonnés (la sécurité dans la CI).

L'intégration continue est-elle au programme du BTS SIO ?

Oui. Le référentiel de 2024 cite, dans le bloc 2 SLAM évalué à l'épreuve E6, la compétence « Intégrer en continu les versions d'une solution applicative », et le bloc 1, commun aux deux options et évalué à l'E5, demande de « déployer un service ». Les indicateurs de sécurité du bloc 3 SLAM, évalués à l'écrit E7, portent aussi sur des composants « sécurisés et actualisés » et des tests de sécurité. Un pipeline sur ton projet, avec une protection de branche et un déploiement en recette, en est la preuve la plus convaincante (la CI/CD dans le référentiel).