Qu’est ce que le GitOps et comment l’appliquer dans un environnement réel ?
Comment en sommes-nous arrivés là ?
En 2006, avec le lancement du service AWS Elastic Compute, Amazon a déclenché une révolution dans la manière dont nous, en tant que développeurs, consommons et utilisons les ressources informatiques nécessaires pour déployer et maintenir les applications que nous écrivons. Très peu de temps après, l’infrastructure-as-code a commencé à exploser avec des projets comme Puppet, Ansible et Terraform.
À mesure que ces technologies ont gagné en maturité, il est devenu évident que mettre à l’échelle des applications dans un environnement moderne ou cloud nécessitait des composants duplicables et réutilisables mais aussi que l’infrastructure-as-code devenait le nouveau standard pour s’assurer que les bonnes ressources soit allouées à une application. Dans le même temps, le monde de l’infrastructure et du logiciel a continué à évoluer. Les concepts de livraison continue et de diffusion continue des logiciels est entré en vogue et a été popularisé par les grandes entreprises de la tech. Le “Manifeste” sur la livraison continue est sorti en 2011. Dans celui-ci, il est apparu que pour aller assez vite et être capable de suivre les demandes du marché, il fallait un cycle DevOps radicalement plus rapide.
La livraison continue de logiciels devenant de plus en plus courante, de nouvelles solutions dans le domaine de l’infrastructure ont été créées pour suivre le rythme. Kubernetes et la montée en puissance du « serverless » promettaient de libérer une fois de plus les développeurs de la nécessité de se préoccuper de l’infrastructure. Dans un monde post-DevOps, comment peut-on penser à l’infrastructure-as-code et les applications comme un seul ensemble cohérent ? Voici GitOps.
Qu’est ce que le GitOps ?
Conceptuellement, le GitOps n’est pas très différent de l’infrastructure-as-code ou de la livraison continue. En fait, à bien des égards, c’est la convergence de ces deux concepts. Les équipes de développement et des opérations peuvent tout aussi bien partager un dépôt de code commun et le GitOps permet une expérience similaire à celle d’un développeur pour gérer des applications et leur infrastructure sous-jacente. De cette manière, vous pouvez utiliser le GitOps comme un modèle opérationnel pour des infrastructures modernes comme Kubernetes, le serverless ou toute autre technologie cloud native.
La gestion de versions et l’intégration continue sont des outils essentiels pour déployer des logiciels de manière continue et fiable. Le GitOps apporte ces deux bonnes pratiques logicielles en faisant du dépôt Git la source centrale de vérité pour toute l’infrastructure requise pour faire tourner les applications. Avec le GitOps, un commit est fait dans le dépôt Git lors de la moindre modification de l’infrastructure de même que tout changement au niveau d’une application.
Cela permet aux développeurs et aux ops d’utiliser des modèles de développement et des stratégies de branching qui leurs sont familiers. A partir de là, la demande de fusion devient l’endroit central pour collaborer et suggérer des changements. Une fois fusionnée dans la branche principale, la CI/CD devrait être configurée pour déployer automatiquement les changements de l’application et de l’infrastructure. La façon dont cela permet la synchronisation entre les développeurs et les ops est ce qui est très attrayant dans le GitOps, la prochaine itération du DevOps.
Pourquoi l’approche GitOps ?
Pourquoi tant d’organisations petites et grandes envisagent-elles de passer à une culture plus centrée sur le GitOps ?
Au fur et à mesure que le logiciel a conquis le monde, l’excellence opérationnelle des entreprises est devenue directement liée à la capacité de fournir des logiciels de qualité plus rapidement. La capacité de survie des entreprises dépend de pratiques de développement de logiciels adaptatives et efficaces. Ces pratiques exigent de nouveaux processus et des modifications dans notre façon de penser la gestion du changement.
Dans de nombreuses pratiques logicielles, c’est le concept de revue et d’approbation du code qui est à l’origine de la plupart des contrôles et équilibres pour le déploiement du code de production. Chez GitLab, ils croient que la demande de fusion est le meilleur endroit pour collaborer sur le code et approuver les changements. Les processus et les outils qui sont extérieurs au changement du code ne servent qu’à augmenter le cycle de temps et à inhiber la capacité d’une entreprise à déployer du code rapidement.
Une fois qu’une entreprise a adopté l’intégration continue et la revue de code comme l’endroit où on approuve des demandes de changement, c’est de façon naturelle qu’on en vient à discuter de l’idée de livraison continue pour la production et tout ça dès que les validations humaines ont été franchies. Alors que le GitOps pousse ce concept un peu plus loin et intègre le pipeline vers la production directement dans le flux de travail de Git et des demandes de fusion, c’est devenu un sujet brûlant qui va transformer le flux de travail quotidien pour les entreprises de logiciels qui sont efficaces. Le fait de retirer des étapes et des outils du chemin déterminant qui mène à la production permet à une entreprise de livrer de meilleurs produits plus rapidement et tout ça sans sacrifier la gouvernance nécessaire au déploiement du code.
Vous cherchez des utilisateurs ou une instance GitLab hébergée en France ? Rejoignez la Communautés Froggit.
Crédits
Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction issue du site de GitLab. Crédits image : photo de couverture de Shiro Atori sur Unsplash
