Introduction au Gitops
faire une code commits au moins quotidienne, voire plusieurs fois par jour. Les tests de vérification doivent eux aussi être automatisés. Les tests unitaires seront généralement les premiers à être automatisés afin de réduire au plus vite la charge de travail des développeurs. Suivront les tests fonctionnels, puis les tests d’interface utilisateur. Les tests fonctionnels ne requièrent généralement pas de mises à jour fréquentes du script d’automatisation, contrairement aux tests UI qui induiront certainement des changements plus fréquents. En résumé, il faut essayer de prendre en considération l’ensemble des dépendances possibles et évaluer leur impact afin de définir avec précision les tâches d’automatisation prioritaires.
Déploiement
Il existe différentes méthodes de déploiement : canary release, BlueGreen, tests A/ B. En mode canary release, la mise à jour est poussée vers un petit groupe d’utilisateurs qui vont la tester. Si tout va bien, elle sera déployée. Sinon, le processus reprend à l’étape précédente. Concernant les bonnes pratiques en la matière et le fonctionnement du CI/ CD as a service, nous vous renvoyons à l’article de Guillaume Perissat à l’adresse https:// www. linformaticien. com/ dossiers/ cicd- as- aservice. aspx
Gitlab CI
Gitlab CI est un outil d’intégration continue intégré à Gitlab. Il sert à la fois à héberger du code et à développer des référentiels git. Initialement publié en tant que projet autonome, Gitlab CI a été intégré dans le logiciel principal Gitlab avec la sortie de Gitlab 8.0 en 2015. Gitlab CI est donc une composante de Gitlab programmée en Ruby et en Go. Il supporte la livraison et le déploiement en continu. Il est open core et peut être auto- hébergé ou hébergé sur le Cloud. La version gratuite ne propose que quelques fonctionnalités. Pour un pack plus complet, le tarif varie de 4 à 99 $ par mois et par utilisateur. Dans Gitlab CI, le processus CI/ CD est défini dans un fichier du référentiel de code grâce à des instructions de configuration en YAML. Le travail à effectuer est ensuite envoyé aux machines appelées « coureurs » , faciles à configurer et pouvant de plus être provisionnées sur de nombreux systèmes d’exploitation. Lors de la configuration des coureurs, vous pouvez choisir votre outil et votre mode d’exécution des tâches ( Docker, Kubernetes, Virtualbox…).
Le principe du Gitops rejoint celui de l’infrastructure as code mais avec des contraintes clairement définies permettant de garantir les « bonnes pratiques » . L’infrastructure as code et de ce fait le Gitops reposent en grande partie sur la formalisation sous forme déclarative de l’infrastructure. Cela se traduit concrètement par l’usage d’outils tels qu’ansible, Chef/ Puppet, Terraform, Powershell DSC, Salt et, bien sûr, Kubernetes. Tout changement doit être décrit de manière déclarative via un outil de provisionnement ou de déploiement. Ce point est décrit dans le 10e point des 12 factor ( https:// 12factor. net/ dev- prod- parity). Comme son nom peut le laisser penser, Gitops se base sur Git. Néanmoins, d’autres outils de versionning peuvent être employés à la place de Git. L’aspect central du Gitops repose sur le fait de considérer que notre dépôt Git est notre unique source de vérité. La notion de convergence est également un point important du Gitops. Comme le dépôt git contient le code de la dernière release, il faut faire converger les déploiements en fonction de ce qui est décrit dans git. Cela passe notamment par de la supervision active de l’infrastructure et le reporting détaillé des différences constatées.
Le couplage étroit de Gitlab CI avec la plate- forme de référentiel Gitlab a des implications fortes sur la manière dont il peut être utilisé. La fonctionnalité intégrée permet aux utilisateurs de Gitlab de configurer un environnement CI/ CD sans devoir installer – ni apprendre à utiliser – un outil supplémentaire. Les tests automatisés peuvent par exemple commencer
par activer quelques options dans l’interface web, enregistrer une machine d’exécution et/ ou ajouter un fichier de définition de pipeline dans le référentiel. La dite « relation de proximité » vous permet également de partager les coureurs entre plusieurs projets, de voir automatiquement l’état de la construction dans le référentiel et de conserver les artefacts de construction avec le code qui les a produits. Gitlab possède, entre autres, une fonctionnalité appelée Auto Devops qui permet, pour les projets les plus simples, de construire automatiquement un pipeline avec plusieurs tests intégrés. Ce système utilise également des packs de création Herokuish permettant de déterminer le langage employé et la manière de créer l’application. Il offre des intégrations natives dans Kubernetes ce qui lui permet de déployer automatiquement des applications dans un cluster Kubernetes avec une méthodologie de déploiement, comme celles basées sur les pourcentages et la méthode
Blue- Green. Gitlab offre aussi de nombreuses fonctionnalités complémentaires, telles que les opérations et la surveillance avec Prometheus qui est déployé automatiquement avec votre application. Gitlab CI permet la gestion de portefeuilles et de projets avec Gitlab Issues, Epics et Milestones et de modifier le code directement dans Gitlab avec WEBIDE. Vous pouvez
ainsi obtenir un aperçu ou exécuter une partie d’un pipeline pour une analyse plus rapide.
Jenkins
Jenkins ( https:// jenkins. io/) est un outil open source adapté au Devops avec une dimension collaborative. Il est écrit en Java et publié sous licence MIT. C’est l’un des tout