Lancement et visualisation des pipelines lors de la configuration de GitLab CI / CD pour plusieurs projets.
L'intégration continue (CI) consiste à automatiser l'assemblage et le test du code avant sa fusion avec la branche principale. Il permet aux développeurs d'injecter du code assez souvent et tôt, tout en réduisant le risque d'introduire de nouvelles erreurs dans le référentiel de code source principal.
Bien que CI vérifie que le nouveau code ne se cassera pas lorsqu'il est intégré à un autre code dans le même référentiel, réussir tous les tests sur ce référentiel n'est que la première étape. Après avoir exécuté CI dans le code, il est important de déployer et d'exécuter des tests dans un environnement réel. La transition de CI à la livraison et au déploiement continus (CD) est la prochaine étape vers les DevOps «adultes». Le déploiement et les retests ultérieurs vous permettent de tester le code d'un projet ainsi que d'autres composants et services qui peuvent être gérés par d'autres projets.
Pourquoi dois-je m'assurer que mon code fonctionne avec d'autres composants?
Un bon exemple est l'architecture des microservices. En règle générale, les microservices sont gérés dans différents projets , où chaque microservice possède son propre référentiel avec un pipeline. De plus, très souvent, chaque équipe de développement est responsable des microservices individuels et des configurations de pipeline. En tant que programmeur, vous voudrez peut-être vous assurer que les modifications apportées à votre code ne violent pas la fonctionnalité de ses microservices. Par conséquent, vous pouvez exécuter des tests sur eux en plus des tests pour votre projet.
Projet de croisement de pipelines
Lors du démarrage d'un pipeline de projet, vous devrez également exécuter un pipeline inter-projets, qui finira par déployer et tester la dernière version de tous les microservices dépendants. Pour y parvenir, vous avez besoin d'un moyen simple, flexible et pratique pour lancer d'autres pipelines dans le cadre du CI de votre projet. GitLab CI / CD offre un moyen simple de lancer un pipeline inter-projets en ajoutant une tâche spéciale au fichier de configuration CI.
Fichier de configuration GitLab CI / CD
Dans GitLab CI / CD, les pipelines, ainsi que les travaux et les étapes de leurs composants sont définis dans le .gitlab-ci.yml pour chaque projet. Le fichier fait partie du référentiel de projet. Il est entièrement versionné et les développeurs peuvent le modifier à l'aide de n'importe quel IDE de leur choix. Ils n'ont pas besoin de demander à l'administrateur système ou à la commande DevOps d'apporter des modifications à la configuration du pipeline, car ils peuvent le faire eux-mêmes. Le .gitlab-ci.yml détermine la structure et l'ordre des pipelines, et décide de ce qui doit être fait à l'aide de GitLab Runner (l'agent qui exécute les tâches), et quelles décisions doivent être prises lorsque certaines conditions se présentent, par exemple, lorsque le processus se termine avec succès ou se termine. système.
Ajout d'un travail pour exécuter un pipeline inter-projets
À partir de GitLab 11.8, GitLab fournit une nouvelle syntaxe de configuration CI / CD pour l'exécution de pipelines inter-projets, qui peut être trouvée dans les règles de configuration de la discipline . Le code suivant illustre comment configurer un travail de pont pour exécuter un pipeline de liaison descendante:
// job1 job deploy: stage: Deploy script: this is my script // job2 bridge job , - Android: stage: Trigger-cross-projects trigger: mobile/android
Dans l'exemple ci-dessus, dès que le travail de déploiement à l'étape du déploiement est réussi, la tâche pour le pont Android démarre. Son statut initial sera en attente. GitLab créera un pipeline en aval dans le projet mobile / android, et une fois qu'il sera créé, le travail Android réussira. Dans ce cas, mobile / android est le chemin complet vers ce projet.
L'utilisateur qui a créé le pipeline en amont doit avoir des droits d'accès au projet en aval (dans ce cas, mobile / android). Si le projet en aval est introuvable ou si l'utilisateur n'a pas les droits d'accès pour y créer un pipeline, le travail Android recevra le statut d'échec.
Vue d'ensemble des graphiques de l'amont au pipeline aval
GitLab CI / CD vous permet de visualiser la configuration du pipeline. Dans la figure ci-dessous, les étapes d'assemblage, de test et de déploiement font partie d'un projet en amont. Une fois le travail de déploiement terminé avec succès, quatre projets croisés seront lancés en parallèle, et vous pouvez y accéder en cliquant sur l'un des travaux en aval.
Dans la figure ci-dessous, vous pouvez voir la ligne de paiement décroissante «Service - Finance». Vous pouvez maintenant faire défiler vers la gauche jusqu'au pipeline ascendant, faire défiler vers la droite vers le pipeline descendant ou sélectionner un autre pipeline descendant.
Définition d'une branche de pipeline enfant
Vous pouvez spécifier le nom de la branche que le pipeline descendant utilisera:
trigger: project: mobile/android branch: stable-11-2
Utilisez le mot clé project pour indiquer le chemin d'accès complet au projet en aval. Utilisez le mot clé de branche pour déterminer le nom de la branche. GitLab utilisera la validation qui se trouve actuellement dans la branche HEAD lors de la création du pipeline de liaison descendante.
Passer des variables à un pipeline descendant
Un jour, vous voudrez peut-être passer des variables à un pipeline descendant. Vous pouvez le faire avec des mots clés pour les variables, comme vous le feriez avec une définition de travail régulière.
Android: variable: ENVIRONMENT: 'This is the variable value for the downstream pipeline' stage: Trigger-cross-projects trigger: mobile/android
La variable ENVIRONNEMENT sera transmise à chaque travail défini dans le pipeline descendant. Il sera disponible en tant que variable d'environnement chaque fois que GitLab Runner sélectionne un travail.
Total pipeline de projets croisés
Le .gitlab-ci.yml détermine l'ordre des étapes CI / CD, les tâches à effectuer et les conditions pour démarrer ou ignorer la tâche. L'ajout d'une «tâche de pont» avec le mot-clé trigger à ce fichier peut être utilisé pour exécuter des pipelines entre projets. Nous pouvons transmettre des paramètres aux travaux dans les pipelines descendants et même définir la branche que le pipeline descendant utilisera.
Les pipelines peuvent être des structures complexes avec de nombreuses tâches séquentielles et parallèles et, comme nous venons de l'apprendre, ils peuvent parfois exécuter des pipelines en aval. Pour simplifier la compréhension du flux de pipeline, y compris les pipelines descendants, GitLab dispose de pipelines pour afficher les pipelines et leurs statuts.
Lisez également d'autres articles sur notre blog: