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 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 définir les différents environnements et leurs variables qui seront utilisés lors de l’intégration et du déploiement de l’application.

Le workflow doit être guidé par les étapes définies dans un “Gitflow” qui permet de déclencher des actions selon les branches et l’état d’avancée du code.

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, les Runners Gitlab peuvent être en Shell ou 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 #

Lors de l’étape de l’intégration continue, le workflow utilise Docker pour lancer des tests unitaires ou fonctionnels, installer des dépendances, préparer les assets, etc.

Dans la pipeline Gitlab, l’image Docker qui aura été définie dans le .gitlab-ci.yml sera instanciée pour réaliser l’opération souhaitée lors des différentes étapes (intégration, build, tests …). Pour l’étape du déploiement, il faudra instancier l’image Docker du service proposé par Bearstech en utilisant la directive image: bearstech/deploy