/ devops

DevOps: Du code à la prod'

Avec Octree, nous réalisons plusieurs projets de site web par mois avec une équipe de trois développeurs. Ainsi, pour assurer un développement de qualité dans des temps courts, nous avons mis en place un processus qui nous permet un développement rapide et maîtrisé en utilisant une approche DevOps.
Dans cette article, nous nous intéressons aux principaux outils que nous utilisons à Octree ainsi qu’à leur mise en pratique.

Les outils

Pour mettre en œuvre cette approche DevOps, nous utilisons des outils déjà largement utilisés et approuvés. Les solutions Open-Source sont souvent notre choix par défaut mais nous mettons également la priorité sur des services stables qui ont fait leurs preuves.

La gestion des sources avec GitLab

GitLab est un gestionnaire de dépôts Git dont le fonctionnement s'inspire grandement du site GitHub. Contrairement à ce dernier, GitLab est un outil libre et open-source qui nous laisse la possibilité de l'installer sur un serveur auto-hébergé. Ainsi, nous avons une totale maîtrise des sources que nous produisons sans limitation sur le nombre de dépôts gérés.

Plus qu'un simple gestionnaire de sources, GitLab intègre un grand nombre d'outils facilitant le développement en équipe, le déploiement et l'intégration continue de projets.

Dans notre cas, nous utilisons principalement l'outil d'intégration continue de GitLab (GitLab-CI). À travers un simple script, il nous est ainsi possible d'automatiser toutes les tâches depuis le push (upload des fichiers sources sur le serveur GitLab) du code jusqu'à la livraison du projet.

L’organisation du développement avec PivotalTracker

PivotalTracker est un outil d'organisation pour des projets Agiles. Nous nous en servons pour organiser, déléguer et pondérer l'ensemble des stories. Il nous sert de tableau de bord sur l'avancée du projet.
Il s'intègre très bien avec GitLab et nous permet de retrouver facilement et avec précision quel commit correspond à quel story.

La simplicité de déploiement avec Docker

Docker est un outil qui fait beaucoup parler de lui depuis quelques temps. En effet, il propose une nouvelle approche dans le domaine du développement et du déploiement : la conteneurisation.

La conteneurisation est l'outil le plus en vogue dans le monde DevOps car elle permet de réduire plus que jamais les frictions entre le développement et l'opérationnel. Les ingénieurs produisent une application à l'intérieur d'un conteneur avec toutes les dépendances requises puis le déplace sur un serveur de production une fois l'application prête (nous y reviendrons dans un prochain article). Ainsi, développement et opération utilisent toujours un environnement commun.

La livraison continue

La livraison continue ou continuous delivery est un processus qui demande l'automatisation de l'ensemble des actions entre le code d'une application tout juste écrit et sa livraison. À ne pas confondre avec le déploiement continu ou continuous deployment qui lui gère en plus l'automatisation du déploiement de l'application.

Différences entre la livraison continue et le déploiement continu

La livraison continue nous apporte plusieurs avantages dans le développement de nos applications web :

  • Un déploiement accéléré: à chaque push, GitLab lance les tests sur la nouvelle version de l'application et construit une image Docker prête à être déployée en production. Il ne nous reste ensuite qu'à placer cette image sur le serveur du client chez son hébergeur.
  • Une qualité améliorée: Comme nous effectuons les tests à chaque push, nous sommes alertés rapidement en cas de régression ou autre problème sur la dernière version du projet déployée. Cela permet aux développeurs de se focaliser sur d'autres choses que la résolution de bugs comme l'amélioration des performances ou encore les tests de sécurité.
  • Un développement facilité: Comme nous n'avons que peu de temps pour développer nos projets, il est agréable, en tant que développeur, de se soucier uniquement du code à créer et non des multiples soucis de déploiement habituels.

Bien évidemment, toute solution n'a pas que des avantages. Le passage à une manière de faire DevOps a été la source de quelques soucis, toutefois plus liés aux changements de processus qu'à la solution elle-même. En effet, étant peu voir pas expérimentés en ce qui concerne la culture DevOps, il nous a été difficile de mettre en place le pipeline de livraison automatisé. L'adoption de Docker a également généré quelques "gueulantes" de la part des développeurs du fait de son changement de paradigme. Cependant, après quelques mois de prise en main, nous apprécions grandement la facilité que nous apporte cette solution pour une efficacité visible.

Pour maîtriser au plus vite la méthodologie DevOps, nous nous sommes grandement reposés sur le livre "Découvrir DevOps" qui est aujourd'hui une référence dans le domaine.

Le pipeline de livraison automatisé

Pour entrer un peu plus dans la pratique maintenant, nous allons aborder comment nous mettons en oeuvre notre pipeline de livraison automatisé.

Comme nous l'avons dit, GitLab, à travers son outil GitLab-CI, nous permet de gérer le plus aisément possible un pipeline pour un dépôt, à la manière de Jenkins.

La définition du pipeline est réalisée à travers un fichier YAML ".gitlab-ci.yml" à la racine du dépôt. Nous n'allons pas nous attarder sur la configuration de ce fichier car la documentation fournie par GitLab n'a pas besoin de rajout mais nous allons détailler les quelques étapes que nous avons pour un pipeline de livraison en prenant l'exemple de Thyme, notre service de gestion de bénévoles.

Le pipeline est divisé en 3 étapes (ou stages selon la nomenclature de Gitlab) :

  1. build: On construit une image Docker de l'application avec le tag build puis on la pousse vers notre Docker registry hébergé en interne. Ce registry est utilisé comme un cache d'image Docker facilitant le pipeline.
  2. test: On récupère l'image de build depuis le registry et on effectue tous les tests sur notre application. Notez que nous utilisons pour l'occasion un conteneur de base de données que nous détruisons à la fin des tests. Si un test ne passe pas, le pipeline s'arrête et les développeurs reçoivent une notification par l'intermédiaire de la messagerie Slack.
  3. release: Si l'image de build a passé tous les tests avec succès, alors nous lui attribuons le tag latest et la poussons sur le registry.

Ainsi, nous sommes assurés que l'image ayant le tag latest sur le Docker registry contient la version valide la plus à jour de notre application. Nous pouvons donc déployer facilement la dernière version en production avec une unique commande sur le serveur de production :

docker run -d -P docker.octree.ch/thyme:latest

docker.octree.ch correspond à l'adresse du Docker registry

Ce pipeline est lancé à chaque fois qu'un développeur fait un push sur GitLab. Il est possible de surveiller les étapes par l'intermédiaire de l'interface web.

La visualisation du pipeline sur GitLab

Comme on peut le voir sur la capture d'écran, nous ajoutons des instructions dans les messages de commit pour mettre à jour PivotalTracker. Par exemple, le commit contenant [#13378337 delivers] va informer PivotalTracker que la story n°13378337 est à passer en statut Delivered, prête pour une acceptation de la part du chef de projet.

Pour la suite

Dans cet article, nous n'avons pas eu le temps d'aborder comment nous créons une image Docker pour nos applications. Nous aborderons cela dans un prochain article plus détaillé.

Maintenant que nous avons un pipeline permettant de faire de la livraison continue, nous souhaitons aller jusqu'au bout et atteindre le déploiement continu en automatisant la dernière étape: la mise en production.

À moyen terme, nous avons pour objectif d'avoir une réelle culture DevOps au sein de l'entreprise et la mise en place de ces outils est notre premier pas en ce sens. Après quelques mois, nous avons déjà observé une réelle croissance de l'efficacité et de la motivation des développeurs car chacun peut se concentrer pleinement sur ce qu'il aime faire: développer.

Références :