Intégration continue

Le workflow est centré sur Gitlab, qui permet à des utilisateurs de créer des projets dans des groupes. Ces projets vont utiliser l'intégration continue avec des images Docker, pour construire, tester, empaqueter, tester fonctionnellement les applications avant de les déployer.

Gitlab #

Git et Gitlab sont utilisés pour versionner le code, mais aussi pour la description de l’architecture des services qui forment l’application, s’inscrivant ainsi dans l’approche “infrastructure as code”, dans le cas des services conteneurisés.

Gitlab centralise aussi la gestion des utilisateurs, et les services complémentaires utilisent l’OAuth2 fourni par Gitlab pour l’authentification.

Intégration continue #

Le workflow utilise un ou plusieurs serveurs d’intégration continue (abrégé en CI) dans l’environnement Gitlab. La CI ne contient pas d’outils de développement, car toutes les étapes de l’intégration seront faites par des conteneurs Docker.

Gitlab CI permet de déclencher une suite d’actions à chaque fois que du code est poussé. Ces actions sont séquentielles et peuvent être parallélisées.

Gitlab utilise le terme technique de “Pipelines” pour désigner les étapes de l’intégration continue. Le fichier .gitlab-ci.yml permet de décrire les étapes de l’intégration du projet, et il doit être versionné à la racine du projet.

Docker et Docker-Compose #

Le workflow utilise Docker lors de l’étape de l’intégration continue pour lancer des tests unitaires ou fonctionnels, installer des dépendances, préparer les assets …

Docker peut aussi être utilisé pour déployer le projet, qui sera alors composé de services conteneurisés:

• Docker-compose permet de décrire l’ensemble des services formant une application conteneurisée.

• Cette description sera utilisée à différentes étapes du projet : développement (en local), intégration continue (tests unitaires et fonctionnels) et éventuellement en production.

• Le fichier docker-compose.yml sera utilisé tel quel en développement et en intégration continue, mais il ne servira que de base pour la description de l’environnement de production : les services infogérés (tels que le SGBD) qui sont déclarés dans le fichier seront rendus différemment en production, avec un service natif, et potentiellement répliqué.