Chez GitLab, nous traitons les correctifs logiciels de deux manières : manuellement et automatiquement. Poursuivez votre lecture pour en savoir plus sur le travail du gestionnaire de versions consistant à créer et à fournir des mises à jour importantes via un déploiement automatisé sur gitlab.com, ainsi que des correctifs permettant aux utilisateurs de travailler sur leurs propres installations.
Je vous recommande de définir un rappel sur votre montre intelligente : chaque mois, le 22, les utilisateurs travaillant avec GitLab dans leurs locaux peuvent voir les mises à jour de la version actuelle de notre produit. La version mensuelle contient de nouvelles fonctionnalités, des développements de celles existantes et montre souvent le résultat final des demandes d'outils ou de fusions de la communauté.
Mais, comme le montre la pratique, le développement de logiciels est rarement sans défauts. Lorsqu'un bug ou une vulnérabilité de sécurité est découvert, le responsable des versions de l'équipe de livraison crée un correctif pour nos utilisateurs avec leurs installations. Gitlab.com est mis à jour pendant le processus du CD. Nous appelons ce processus CD déploiement automatique pour éviter toute confusion avec la fonctionnalité CD dans GitLab. Ce processus peut intégrer des suggestions provenant de demandes d'extraction soumises par les utilisateurs, les clients et notre équipe de développement interne, de sorte que la résolution du problème ennuyeux de la publication de correctifs soit résolue de deux manières très différentes.
«Nous veillons à ce que tout ce que les développeurs créent soit déployé quotidiennement dans tous les environnements avant de le déployer sur GitLab.com.", explique , Responsable Technique Senior, Département Infrastructure. "Considérez les versions de vos installations comme des instantanés pour les déploiements gitlab.com, pour lesquels nous avons ajouté des étapes distinctes pour créer un package afin que nos utilisateurs puissent l'utiliser pour l'installer sur leurs installations.».
Quel que soit le bug ou la vulnérabilité, les clients de gitlab.com recevront les correctifs peu de temps après leur publication, ce qui constitue un avantage du processus automatisé de CD. Les correctifs destinés aux utilisateurs disposant de leurs propres installations nécessitent une préparation séparée par le gestionnaire de versions.
L'équipe de livraison travaille dur pour automatiser la plupart des processus impliqués dans la création de versions afin de réduire (délai moyen de production, c'est-à-dire temps passé en production), délai écoulé entre le traitement d'une demande de fusion par un développeur et le déploiement sur gitlab.com.
«L'objectif de l'équipe de livraison est de s'assurer que nous pouvons avancer plus rapidement en tant qu'entreprise, ou au moins faire travailler les livreurs plus rapidement, n'est-ce pas?, dit Marin.
Les clients de gitlab.com et les utilisateurs de leurs installations bénéficient des efforts de l'équipe de livraison pour réduire les temps de cycle et accélérer les déploiements. Dans cet article, nous expliquerons les similitudes et les différences entre ces deux méthodes. , et nous décrirons également comment notre équipe de livraison prépare les correctifs pour les utilisateurs exécutés sur site, et comment nous maintenons gitlab.com à jour grâce au déploiement automatisé.
Que fait un gestionnaire de versions ?
Membres de l'équipe mensuellement nos versions aux utilisateurs dans leurs installations, y compris les correctifs et les versions de sécurité qui peuvent survenir entre les versions. Ils sont également chargés de diriger la transition de l'entreprise vers un déploiement automatisé et continu.
Les versions d'auto-installation et les versions de gitlab.com utilisent des flux de travail similaires mais s'exécutent à des moments différents, explique Marin.
Avant tout, le gestionnaire de versions, quel que soit le type de version, garantit que GitLab est disponible et sécurisé dès le lancement de l'application sur gitlab.com, notamment en s'assurant que les mêmes problèmes ne se retrouvent pas dans l'infrastructure des clients avec leur propres capacités.
Une fois qu'un bug ou une vulnérabilité est marqué comme corrigé dans GitLab, le gestionnaire de versions doit évaluer qu'il sera inclus dans les correctifs ou les mises à jour de sécurité pour les utilisateurs avec leurs installations. S'il décide qu'un bug ou une vulnérabilité mérite une mise à jour, les travaux préparatoires commencent.
Le gestionnaire de versions doit décider s'il doit préparer un correctif ou quand le déployer - et cela dépend fortement du contexte de la situation, "en attendant, les machines ne sont pas aussi douées pour gérer le contexte que les humains" dit Marin.
Tout est question de correctifs
Que sont les correctifs et pourquoi en avons-nous besoin ?
Le gestionnaire de versions décide de publier ou non un correctif en fonction de la gravité du bogue.
Les erreurs varient en fonction de leur gravité. Les erreurs S4 ou S3 peuvent donc être stylistiques, comme le déplacement de pixels ou d'icônes. Ce n'est pas moins important, mais il n'y a pas d'impact significatif sur le flux de travail de quiconque, ce qui signifie que la probabilité qu'un correctif soit créé pour de telles erreurs S3 ou S4 est faible, explique Marin.
Cependant, les vulnérabilités S1 ou S2 signifient que l'utilisateur ne doit pas mettre à jour vers la dernière version, ou qu'il existe un bug important qui affecte le flux de travail de l'utilisateur. S'ils sont inclus dans le tracker, de nombreux utilisateurs les ont rencontrés, le gestionnaire de versions commence donc immédiatement à préparer un correctif.
Une fois qu'un correctif pour les vulnérabilités S1 ou S2 est prêt, le gestionnaire de versions commence à publier le correctif.
Par exemple, le correctif GitLab 12.10.1 a été créé après que plusieurs problèmes de blocage ont été identifiés et que les développeurs ont résolu le problème sous-jacent qui les provoquait. Le responsable des versions a évalué l'exactitude des niveaux de gravité attribués et, après confirmation, le processus de publication d'un correctif a été lancé, qui était prêt dans les XNUMX heures suivant la découverte des problèmes bloquants.
Lorsqu'un grand nombre de S4, S3 et S2 s'accumulent, le gestionnaire de versions examine le contexte pour déterminer l'urgence de publier un correctif, et lorsqu'un certain nombre d'entre eux est atteint, ils sont tous combinés et publiés. Les correctifs post-version ou les mises à jour de sécurité sont résumés dans les articles de blog.
Comment un gestionnaire de versions crée des correctifs
Nous utilisons GitLab CI et d'autres fonctionnalités comme notre ChatOps pour générer des correctifs. Le gestionnaire de versions démarre la publication du correctif en activant l'équipe ChatOps sur notre canal interne #releases dans Slack.
/chatops run release prepare 12.10.1ChatOps fonctionne dans Slack pour déclencher différents événements, qui sont ensuite traités et exécutés par GitLab. Par exemple, l'équipe de livraison a configuré ChatOps pour automatiser diverses tâches afin de publier des correctifs.
Une fois que le gestionnaire de versions démarre l'équipe ChatOps dans Slack, le reste du travail s'effectue automatiquement dans GitLab à l'aide de CICD. Il existe une communication bidirectionnelle entre ChatOps dans Slack et GitLab pendant le processus de publication, car le gestionnaire de publication active certaines des principales étapes du processus.
La vidéo ci-dessous montre le processus technique de préparation d'un patch pour GitLab.
Comment fonctionne le déploiement automatique sur gitlab.com
Le processus et les outils utilisés pour mettre à jour gitlab.com sont similaires à ceux utilisés pour créer des correctifs. La mise à jour de gitlab.com nécessite moins de travail manuel du point de vue du gestionnaire de versions.
Au lieu d'exécuter des déploiements à l'aide de ChatOps, nous utilisons les fonctionnalités CI, par ex. , avec lequel le gestionnaire de versions peut planifier certaines actions à effectuer au moment requis. Au lieu d'un processus manuel, il existe un pipeline qui s'exécute périodiquement une fois par heure et télécharge les nouvelles modifications apportées aux projets GitLab, les emballe et planifie le déploiement, et exécute automatiquement les tests, le contrôle qualité et d'autres étapes nécessaires.
"Nous avons donc de nombreux déploiements exécutés dans différents environnements avant gitlab.com, et une fois que ces environnements sont en bon état et que les tests montrent de bons résultats, le gestionnaire de versions démarre les actions de déploiement de gitlab.com", explique Marin.
La technologie CICD pour prendre en charge les mises à jour de gitlab.com automatise l'ensemble du processus au point où le gestionnaire de versions doit lancer manuellement le déploiement de l'environnement de production sur gitlab.com.
Marin détaille le processus de mise à jour de gitlab.com dans la vidéo ci-dessous.
Que fait d’autre l’équipe de livraison ?
La principale différence entre les processus de mise à jour de gitlab.com et la publication de correctifs aux clients en interne est que ce dernier processus nécessite plus de temps et plus de travail manuel de la part du gestionnaire de versions.
« Nous retardons parfois la publication des correctifs auprès des clients avec leurs installations en raison de problèmes signalés, de problèmes d'outils et parce que de nombreuses nuances doivent être prises en compte lors de la publication d'un seul correctif », explique Marin.
L'un des objectifs à court terme de l'équipe de livraison est de réduire la quantité de travail manuel de la part du responsable de la publication afin d'accélérer la publication. L'équipe s'efforce de simplifier, rationaliser et automatiser le processus de publication, ce qui permettra de résoudre les problèmes de faible gravité (S3 et S4, environ. traducteur). Se concentrer sur la vitesse est un indicateur de performance clé : il est nécessaire de réduire le MTTP - le temps entre la réception d'une demande de fusion et le déploiement du résultat sur gitlab.com - des 50 heures actuelles à 8 heures.
L'équipe de livraison travaille également sur la migration de gitlab.com vers une infrastructure basée sur Kubernetes.
N.b. de l'éditeur: Si vous avez déjà entendu parler de la technologie Kubernetes (et je n'en doute pas), mais que vous ne l'avez pas encore touché avec vos mains, je vous recommande de participer à des cours intensifs en ligne , qui se tiendra du 28 au 30 septembre, et , qui aura lieu du 14 au 16 octobre. Cela vous permettra de naviguer et de travailler avec la technologie en toute confiance.
Ce sont deux approches qui poursuivent le même objectif : une livraison rapide des mises à jour, à la fois pour gitlab.com et pour les clients dans leurs locaux.
Des idées ou des recommandations à nous faire ?
Tout le monde est invité à contribuer à GitLab et nous apprécions les commentaires de nos lecteurs. Si vous avez des idées pour notre équipe de livraison, n'hésitez pas marqué team: Delivery.
Source: habr.com