Pourquoi une application unique permet d’éliminer les silos et les lacunes en matière de connaissances.
GitLab a déjà parlé de la façon dont la collaboration harmonieuse entre les équipes de développement et infrastructure est une belle chose. Lorsqu'une organisation a une culture DevOps saine, elle est en mesure d’atteindre ses objectifs commerciaux et d’augmenter la vitesse de livraison. Le DevOps est destiné à éliminer les cloisonnements afin que tout le monde puisse être sur la même longueur d’onde, et les outils que vous utilisez peuvent jouer un rôle important dans la réussite ou l’échec de votre stratégie DevOps.
Des outils compliqués créent des silos
L’une des façons dont les opérations peuvent être désavantagées est de devoir maintenir un environnement de greffons compliqué. Ce scénario devient particulièrement problématique lorsque les choses tournent mal et que les développeurs comptent sur un groupe spécifique pour régler le problème. Si la spécialisation n’est pas nécessairement une mauvaise chose (les développeurs ne devraient pas avoir à faire des opérations, et vice versa), l’expertise nécessaire pour gérer un environnement de greffons est généralement une spécialisation au sein d’un groupe déjà spécialisé.
Jenkins est l’exemple le plus populaire de ce type de complexité, pour plusieurs raisons :
- L’architecture de Jenkins nécessite la maintenance d’un large ensemble de systèmes d’environnement de build. À l’échelle, cela nécessite de nombreuses personnes dédiées pour gérer les machines, installer et gérer les outils de build (NodeJS, Python, Java, etc.), surveiller les machines, etc.
- La mise à jour est un risque (Jenkins ou greffons). Il est fort probable que les mises à jour puissent provoquer des défaillances de processus, ce qui entraînerait des builds défectueux ou du coupure de service.
- La maintenance de Groovy est difficile. Ce n’est pas un langage de script très populaire, il est donc plus difficile de trouver des experts pour le gérer et il est difficile à déboguer en raison du manque de débogueurs.
- Jenkins ne soutient aucune forme d’agrégation ou de basculement (failover). L’interface web fonctionne sur un conteneur web connu sous le nom de Jenkins master, et vous ne pouvez en avoir qu’un seul. Pour une grande équipe de développeurs ayant besoin d’utiliser Jenkins en une seule fois, ce cas doit être surveillé de très près avec des autorisations limitées.
Un grand environnement de plugin Jenkins crée des silos à l’intérieur des silos et des lacunes dans les connaissances qui sont difficiles à surmonter. Cela conduit à une dynamique d’équipe « jeter par-dessus le mur» : comme le système dépend de l’expertise d’un nombre très limité de personnes, les développeurs doivent soumettre le code et espérer que leurs experts ont les compétences nécessaires pour le gérer.
Le manque de visibilité maintient les équipes dans l’obscurité.
Pour que le DevOps puisse prospérer, il faut comprendre ce que chaque équipe fait et clarifier les processus. Malheureusement, un outil comme Jenkins ne facilite pas nécessairement cette tâche. Comme les utilisateurs ne peuvent pas voir les commits des autres utilisateurs, ils ne peuvent pas visualiser le cycle de développement des systèmes dans son ensemble. Cela ne fait qu’isoler encore plus les équipes.
Les équipes qui travaillent dans cet environnement de plug-ins téléchargent souvent les plug-ins dont elles ont besoin, ce qui rend difficile pour les administrateurs de Jenkins la standardisation entre les équipes. Il est donc plus difficile pour les administrateurs de gérer les dépendances et de maintenir les greffons correctement, ce qui peut entraîner d’autres erreurs de build.
Si les greffons sont un moyen courant d’ajouter des fonctionnalités dans une chaîne d’outils, ils ne règlent pas les problèmes d’une chaîne d’outils qui entravent les équipes qui tentent de mettre en œuvre le DevOps :
- Manque de visibilité
- Lacunes en matière de connaissances
- Travail en silo
Pourquoi une application unique de CI/CD permet un meilleur DevOps
En tant que plate-forme DevOps complète livrée sous la forme d’une application unique, GitLab fournit un outil qui couvre toutes les parties du cycle de développement des systèmes à partir d’une interface unique. CI et CD ne sont qu’une partie du cycle de vie, et en ayant des fonctionnalités commeSCM (supply-chain management), suivi des problèmes, tests de sécurité et monitoring, GitLab, et bien sur froggit.fr, faciliteront le travail des équipes avec les meilleures pratiques DevOps.
Si vous souhaitez voir une démo de GitLab CI/CD et comment nous nous situons par rapport à Jenkins, et accéder à d’autres contenus sélectionnés autour de la CI/CD, vous pouvez regarder le dernier webcast de GitLab.
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.
