Pourquoi la technologie de collaboration de GitLab est-elle essentielle pour GitOps ? Découvrez-le dans cette démo
Les logiciels de collaboration comme GitLab simplifient les workflow GitOps. Dans cet article, une démonstration illustre comment GitLab renforce et facilite les pratiques GitOps grâce à ses fonctionnalités de collaboration.
GitOps fait référence à l'utilisation d'un dépôt Git comme source unique de vérité pour tout le code qui entre dans la compilation de l'infrastructure et le déploiement d'applications. En utilisant un système de contrôle de version, tel que Git, comme source unique de vérité, les ingénieurs sont en mesure de mettre à jour le code source sous-jacent pour leurs applications dans un format de livraison continue.
Le système de contrôle de version assure la documentation et la visibilité, tandis qu'une piste d'audit permet la conformité. GitOps permet d'annuler facilement les modifications et fournit un emplacement unique pour accéder aux informations les plus récentes afin d'aider les équipes à comprendre l'état actuel, du point de vue des équipes de développement logiciel et des opérations.
GitLab est une application unique pour l'ensemble du cycle de vie du processus DevOps. Elle constitue une plateforme de collaboration qui permet aux parties prenantes de peser sur le processus de production du code. La collaboration est un aspect important du processus GitOps. Les équipes, qu'il s'agisse des équipes d'infrastructure et de développement ou des parties prenantes de la sécurité et de l'entreprise, ont besoin d'une méthode facile pour collaborer afin de livrer le code rapidement et efficacement tout au long du cycle de vie de développement.
L'approche GitOps ne se limite pas au code, elle est étroitement liée à la collaboration, et GitLab permet à chaque équipe de travailler sur une seule plateforme.
Le reste de l'article contient une démo sur l'influence de la collaboration favorisée par GitLab dans GitOps. La démo présente des exemples d'epics et de tickets, dont les liens d'accès figurent dans les sections suivantes.
Planifier un projet avec des epics
Étant donné que GitOps est un déploiement centré sur le contrôle de version, la première étape consiste à définir la portée du projet et à identifier les parties prenantes. Les membres de l'équipe peuvent ensuite partager toutes les autres informations qui pourraient être nécessaires à la réalisation du projet, telles que le codage, les modifications de l'infrastructure en tant que code (IaC), ainsi que les modifications qui doivent être examinées et éventuellement déployées en production.
Après avoir ouvert un epic dans le dépôt associé, les équipes peuvent ajouter des objectifs et des tâches dans la description. Un epic permet aux équipes de suivre des tickets dans différents projets et jalons. Un ticket constitue le principal support d'échange d'idées et de planification du travail dans GitLab.
Exemple d'epics et de tickets
Dans cet exemple d'epic, appelé Mettre à l'échelle le cloud, les équipes peuvent voir le processus de mise à l'échelle d'un cluster Kubernetes dans GitLab. Étant donné la nature multicloud de GitLab, il existe trois tickets distincts pour la démo qui expliquent ce qui est nécessaire pour déployer le cluster Kubernetes dans chaque environnement unique : Azure (AKS), Google (GKE) et Amazon (EKS).
Favoriser la collaboration et la transparence avec GitLab
Au niveau de l'epic, les équipes peuvent voir que le ticket de mise à l'échelle à l'intérieur du cluster Amazon EKS a déjà été résolu. Cliquer sur le ticket permet de révéler qu'une merge request a été créée à partir des tâches décrites dans le ticket, et que la MR est déjà fusionnée.
Pour voir exactement ce qui a changé entre le code d'origine et le code actuel, cliquez à l'intérieur de la MR. Les équipes peuvent y voir tous les tests qui ont abouti avant/après la fusion, y consulter l'historique des commentaires pour identifier les modifications et noter qui a approuvé et fusionné le code.
Le ticket de mise à l'échelle vers GKE n'est pas encore résolu. La merge request est encore un travail en cours, ce qui signifie que rien n'a encore été modifié. Il y a un commentaire sur la MR de Terraform, qui indique que le nombre de nœuds doit passer de deux à cinq pour préparer l'environnement GKE au déploiement. L'approbateur de la MR clique sur « Résoudre le statut du travail en cours » pour lancer le pipeline et il peut choisir de supprimer la branche source pour fusionner le nombre de nœuds mis à jour.
Pour que GitLab soit un outil de collaboration efficace, il doit également être transparent. C'est pour cela que tout le monde dans l'entreprise est en mesure de voir un ticket et la MR associée par défaut. Le ticket et la MR peuvent être attribués à un collaborateur, ou le collaborateur peut être étiqueté dans la section des commentaires pour qu'il ajoute le ticket à sa liste À traiter.
En revenant à la vue Epic, qui est souvent utilisée par les parties prenantes pour voir l'avancement du projet, les équipes peuvent constater que le déploiement de la mise à l'échelle de GKE sur cinq nœuds est en cours.
En utilisant GitLab pour un workflow GitOps, chaque membre de l'équipe est en mesure de travailler à partir du même système et de comprendre le statut des projets. Que ce soit en matière d'infrastructure ou de développement d'applications, toutes les modifications suivent le même processus, qui consiste à définir le travail à accomplir dans son ensemble, à l'attribuer à des individus, à collaborer avec des coéquipiers, à déployer le code et à utiliser le dépôt Git comme source unique de vérité.
Lancez-vous dès maintenant
Découvrez comment la plateforme DevSecOps alimentée
par l'IA la plus complète peut aider votre équipe.