Premiers pas avec les pipelines d’intégration et de déploiement continus de GitLab (CI / CD) –

L’intégration et le déploiement continus, ou CI / CD, est le processus de rationalisation et d’accélération du développement en créant et testant automatiquement chaque engagement dans votre projet. GitLab intègre CI / CD dans leur git solution extrêmement bien, et nous montrerons comment la configurer et l’utiliser.

Configurer un serveur de construction (GitLab Runner)

Souvent, la compilation de code peut être une opération extrêmement intensive. Tous les langages n’ont pas ce problème, mais certains, comme C ++, peuvent prendre plus d’une demi-heure pour terminer une compilation compliquée. Le chrome, par exemple, peut prendre plus d’une heure, même sur les systèmes à 12 cœurs, comme le montre ce graphique de GamersNexus.

Le temps, c’est de l’argent, de nombreuses entreprises choisiront donc d’avoir des serveurs de construction dédiés, souvent un essaim de serveurs, et d’exécuter leurs pipelines CI / CD sur du matériel puissant.

Si vous n’êtes pas auto-hébergé et que vous utilisez plutôt la solution SaaS en ligne de GitLab (gitlab.com), vous devrez alors payer les minutes CI / CD. Le niveau gratuit comprend 400 minutes CI / CD, ce qui devrait être suffisant pour des projets simples, en particulier des langages comme JS où tout ce qui peut être nécessaire est un élément de base npm build. Les niveaux supérieurs, facturés par utilisateur, offrent beaucoup plus de temps de construction. Vous pouvez afficher les totaux à jour à partir de la page d’informations sur les prix de GitLab.

Dans notre cas, nous sommes auto-hébergés, nous devrons donc configurer un GitLab Runner, qui s’installe sur un serveur et le configure en tant qu’agent de compilation. Ceci est disponible en tant que déploiement binaire et Kubernetes, ce qui peut être idéal pour les déploiements multi-serveurs à mise à l’échelle automatique.

Heureusement, le processus d’installation est simple. Vous devrez trouver le binaire dont vous aurez besoin pour votre hôte et le télécharger. Pour les systèmes basés sur Debian comme Ubuntu, ce serait le deb paquet:

curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"

Et installez-le avec dpkg:

sudo dpkg -i gitlab-runner_amd64.deb

Ensuite, vous devrez le configurer avec l’URL et le jeton trouvés dans / admin / runners.

sudo gitlab-runner register

Il vous sera demandé de spécifier quel exécuteur ce coureur doit utiliser. Dans la plupart des cas, vous pouvez simplement utiliser «docker», avec une image par défaut comme ubuntu.

Une fois configuré, vous pouvez démarrer le coureur:

sudo gitlab-runner register

Ensuite, vous devriez le voir dans la liste.

Dans notre cas, il y avait un bug étrange où le coureur ne partait pas car le /var/lib/gitlab-runner le dossier n’était pas présent. Le créer manuellement a résolu le problème immédiatement:

sudo mkdir /var/lib/gitlab-runner

Vous devrez ouvrir les paramètres du runner et définir des balises appropriées pour celui-ci qui seront récupérées en faisant correspondre les fichiers de configuration gitlab-ci.yml. Si vous ne vous souciez pas des balises, vous pouvez cocher cette case ici pour récupérer les travaux non balisés:

Ensuite, vous devrez configurer vos projets pour utiliser ce runner.

Configurer CI / CD pour votre projet

La configuration de GitLab CI se fait avec un fichier à la racine de votre projet, appelé .gitlab-ci.yml. Ceci est automatiquement utilisé pour s’exécuter.

Bien sûr, la configuration exacte de cela dépendra fortement de vous et de vos besoins. Un bon point de départ serait de chercher comment les autres l’ont fait pour votre langage et votre environnement d’exécution.

Par exemple, une construction .NET simple peut être exécutée à l’aide d’une configuration comme celle-ci:

image : microsoft/dotnet:latest

stages:
  - build

before_script:
  - 'dotnet restore'

build:
  stage: build
  script:
    - 'dotnet build'

Tout d’abord, nous devons définir l’image Docker que GitLab utilisera pour créer votre application. Ceci est important car sinon l’environnement n’aura pas le runtime .NET. Avant tout, ça court dotnet restore, puis court dotnet build pour créer réellement l’application.

Pour en savoir plus sur la structure de ce fichier, vous pouvez consulter la documentation de GitLab.

Une fois engagé dans votre dépôt, ce commit déclenchera le premier pipeline. Vous pouvez afficher les résultats du pipeline sous CI / CD> Pipelines, où vous verrez chaque exécution avec son état.

Si vous cliquez sur les détails, vous pouvez déboguer ce qui n’a pas fonctionné en cas d’échec de l’exécution, car il conserve un journal de la console.