Qu’est-ce qu’une CI et quoi peut-elle servir ? Cet article va y répondre et vous donnez une configuration simple pour pouvoir l’utiliser sur votre projet.
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 Bitbucket CI, un logiciel libre qui va lancer vos tests à chaque commit sur votre dépôt Bitbucket.
Comment ça marche ?
Bitbucket CI marche uniquement avec des dépôt Bitbucket. Rien à configurer, votre dépôt peut accéder directement à la CI de Bitbucket.
Sur votre projet, à la racine de ce dernier, on va créer un fichier nommé : “bitbucket-pipelines.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.
# This is a sample build configuration for PHP.
# Check our guides at https://confluence.atlassian.com/x/e8YWN for more examples.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: php:7.2
pipelines:
default:
- step:
caches:
- composer
script:
- apt-get update && apt-get install -y unzip default-mysql-client
- docker-php-ext-install pdo pdo_mysql
- curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- composer install
- php bin/console doctrine:schema:update --force --env=test
- php bin/console doctrine:fixture:load --no-interaction --env=test
- ./vendor/bin/simple-phpunit --coverage-text --colors
services:
- mysql
definitions:
services:
mysql:
image: mysql:5.7
variables:
MYSQL_DATABASE: 'homestead'
MYSQL_RANDOM_ROOT_PASSWORD: 'yes'
MYSQL_USER: 'homestead'
MYSQL_PASSWORD: 'secret'
Encore une fois comme pour Travis-CI ou Gitlab CI, je vais expliquer cas par cas chaque option, comme pour Travis et GitLab CI c’est une version simplifiée uniquement pour de la CI.
Comparé à Travis CI on peut utiliser soit un docker que fournit Bitbucket comme Gitlab ou 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 bitbucket-pipelines.yml.
image
Une image de docker en général qui est adapté à Bitbucket CI.
pipelines
Définition de l’ensemble des pipelines
pipelines > default
Le mode default permet de lancer la CI sur n’importe quel commit de n’importe quel branche de git. Vous pouvez spécifier à la place uniquement les pull-requests ou des branches en particulier. (on vera sur un prochain article où je vous expliquerai plus en détail).
pipelines > step
C’est une étape qui permet d’initialiser un container Docker pour le test (avec un choix de l’image pour ce dernier), utile si vous avez un projet avec plusieurs langage à tester. Ici on test uniquement le back php mais on pouvait aussi tester un script javascript.
pipelines > step > caches
Pour éviter d’attendre entre chaque test, on peut mettre en cache le composer afin d’accélérer le processus.
pipelines > step > 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 projet avec les bundles dont j’ai besoin, la base de données et les fixtures de notre dernier article.
pipelines > step > 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.
definitions
L’ensemble de définition de services etc.
definitions > services > mysql
Le service MySql avec l’ensemble de ses informations qu’on définit pour notre CI.
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 Bitbucket 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 Bitbucket 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 Bitbucket.
Maintenant on peut voir sur Bitbucket, l’ensemble des stages (Step 1). Il lancera la CI sur chaque modification qu’on enverra sur le dépôt Git sur Bitbucket. 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.
