Salut !

Aujourd’hui on va parler de gestionnaire de sources et plus particulièrement d’intégration continue (Le petit CI à coté de Gitlab). Gitlab pour commencer, c’est un gestionnaire de dépôts Git (Github like), gratuit, open-source et plutôt beau. Il propose pour votre projet un wiki, les issues, les comparaisons de codes et… l’intégration continue

Intégration continue o_0 ?

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée

Source : Wikipedia

Concrètement, avec Gitlab CI, nous allons pouvoir effectuer des tests sur notre code à chaque push afin de le tester. Nous pouvons aussi l’utiliser pour compiler nos sources et récupérer automatiquement l’executable :)

Pourquoi Gitlab CI ?

Il existe différents outils d’intégration continue, dans les plus connus nous pouvons citer Jenkins, TeamCity et Travis.

En comparaison,

  • Jenkins fonctionne principalement avec Java, que ce soit dans le vocabulaire utilisé ou dans le fonctionnement : les artéfacts sont disponibles, et font la force de Jenkins. Mais Jenkins commence à rouiller, donc il faudra attendre Jenkins 2.0 pour que la comparaison ait du sens.
  • TeammCity est gratuit (avec des restrictions), fonctionne plutôt bien et met en valeur les résultats des tests unitaires.

Cependant, ce sont tous les deux des outils externes : à moins d’avoir un LDAP (et donc, Gitlab EE), vous ne pourrez pas avoir d’authentification centralisée. > Gitlab CI est à Gitlab ce que Travis est à Github : un outil intégré du début à la fin.

Et surtout, Gitlab CI (comme Travis) permet de lancer vos tests / builds dans des environnements Docker ! Le top en terme de sécurité.

Installation d’un runner

Gitlab-runner est l’executable (open source et écrit en Go) qui va se charger de lancer les tests sur notre code. Il peut lancer la suite de tests en local, sur une machine avec un accès SSH, ou même dans Docker. Et c’est Docker que nous allons configurer.

Nous commençons donc par l’installation de docker. Attention, il vous faudra une machine dédiée ou un VPS KVM, Docker fonctionne assez mal sur OpenVZ.

$ curl -sSL https://get.docker.com/ | sh

Vient ensuite l’installation du runner Gitlab CI.

Avec Debian :

$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ apt install gitlab-ci-multi-runner

Avec CentOS :

$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
$ yum install gitlab-ci-multi-runner

Pour la suite, vous avez besoin d’un Token (_https://addresse_de_mon_gitlab/admin/runners_) Pour le configurer rien de plus simple

$ gitlab-ci-multi-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci ) https://addresse_de_mon_gitlab/ci
Please enter the gitlab-ci token for this runner Token
Please enter the gitlab-ci description for this runner MonRunner
INFO[0034] fcf5c619 Registering runner… succeeded
Please enter the executor: shell, docker, docker-ssh, ssh? docker
Please enter the Docker image (eg. ruby:2.1): debian:latest
INFO[0037] Runner registered successfully. Feel free to start it, but if it’s running already the config should be automatically reloaded!

Notre runner est configuré, il ne nous reste plus qu’à le lancer:

$ gitlab-ci-multi-runner run

Si aucun message d’erreur n’apparait, vous devriez voir votre runner sur la page dédiée de votre Gitlab

Utilisation du runner

Comme nous pouvons le voir sur le screen juste au dessus, le runner est actuellement de type Shared. Dans cet état il exécutera le code de tous vos projets. Vous pouvez néanmoins réserver un runner à un projet en particulier en le lui attribuant.

Pour utiliser Gitlab-CI dans vos projets, il vous faut un fichier .gitlab-ci.yml. C’est ce fichier qui va décrire les différentes tâches à effectuer pour tester notre code. Dans mon exemple, je vais compiler une application en Go. Un simple Hello World, pas de make, nous restons très basique.

.gitlab-ci.yml :

# Image du Hub docker à utiliser
image: golang
# Commande à lancer avant notre code
before_script:
  - go version
test_app:
  script: go build hello.go && ./hello
  artifacts: # Récupération du binaire
    untracked: true

La ligne artifacts.untracked: true demande à Gitlab CI d’enregistrer tous les fichiers qui ne font pas dans Git. Notre binaire hello en fait partie : il sera stocké dans les artéfacts.

À chaque nouveau commit, votre code va maintenant être testé. Le runner va utiliser un container Docker puis le détruire une fois le test terminé.

Cette configuration est très souple et devrait vous permettre de réaliser tout ce que vous désirez. Pour plus d’informations, je vous renvoie à la documentation .gitlab-ci.yml.