🥇Guide du CI/CD dans GitLab pour le débutant (presque) absolu

Ou comment obtenir de beaux badges pour votre projet en une soirée de codage facile

Probablement, chaque développeur qui a au moins un projet favori à un moment donné a une démangeaison à propos de beaux badges avec des statuts, une couverture de code, des versions de packages en nuget... Et cette démangeaison m'a amené à écrire cet article. En préparation pour l'écrire, j'ai eu cette beauté dans l'un de mes projets :

Cet article vous guidera à travers la configuration de base de l'intégration et de la livraison continues pour un projet de bibliothèque de classes .Net Core dans GitLab, la publication de la documentation sur les pages GitLab et la transmission des packages créés vers un flux privé dans Azure DevOps.

VS Code a été utilisé comme environnement de développement avec l'extension Flux de travail GitLab (pour valider le fichier de paramètres directement depuis l'environnement de développement).

Brève introduction

CD - est-ce que vous venez de pousser et que tout est déjà tombé sur le client?

Qu'est-ce que CI / CD et pourquoi vous en avez besoin - vous pouvez facilement le rechercher sur Google. Trouver une documentation complète sur la configuration des pipelines dans GitLab aussi facile. Ici, je vais décrire brièvement et, si possible, sans défauts, le processus du système à vol d'oiseau :

le développeur envoie un commit au référentiel, crée une demande de fusion via le site, ou d'une autre manière, démarre explicitement ou implicitement le pipeline,
toutes les tâches sont sélectionnées dans la configuration dont les conditions permettent de les lancer dans le contexte donné,
les tâches sont organisées selon leurs étapes,
les étapes sont exécutées à tour de rôle - c'est-à-dire parallèlement à toutes les tâches de cette étape sont terminées,
si l'étape échoue (c'est-à-dire qu'au moins une des tâches de l'étape échoue), le pipeline s'arrête (presque toujours),
si toutes les étapes sont terminées avec succès, le pipeline est considéré comme réussi.

Ainsi, nous avons:

pipeline - un ensemble de tâches organisées en étapes au cours desquelles vous pouvez créer, tester, empaqueter du code, déployer une version finie sur un service cloud, etc.,
organiser (étape) - unité d'organisation du pipeline, contient 1+ tâche,
tâche (JOB) est une unité de travail dans le pipeline. Il se compose d'un script (obligatoire), des conditions de lancement, des paramètres de publication/mise en cache des artefacts, et bien plus encore.

En conséquence, la tâche lors de la configuration de CI / CD revient à créer un ensemble de tâches qui implémentent toutes les actions nécessaires pour construire, tester et publier du code et des artefacts.

Avant de commencer : pourquoi ?

Pourquoi Gitlab ?

Parce que quand il est devenu nécessaire de créer des dépôts privés pour des projets favoris, ils ont été payés sur GitHub, et j'étais gourmand. Les référentiels sont devenus gratuits, mais jusqu'à présent, ce n'est pas une raison suffisante pour que je passe à GitHub.

Pourquoi pas Azure DevOps Pipelines ?

Parce que là, le réglage est élémentaire - la connaissance de la ligne de commande n'est même pas requise. Intégration avec des fournisseurs git externes - en quelques clics, importation de clés SSH pour envoyer des commits au référentiel - aussi, le pipeline est facilement configuré même pas à partir d'un modèle.

Position de départ : ce que vous avez et ce que vous voulez

Nous avons:

référentiel dans GitLab.

Nous voulons:

assemblage et tests automatiques pour chaque demande de fusion,
construire des packages pour chaque demande de fusion et pousser vers le maître, à condition qu'il y ait une certaine ligne dans le message de validation,
envoyer des packages construits à un flux privé dans Azure DevOps,
montage de la documentation et publication dans les Pages GitLab,
insignes!11

Les exigences décrites relèvent organiquement du modèle de pipeline suivant :

Étape 1 - Assemblage
- Nous collectons le code, publions les fichiers de sortie sous forme d'artefacts
Étape 2 - test
- Nous obtenons des artefacts dès la phase de construction, exécutons des tests, collectons des données de couverture de code
Étape 3 - Soumettre
- Tâche 1 - créer le package nuget et l'envoyer à Azure DevOps
- Tâche 2 - nous collectons le site de xmldoc dans le code source et le publions dans les pages GitLab

Commençons!

Collecte de la configuration

Préparation des comptes

Créez un compte dans Microsoft Azure
Nous passons à DevOps Azure
Nous créons un nouveau projet
1. Nom - tout
2. Visibilité - quelconque
Lorsque vous cliquez sur le bouton Créer, le projet sera créé et vous serez redirigé vers sa page. Sur cette page, vous pouvez désactiver les fonctionnalités inutiles en vous rendant dans les paramètres du projet (lien en bas dans la liste à gauche -> Présentation -> bloc Azure DevOps Services)
Accédez à Atrifacts, cliquez sur Créer un flux
1. Entrez le nom de la source
2. Choisissez la visibilité
3. Décochez Inclure des packages provenant de sources publiques courantes, afin que la source ne se transforme pas en un clone de nuget de vidage
Cliquez sur Se connecter au flux, sélectionnez Visual Studio, copiez la source à partir du bloc Configuration de la machine
Accédez aux paramètres du compte, sélectionnez Jeton d'accès personnel
Créer un nouveau jeton d'accès
1. Nom - arbitraire
2. Organisation - actuelle
3. Valable 1 an maximum
4. Portée - Emballage/Lecture et écriture
Copiez le jeton créé - après la fermeture de la fenêtre modale, la valeur sera indisponible
Allez dans les paramètres du référentiel dans GitLab, sélectionnez les paramètres CI / CD
Développez le bloc Variables, ajoutez-en un nouveau
1. Nom - n'importe lequel sans espaces (sera disponible dans le shell de commande)
2. Valeur - jeton d'accès du paragraphe 9
3. Sélectionner la variable de masque

Ceci termine la pré-configuration.

Préparation du cadre de configuration

Par défaut, la configuration CI/CD dans GitLab utilise le fichier .gitlab-ci.yml à partir de la racine du référentiel. Vous pouvez définir un chemin arbitraire vers ce fichier dans les paramètres du référentiel, mais dans ce cas, ce n'est pas nécessaire.

Comme vous pouvez le voir sur l'extension, le fichier contient une configuration au format YAML. La documentation détaille les clés pouvant être contenues au niveau supérieur de la configuration et à chacun des niveaux imbriqués.

Tout d'abord, ajoutons un lien vers l'image docker dans le fichier de configuration, dans lequel les tâches seront effectuées. Pour cela on trouve Page des images .Net Core sur Docker Hub. la GitHub il existe un guide détaillé sur l'image à choisir pour différentes tâches. Une image avec .Net Core 3.1 nous convient pour la construction, alors n'hésitez pas à ajouter la première ligne à la configuration

image: mcr.microsoft.com/dotnet/core/sdk:3.1

Désormais, lorsque le pipeline est lancé à partir du référentiel d'images Microsoft, l'image spécifiée sera téléchargée, dans laquelle toutes les tâches de la configuration seront exécutées.

L'étape suivante consiste à ajouter étape's. Par défaut, GitLab définit 5 étapes :

.pre - effectué jusqu'à toutes les étapes,
.post - effectué après toutes les étapes,
build - premier après .pre organiser,
test - seconde phase,
deploy - la troisième étape.

Rien ne vous empêche cependant de les déclarer explicitement. L'ordre dans lequel les étapes sont répertoriées affecte l'ordre dans lequel elles sont exécutées. Pour être complet, ajoutons à la configuration :

stages:
  - build
  - test
  - deploy

Pour le débogage, il est logique d'obtenir des informations sur l'environnement dans lequel les tâches sont exécutées. Ajoutons un ensemble global de commandes qui seront exécutées avant chaque tâche avec before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

Il reste à ajouter au moins une tâche pour que lorsque les commits seront envoyés, le pipeline démarrera. Pour l'instant, ajoutons une tâche vide pour illustrer :

dummy job:
  script:
    - echo ok

On lance la validation, on reçoit un message que tout va bien, on commit, on pousse, on regarde les résultats sur le site... Et on reçoit une erreur de script - bash: .PSVersion: command not found. WTF ?

Tout est logique - par défaut, les runners (responsables de l'exécution des scripts de tâches et fournis par GitLab) utilisent bash pour exécuter des commandes. Vous pouvez résoudre ce problème en spécifiant explicitement dans la description de la tâche les balises que l'exécuteur de pipeline en cours d'exécution doit avoir :

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

Super! Le pipeline est maintenant en cours d'exécution.

Un lecteur attentif, après avoir répété les étapes indiquées, remarquera que la tâche a été accomplie à l'étape test, bien que nous n'ayons pas précisé l'étape. Comme vous pouvez le deviner test est l'étape par défaut.

Continuons à créer le squelette de configuration en ajoutant toutes les tâches décrites ci-dessus :

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

Nous avons obtenu un pipeline pas particulièrement fonctionnel, mais néanmoins correct.

Configuration des déclencheurs

Étant donné qu'aucun filtre de déclenchement n'est spécifié pour aucune des tâches, le pipeline pleinement être exécuté chaque fois qu'un commit est poussé vers le référentiel. Comme ce n'est pas le comportement souhaité en général, nous allons mettre en place des filtres de déclenchement pour les tâches.

Les filtres peuvent être configurés en deux formats : seulement/sauf и . Brièvement, only/except permet de configurer des filtres par déclencheurs (merge_request, par exemple - définit la tâche à exécuter chaque fois qu'une demande d'extraction est créée et chaque fois que des validations sont envoyées à la branche qui est la source dans la demande de fusion) et les noms de branche (y compris l'utilisation d'expressions régulières) ; rules vous permet de personnaliser un ensemble de conditions et, éventuellement, de modifier la condition d'exécution de la tâche en fonction du succès des tâches précédentes (when dans GitLab CI/CD).

Rappelons un ensemble d'exigences - assemblage et test uniquement pour la demande de fusion, l'empaquetage et l'envoi à Azure DevOps - pour la demande de fusion et les poussées vers le maître, la génération de documentation - pour les poussées vers le maître.

Tout d'abord, configurons la tâche de génération de code en ajoutant une règle qui ne se déclenche que sur demande de fusion :

build job:
  # snip
  only:
    - merge_request

Configurons maintenant la tâche d'empaquetage pour qu'elle se déclenche sur la demande de fusion et ajoutons des commits au maître :

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

Comme vous pouvez le voir, tout est simple et direct.

Vous pouvez également configurer la tâche pour qu'elle se déclenche uniquement si une demande de fusion est créée avec une cible ou une branche source spécifique :

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Sous conditions, vous pouvez utiliser variables listées ici; règles rules incompatible avec les règles only/except.

Configuration de l'enregistrement d'artefacts

Au cours d'une tâche build job nous aurons des artefacts de construction qui pourront être réutilisés dans des tâches ultérieures. Pour ce faire, vous devez ajouter les chemins vers la configuration de la tâche, les fichiers le long desquels vous devrez enregistrer et réutiliser dans les tâches suivantes, à la clé artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

Les chemins prennent en charge les caractères génériques, ce qui les rend certainement plus faciles à définir.

Si une tâche crée des artefacts, chaque tâche suivante pourra y accéder - ils seront situés le long des mêmes chemins relatifs à la racine du référentiel qui ont été collectés à partir de la tâche d'origine. Les artefacts sont également disponibles en téléchargement sur le site.

Maintenant que nous avons un cadre de configuration prêt (et testé), nous pouvons passer à l'écriture de scripts pour les tâches.

Nous écrivons des scripts

Peut-être qu'il était une fois, dans une galaxie très, très lointaine, la construction de projets (y compris ceux sur .net) à partir de la ligne de commande était une douleur. Vous pouvez désormais créer, tester et publier le projet en 3 équipes :

dotnet build
dotnet test
dotnet pack

Naturellement, il y a quelques nuances à cause desquelles nous compliquerons quelque peu les commandes.

Nous voulons une version de version, pas une version de débogage, nous ajoutons donc à chaque commande -c Release
Lors des tests, nous voulons collecter des données de couverture de code, nous devons donc inclure un analyseur de couverture dans les bibliothèques de test :
1. Ajouter le package à toutes les bibliothèques de test coverlet.msbuild: dotnet add package coverlet.msbuild du dossier du projet
2. Ajouter à la commande de test /p:CollectCoverage=true
3. Ajoutez une clé à la configuration de la tâche de test pour obtenir des résultats de couverture (voir ci-dessous)
Lorsque vous compressez le code dans des packages de nuget, définissez le répertoire de sortie des packages : -o .

Collecte des données de couverture de code

Après avoir exécuté les tests, Coverlet imprime les statistiques d'exécution sur la console :

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab vous permet de spécifier une expression régulière pour obtenir des statistiques, qui peuvent ensuite être obtenues sous la forme d'un badge. L'expression régulière est spécifiée dans les paramètres de la tâche avec la clé coverage; l'expression doit contenir un groupe de capture dont la valeur sera passée au badge :

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

Ici, nous obtenons des statistiques d'une ligne avec une couverture totale de la ligne.

Publier des packages et de la documentation

Les deux actions sont prévues pour la dernière étape du pipeline - puisque l'assemblage et les tests sont passés, nous pouvons partager nos développements avec le monde.

Tout d'abord, envisagez de publier dans la source du package :

Si le projet n'a pas de fichier de configuration nuget (nuget.config), créez-en un nouveau : dotnet new nugetconfig

Pour quelle raison: l'image peut ne pas avoir accès en écriture aux configurations globales (utilisateur et machine). Afin de ne pas détecter d'erreurs, nous créons simplement une nouvelle configuration locale et travaillons avec.
Ajoutons une nouvelle source de package à la configuration locale : nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - nom de la source locale, non critique
2. url - URL de la source de l'étape "Préparer les comptes", p.6
3. organization - nom de l'organisation dans Azure DevOps
4. gitlab variable - le nom de la variable avec le jeton d'accès ajouté à GitLab ("Préparer les comptes", p. 11). Naturellement, sous la forme $variableName
5. -StorePasswordInClearText - un hack pour contourner l'erreur d'accès refusé (Je ne suis pas le premier à marcher sur ce râteau)
6. En cas d'erreurs, il peut être utile d'ajouter -verbosity detailed
Envoi du package à la source : nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Nous envoyons tous les paquets du répertoire courant, donc *.nupkg.
2. name - de l'étape ci-dessus.
3. key - n'importe quelle ligne. Dans Azure DevOps, la fenêtre Se connecter au flux donne toujours comme exemple la ligne az.
4. -skipduplicate - lors d'une tentative d'envoi d'un paquet déjà existant sans cette clé, la source renverra une erreur 409 Conflict; avec la touche , l'envoi sera sauté.

Paramétrons maintenant la création de la documentation :

Tout d'abord, dans le référentiel, dans la branche master, nous initialisons le projet docfx. Pour ce faire, exécutez la commande à partir de la racine docfx init et définissez de manière interactive les paramètres clés de la documentation de construction. Description détaillée de la configuration minimale du projet ici.
1. Lors de la configuration, il est important de spécifier le répertoire de sortie ..public - GitLab prend par défaut le contenu du dossier public à la racine du référentiel comme source pour les pages. Parce que le projet sera situé dans un dossier imbriqué dans le référentiel - ajoutez une sortie au niveau supérieur dans le chemin.
Poussons les modifications vers GitLab.
Ajouter une tâche à la configuration du pipeline pages (mot réservé aux tâches de publication de site dans les pages GitLab) :
1. script:
  1. nuget install docfx.console -version 2.51.0 - installer docfx ; la version est spécifiée pour garantir que les chemins d'installation du package sont corrects.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - collecte de documentation
2. Artefacts de nœud :

pages:
  # snip
  artifacts:
    paths:
      - public

Digression lyrique sur docfx

Auparavant, lors de la configuration d'un projet, je spécifiais le code source de la documentation en tant que fichier de solution. Le principal inconvénient est que la documentation est également créée pour les projets de test. Si cela n'est pas nécessaire, vous pouvez définir cette valeur sur le nœud metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

metadata.src.src: "../" - on monte d'un niveau par rapport à l'emplacement docfx.json, parce que dans les modèles, la recherche dans l'arborescence des répertoires ne fonctionne pas.
metadata.src.files: ["**/*.csproj"] - un pattern global, nous collectons tous les projets C# de tous les répertoires.
metadata.src.exclude: ["*.tests*/**"] - modèle global, exclure tout des dossiers avec .tests dans le nom

Sous-total

Une configuration aussi simple peut être créée en seulement une demi-heure et quelques tasses de café, ce qui vous permettra de vérifier que le code est construit et que les tests réussissent, de créer un nouveau paquet, de mettre à jour la documentation et de ravir les yeux avec de belles badges dans le README du projet à chaque demande de fusion et envoi au master.

Final .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

En parlant d'insignes

Grâce à eux, après tout, tout a commencé !

Les badges avec les statuts de pipeline et la couverture de code sont disponibles dans GitLab dans les paramètres CI/CD du bloc Gtntral pipelines :

J'ai créé un badge avec un lien vers la documentation sur la plateforme Boucliers.io - tout y est assez simple, vous pouvez créer votre propre badge et le recevoir à l'aide d'une requête.

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps Artifacts vous permet également de créer des badges pour les packages avec la dernière version. Pour ce faire, dans la source sur le site Azure DevOps, vous devez cliquer sur Créer un badge pour le package sélectionné et copier le balisage Markdown :

Ajouter de la beauté

Mise en surbrillance des fragments de configuration communs

Lors de l'écriture de la configuration et de la recherche dans la documentation, je suis tombé sur une fonctionnalité intéressante de YAML - la réutilisation de fragments.

Comme vous pouvez le voir dans les paramètres de la tâche, ils nécessitent tous la balise windows au niveau du runner, et sont déclenchés lorsqu'une demande de fusion est envoyée au maître/créé (sauf documentation). Ajoutons ceci au fragment que nous allons réutiliser :

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

Et maintenant, nous pouvons insérer le fragment déclaré précédemment dans la description de la tâche :

build job:
  <<: *common_tags
  <<: *common_only

Les noms de fragment doivent commencer par un point, afin de ne pas être interprétés comme une tâche.

Gestion des versions des packages

Lors de la création d'un package, le compilateur vérifie les commutateurs de ligne de commande et, en leur absence, les fichiers du projet ; lorsqu'il trouve un nœud Version, il prend sa valeur comme la version du package en cours de construction. Il s'avère que pour construire un package avec une nouvelle version, vous devez soit le mettre à jour dans le fichier projet, soit le transmettre en tant qu'argument de ligne de commande.

Ajoutons une autre liste de souhaits - laissez les deux chiffres mineurs de la version être l'année et la date de construction du package, et ajoutez des versions préliminaires. Bien sûr, vous pouvez ajouter ces données au fichier de projet et vérifier avant chaque soumission - mais vous pouvez également le faire dans le pipeline, en collectant la version du package à partir du contexte et en la transmettant via l'argument de ligne de commande.

Convenons que si le message de validation contient une ligne comme release (v./ver./version) <version number> (rev./revision <revision>)?, nous prendrons alors la version du package de cette ligne, la compléterons avec la date actuelle et la passerons en argument à la commande dotnet pack. En l'absence de file d'attente, nous ne récupérons tout simplement pas le colis.

Le script suivant résout ce problème :

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

Ajouter un script à une tâche pack and deploy job et observer l'assemblage des packages strictement en présence d'une chaîne donnée dans le message de validation.

En tout

Après avoir passé environ une demi-heure ou une heure à écrire la configuration, à déboguer dans le powershell local et, éventuellement, à quelques lancements infructueux, nous avons obtenu une configuration simple pour automatiser les tâches de routine.

Bien sûr, GitLab CI/CD est beaucoup plus étendu et multiforme qu'il n'y paraît après avoir lu ce guide - c'est complètement faux. Là même Auto DevOps estpermettant

détectez, construisez, testez, déployez et surveillez automatiquement vos applications

Il est maintenant prévu de configurer un pipeline pour déployer des applications sur Azure, en utilisant Pulumi et en déterminant automatiquement l'environnement cible, ce qui sera couvert dans le prochain article.

Source: habr.com

Un guide du CI/CD dans GitLab pour le débutant (presque) absolu