You are currently viewing Gitlab CI – Comment automatiser les tests

Gitlab CI – Comment automatiser les tests

  • Post comments:0 commentaire
  • Temps de lecture :9 min de lecture

Qu’est-ce qu’une CI et quoi peut-elle servir ? Cet article va y répondre et vous donnez une configuration simple sur Gitlab CI, afin d’automatiser les tests.

CI ? Continious Integration ou intégration continue ?

L’intégration continue (CI) est un ensemble de pratique qui consiste à tester l’application à chaque modification (via un push git). L’avantage de cette pratique est de maintenir à jour votre application, sans vous préoccuper de tester l’ensemble des codes métiers, pour vous rassurer qu’il est toujours stable.

Ceci permet aussi de bloquer une branche lors d’une fusion (merge) s’il il y a une erreur lors des tests. On réduit fortement la régression.

Dans cet article, je vais vous présenter Gitlab CI, un logiciel libre qui va lancer vos tests à chaque commit sur votre dépôt GitLab. Dans un prochain article, on parlera de Bitbucket CI qui lui est aussi incorporé directement dans Bitbucket.

Comment ça marche ?

Gitlab CI marche uniquement avec des dépôt Gitlab. Rien à configurer, votre dépôt peut accéder directement à la CI de Gitlab.

Sur votre projet, à la racine de ce dernier, on va créer un fichier nommé : “.gitlab-ci.yml”. Ce fichier est le point d’entrée pour la CI pour qu’il s’exécute sur votre projet.

On va le configurer et l’utiliser les deux derniers articles (Tests Unitaires, Fixtures) pour vérifier si tout marche comme il faut.

image: edbizarro/gitlab-ci-pipeline-php:7.2-alpine

cache:
    paths:
        - vendor/
services:
    - mysql:latest

stages:
    - build
    - test

variables:
    MYSQL_ROOT_PASSWORD: root
    MYSQL_USER: homestead
    MYSQL_PASSWORD: secret
    MYSQL_DATABASE: homestead
    DB_HOST: mysql
    GIT_STRATEGY: fetch

build:
    stage: build
    script:
        - composer install --prefer-dist --no-ansi --no-interaction --no-progress
        - sudo apk add --no-cache zip unzip

test:
    stage: test
    script:
        - php bin/console doctrine:schema:update --force --env=test 
        - php bin/console doctrine:fixture:load --no-interaction --env=test
        - ./vendor/bin/simple-phpunit
    dependencies:
        - build

Au secours !!! Gary veut nous noyer encore ! :O

Encore une fois comme pour Travis-CI, je vais expliquer cas par cas chaque option, comme pour Travis c’est une version simplifiée uniquement pour de la CI.

Comparé à Travis CI on peut utiliser soit un docker que fournit Gitlab où on peut se connecter directement sur un de nos serveurs afin de faire les tests et le déploiement (CD ce qui sera fait dans un prochain article).

Désormais, je vais expliquer chaque partie de la conf de .gitlab-ci.yml.

image

Une image de docker qui est adapté à GitLab CI.

cache

Pour éviter d’attendre entre chaque test, on peut mettre en cache le composer et Phpunit afin d’accélérer le processus.

services

L’ensemble des services qui vous permettra de simuler un environnement, une base de données, un elasticsearch, un rabbitmq etc. Par défaut, l’image docker n’a aucun service d’installer pour améliorer les performances.

stages

C’est les étapes qu’on veut effectuer dans notre CI, par exemple on veut faire un build, fixture, test. On peut créer autant d’étapes qu’on veut.

variables

Les variables de configuration qu’on veut mettre en place dans Gitlab CI.

build / test

Stage : L’étape que le script doit être utilisé.

Script : C’est les scripts qui vont permettre de mettre en place l’environnement de tests, lancer les tests unitaires. Pour mon environnement de tests, j’ai décidé d’installer le prochain avec les bundles dont j’ai besoin, la base de données et les fixtures de notre dernier article.

Dependencies : Comme pour les fixtures, cette partie se lancera après l’étape qu’on a choisie, pour cet exemple c’est le build.

Un peu plus de détail

Comme vous pouvez le remarquer, il y a des options dans les lignes de commandes qui seront importants à savoir.

–env

Permet de choisir l’environnement pour exécuter la commande pour nos tests on force celui de tests alors il va utiliser la configuration du fichier “.env.test“.

doctrine:fixtures:load -n

L’option -n permet de passer à oui la demande de vide la base de données avant d’exécuter les fixtures.

Configuration des tests .env et phpunit

Maintenant, je vais configurer le projet pour qu’il puisse avoir un environnement de test pour Gitlab CI. Le fichier .env.test sera utile pour différencier notre environnement de production et notre environnement de test.

###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=32bb1968190362d214325d23756ffd65
DATABASE_URL=mysql://homestead:[email protected]/homestead
#TRUSTED_PROXIES=127.0.0.1,127.0.0.2
#TRUSTED_HOSTS='^localhost|example\.com$'
###< symfony/framework-bundle ###

Par rapport à votre .env.test il y a DATABASE_URL qui se rajoute, qui permet d’avoir sur Gitlab CI, une connexion à une base de données.

Maintenant, il faut commit et push l’ensemble de nos modifications pour voir ce qu’il se passe sur GitLab.

Page de Résultat de Gitlab-CI

Maintenant on peut voir sur Gitlab, l’ensemble des stages (Build et Test). Il lancera la CI sur chaque modification qu’on enverra sur le dépôt Git sur Gitlab. A savoir qu’il envoie des mails des résultats s’il y a des erreurs.

Dans un prochain article, on fera plusieurs stages avec des tests simultanées et des tests journaliers.

Laisser un commentaire