Salut.
Vu que tu pourrais trouver 1'000'000 d'explications sur le net en tapant littéralement "pipeline CI/CD" sur Google, je vais quand même expliquer avec mes mots. Peut-être que ça aidera, mais je pense que tu trouveras énormément d'explications très bonnes et moins biaisée que la mienne sur ce que c'est les pipelines.
En tant que développeur, tu produis du code. Ce code s'intègrera, la plupart du temps, à du code déjà existant et produit par l'entreprise (tes collègues ou d'ancien devs de la boîte). Pour que cette intégration se passe au mieux, on utilise des pipelines CI/CD. À chaque fois que tu rajoutes du code dans un programme ou une librairie, c'est une évolution. Il faut donc faire plusieurs opérations qui sont généralement orchestrées par un serveur d'automatisation (Jenkins p.ex) car il faut pratiquement toujours faire la même chose. Qu'est-ce qui est fait dans ces pipelines ? Tout ce que tu veux. C'est juste une automatisation de divers processus appliqués à ce que tu veux. Mais c'est à l'entreprise de créer ses pipelines. Voilà comment ça fonctionne grosso-modo pour ce qui est du code dans une majorité d'entreprises:
1) Je pousse du code sur GIT, j'ai configuré mon serveur GIT pour qu'il avertisse mon serveur d'automatisation quand ça se produit.
2) Mon serveur d'automatisation réagit en récupérant le projet qui a été modifié. Il cherche le fichier qui indique quelle pipeline doit être déclenchée pour ce projet. Par exemple, pour Jenkins, c'est le Jenkinsfile qui est situé dans ton projet (à la racine généralement) qui décrit la pipeline
3) Une fois qu'il sait ce qu'il doit faire, il exécute les tâches qu'il faut faire. L'interface d'un serveur d'automatisation te montre généralement la progression de chaque étape que tu as définie et te donne un statut (temps qu'il a passé sur l'étape, si selon tes critères c'est réussi ou échoué, etc.).
Maintenant une pipeline, comme je l'ai dit, ça peut être tout et n'importe quoi. Dans un cadre CI/CD donc intégration continue de code source et livraison continue, on pourrait imaginer un exemple avec les différentes étapes suivantes (c'est souvent ce que tu trouveras en vrai, il peut y avoir des étapes supplémentaires ou ça peut être dans un ordre différent pour certains trucs):
1) Compilation du code (ici, si pas d'erreur à la compil, l'étape sera considérée comme OK)
2) Tests unitaires (exécution des tests unitaires liés à ton projet. Si tous les tests passent OK)
3) Test d'intégration (exécution des tests d'intégration liés à ton projet. Si tous les tests passent OK)
4) Test qualité (selon des règles imposées par un outil d'audit de code, p.ex Sonar ou autre. Si les objectifs en termes de qualité sont toujours atteints après avoir ajouté ton code, ce sera OK).
5) Publication de la nouvelle version de l'application / de la librairie sur un gestionnaire de dépendance (type Nexus p.ex.)
6) Déploiement de la nouvelle version de l'application / de la librairie sur le serveur où elle doit être déployée. Généralement c'est publié soit sur un environnement de "développement" soit sur un environnement "intégration". Ca dépend, il y a plusieurs écoles. Le déploiement en environnement qualité ou production se fera dans la majorité des cas via une "promotion". C'est le "product owner" du programme impacté qui choisit généralement quand il est satisfait de telle ou telle version et que les changements sont "promus" en prod ou pré-prod. Mais là, on passe plus vraiment par un serveur d'automatisation, en tout cas pas dans les environnements dans lesquels j'ai travaillé. Je sais plus tellement ce que c'est le standard pour la livraison continue, je ne sais pas si on passe par ces étapes de promotion ou si justement on automatise absolument tout. C'est trop ambitieux si c'est le cas pour beaucoup d'entreprises.
Voilà, j'espère avoir pu t'aider. N'hésite pas si tu as des questions plus précises à ce sujet.
Message édité le 12 janvier 2023 à 14:23:01 par Impaloupa
