Comme notre équipe de livraison, en utilisant uniquement nos propres ressources, refait notre système sous CI / CD.
Les équipes d'ingénieurs sont constamment sous pression: vous devez donner de nouvelles fonctions sous la forme d'un produit digne et en même temps minimiser constamment le temps de cycle . Souvent, les experts sans saisir les outils modernes. L'intégration et la livraison continues (CI / CD) sont intégrées à GitLab, notre seule application de cycle de vie DevOps, et maintenant nous migrons vers Kubernetes pour réduire encore plus le temps de cycle. Cependant, pour le CI / CD - et finalement Kubernetes - nous sommes allés d'une manière plutôt inhabituelle. L'équipe de livraison , nous amenant à la livraison continue de GitLab.com, a mis à rude épreuve l'ancien système, et c'est seulement à ce moment-là que nous sommes complètement passés à Kubernetes.
Comment nous avons publié les versions avant CI / CD
Entre le 7 août et le 27 septembre 2019, l'énorme communauté GitLab et les membres de notre équipe ont atteint une moyenne de 55 commits par jour - ce sont des itérations continues de notre produit pour créer de nouvelles fonctionnalités. Mais avant de maîtriser la livraison continue, nous avons utilisé des périodes de gel de nouvelles fonctions à partir du 7 de chaque mois: à ce moment, nos ingénieurs ont détourné leur attention du développement de nouvelles fonctions vers le débogage pour préparer les prochaines versions à sortir de manière stable le 22 de chaque mois.
En introduisant un délai strict, nous avons inculqué aux développeurs un comportement qui les a finalement aidés à se concentrer sur une date spécifique, plutôt que sur la préparation.
"... les développeurs ont commencé à danser à partir du 7e jour, car ils ont regardé le calendrier et ont pensé: eh bien, il est encore temps, le 7e jour de la semaine, puis, à minuit le 6, ils ont frénétiquement fusionné", a déclaré Marine. Jankowski , CTO de l'équipe de livraison. «Ils savent que s'ils dépassent les délais, ils devront attendre encore un mois et s'ils parviennent à le faire à temps, ils auront encore deux bonnes semaines pour déboguer.»
Depuis la création de GitLab.com, des périodes de gel des nouvelles fonctionnalités ont été utilisées comme temps de stabilisation », a expliqué Marine.
Cependant, le nombre d'utilisateurs augmente et le besoin de nouvelles fonctionnalités nous oblige à accélérer le rythme de développement. La période de stabilisation a ralenti le cycle et considérablement retardé la transition vers le débogage, la régression et la livraison de fonctions - à la fois aux utilisateurs de Gitlab.com et aux clients individuels.
«Dans certains cas, [le gel de nouvelles fonctionnalités] a même provoqué une instabilité de la plate-forme - du fait que les correctifs de priorité absolue n’ont pas été livrés au client à temps», a expliqué Marine. - "En passant à CI / CD, nous livrons de nouveaux produits et les déboguons beaucoup plus rapidement."
Avant de former l'équipe de livraison pour déplacer GitLab.com vers une livraison continue - et finalement vers Kubernetes - nous dépendions du responsable de la version . C'était une position de transition parmi les développeurs qui était tenue par celui qui préparait la nouvelle version. Nous itérons le processus depuis plus de 5 ans , mais les responsables des versions ont créé une base de connaissances et l'ont plus ou moins automatisée.
Cependant, la méthode s'est avérée inefficace, car le calendrier de déploiement et la préparation à la publication ont flotté: d'une demi-journée à plusieurs jours en raison du fait que les tâches à exécuter manuellement s'accumulaient dans le processus .
"Le responsable de la publication a reçu une liste fixe de tâches, un délai et a répété les étapes ci-dessus encore et encore jusqu'à ce qu'une version complètement prête et stable sur GitLab.com soit obtenue", a déclaré Marine. Dans le sens le plus général, les éléments suivants étaient requis du gestionnaire de versions:
- Synchronisation manuelle des nombreux référentiels qui composent GitLab.
- Assurez-vous que les versions correctes sont incluses dans les branches Git créées manuellement.
- Lorsque la version reçoit les balises, déployez manuellement les environnements de test et de production sur GitLab.com.
- Assurez-vous que tout fonctionne et publiez manuellement les packages pour les utilisateurs individuels.
Lors d'une présentation à Brooklyn lors du GitLab Commit sur ce sujet, Marine a partagé les résultats des observations pour 2018: au cours de la période de deux semaines précédant la publication, l'équipe de livraison a passé 60% du temps à cajoler avec les déploiements, 26% ont consacré à des tâches manuelles et semi-manuelles comme la rédaction d'une revue version mensuelle.
Résultats d'observation pour 2018, avant de passer à la livraison continue: c'est ainsi que l'équipe Delivery a passé du temps 2 semaines avant la sortie.
"De manière générale, puis 14 jours, deux semaines avant la sortie, l'équipe n'a fait que ce qu'elle regardait les moniteurs, en regardant comment la peinture séchait, ou quelque chose", a déclaré Marine.
Mais en assumant 86% de cette tarte (60% pour les déploiements + 26% pour les tâches manuelles), l'équipe de livraison résoudrait un certain nombre de problèmes:
- Nouvelles versions sans délai.
- Déploiements reproductibles et plus rapides sans temps d'arrêt.
- Plus de temps pour migrer GitLab.com vers Kubernetes.
- Plus de liberté pour préparer votre organisation à une livraison continue.
Bien que le CD ne soit disponible que sur GitLab.com, nos clients individuels bénéficient également de notre transition vers celui-ci. Désormais, tout ce qui n'est pas affecté par les tests CI est testé automatiquement et manuellement dans les environnements - avant d'accéder à GitLab.com. Tout ce qui arrive sur GitLab.com et qui nécessite un débogage sera débogué en quelques heures. Ainsi, la version finale pour les clients individuels sera propre.
La transition du gel au CD était une question de temps, car notre pile de fonctions s'est développée, et une équipe d'ingénieurs dirigée par Marina a semblé observer la transition: «L'équipe de livraison a été formée dans le seul but de transférer l'entreprise vers le modèle de CD, et en même temps de transférer l'entreprise. à la plate-forme Kubernetes pour faciliter la mise à l'échelle et accélérer le cycle. "
La plupart des entreprises à la place de GitLab entameraient la transition vers CI / CD et Kubernetes, intégrant d'abord les nouvelles technologies dans leur flux de travail et corrigeant le processus de développement dans le processus. Nous avons choisi une approche différente.
La migration vers Kubernetes nécessite un changement non seulement dans le système de production, mais aussi dans l'approche de développement », a déclaré Marine. Kubernetes offre certaines fonctionnalités qui sont disponibles facilement et sans investissement supplémentaire. Mais pour vraiment profiter des fonctionnalités gratuites offertes par Kubernetes, vous avez besoin d'une sorte de CI / CD.
L'équipe de livraison l'a accepté: afin de faciliter la transition vers Kubernetes pour une livraison continue, nos ingénieurs devraient déjà travailler en mettant l'accent sur le CI / CD, ce qui implique un contrôle de qualité (QA) amélioré et une planification des fonctions plus stricte. Et puis notre équipe de livraison a pris une sombre décision : construire un système de CD avec les outils existants et réorganiser l'infrastructure de l'application GitLab.com - au lieu de maîtriser immédiatement les nouveaux outils et technologies de CD.
"L'idée était simple", a déclaré Marin, "nous utilisons les outils disponibles , automatisons la plupart des tâches manuelles et testons l'ensemble du système statique sous charge. Si le système statique résiste, nous procédons au test dynamique."
Cette approche a procuré deux avantages clés:
Premièrement , nous avons identifié toutes les faiblesses de notre approche et les avons stabilisées en automatisant avec CI, afin que notre application se renforce et que le succès de la transition vers Kubernetes devienne plus réel.
Deuxièmement , mettre en place une équipe d'ingénieurs sur CD, que nous avons implémenté dans l'esprit des ingénieurs de GitLab, habitués aux déploiements chaque semaine et attendre, parfois toute la journée, car ils affectent la fusion, est un véritable changement culturel.
"Depuis que nous maîtrisons CI / CD, nos développeurs ont commencé à comprendre d'une nouvelle manière ce que cela signifie", a déclaré Marine.
Avant l'introduction du CI / CD, le changement était considéré comme prêt dès la fin de l'examen. Cela a éliminé le déploiement dans divers environnements, ce qui prenait beaucoup de temps. Aujourd'hui, les déploiements sont livrés en quelques heures, il n'y a donc aucune raison de ne pas confirmer que les changements sont opérationnels dans les environnements de test et de production.
Le déploiement des applications de révision de Kubernetes permet aux développeurs d'exécuter des contrôles de qualité littéralement en temps réel, et l'utilisation d'indicateurs de fonctionnalité pour une livraison progressive accélère également le développement.
"Dès la toute première étape du CD, les développeurs sont tenus de répondre à chaque contrôle qualité automatisé, et également d'effectuer des confirmations manuelles à un nouveau niveau dans les environnements de production et de test. De plus, les développeurs peuvent apporter des modifications à l'environnement de production en une journée alors qu'auparavant, cela prenait plusieurs jours (voire des semaines). "
Avec CD, vous pouvez effectuer des contrôles de qualité de code beaucoup plus souvent. Et comme avec notre système CI / CD, les modifications du code sont fournies 24h / 24, les développeurs tournent à la demande pour tout problème non standard qui apparaît en temps réel, car la "période d'incubation" est considérablement réduite.
Notre nouvelle méthode
Après avoir implémenté le système CI / CD , nous avons automatisé 90% du processus. Les 10% restants nécessitent une intervention humaine - une coordination est nécessaire entre de nombreuses personnes ayant le droit d'accès.
"Nous réduisons progressivement ces 10% - de sorte que nous n'avons besoin que d'une approbation pour la publication du communiqué", a déclaré Marine. Dans l'itération actuelle, le processus CI / CD fonctionne comme suit :
- CI recherche automatiquement des balises spécifiques dans les demandes de fusion approuvées par les réviseurs et les développeurs.
- CI synchronise automatiquement les référentiels requis et crée en même temps les branches et balises Git nécessaires, et inclut également les versions correctes que nous voulons fournir.
- Une fois les générations terminées, les packages sont automatiquement déployés pour tester les environnements.
- Des contrôles de qualité automatiques sont effectués et, si tout se passe bien, le déploiement est livré à un petit segment d'utilisateurs dans un environnement de production.
- Parallèlement à cela, les développeurs effectuent manuellement un contrôle qualité d'un niveau différent - pour s'assurer que les nouvelles fonctions fonctionnent comme elles le devraient.
- Si un problème de haute priorité est découvert lors de la confirmation manuelle, les déploiements s'arrêtent.
- Une fois l'étape précédente terminée, le membre de l'équipe de livraison démarre la livraison du déploiement pour tous les utilisateurs de GitLab.com.
- Ensuite, sur la base du dernier déploiement de production lancé sur GitLab.com, une version client individuelle est créée.
Comme pour toute autre équipe d'ingénierie, la mise à l'échelle est un véritable défi pour nous. Cependant, l'un des plus grands défis pour les techniciens est de s'assurer que le contrôle qualité couvre tout, mais pour un grand projet comme GitLab.com, c'est un travail intense. Et vous devez également vous assurer qu'il y a suffisamment de surveillance et de notification, afin que le projet ne fonctionne pas uniquement sur des règles prédéfinies.
Le deuxième défi majeur pour nous est la complexité du système GitLab.com et le transfert des modifications en cours de processus à toutes les équipes d'ingénierie. "Briser le processus et les habitudes qui ont été établies au fil des ans est loin d'être facile", a déclaré Marine.
Résultats
GitLab profite déjà beaucoup du passage au CI / CD.
Les observations et l'évaluation en 2019 ont montré que dans les 14 jours précédant la sortie, l'équipe de livraison passe 82% du temps plus productif: elle a été libérée pour travailler sur d'autres tâches importantes.
L'observation pour 2019 a montré que dans les mêmes 2 semaines, beaucoup de temps précieux a été libéré des développeurs grâce à la transition vers c CD.
En automatisant le travail manuel, l'équipe de livraison est finalement passée à la modification de l'infrastructure de GitLab.com pour améliorer la prise en charge de la vitesse de développement et du trafic des utilisateurs, et en même temps, la migration vers Kubernetes.
"Et, comme je l'ai déjà dit, tout cela est sans Kubernetes. Tout a été fait sur l'ancien système précédent", a déclaré Marine aux invités du Brooklyn GitLab Commit. - "Mais nous avons gagné du temps, alors maintenant mon équipe est étroitement impliquée dans la migration. Cependant, l'un des plus grands changements s'est produit précisément dans l'habitude d'organiser le développement."
Les résultats après la transition sont significatifs. Si sur l'ancien système en mai 2019, l'équipe a livré quelque part 7 déploiements, alors en août 2019, ce chiffre est passé à 35. Et ce n'est pas la limite: les chiffres augmenteront considérablement - maintenant que l'équipe fournit de nombreux déploiements quotidiennement.
"Nous venons de migrer notre service de registre vers Kubernetes, et si vous utilisez le registre de conteneurs sur GitLab.com , toutes vos demandes sont exécutées sur la plate-forme Kubernetes", a déclaré Marine. - "GitLab est un système multi-composants, et nous continuons à isoler et à transférer d'autres services."
Chaque nouvelle version comprend de nouvelles fonctionnalités CI / CD. Par exemple, dans la version 12.3, nous avons étendu le registre de conteneurs GitLab - permettant aux utilisateurs d'utiliser CI / CD et de collecter et d'incorporer des images / balises dans leurs propres projets . Il y avait d'autres nouvelles innovations passionnantes.
Transférer également le système à une livraison continue?
Marin a conseillé aux entreprises qui sont sur le point de passer au CD de commencer avec ce qu'elles ont.
"Quant à moi, rester assis et attendre la migration vers une nouvelle plateforme, c'est se faire du mal", a expliqué Marine. "La plupart des systèmes peuvent être modifiés d'une manière ou d'une autre et accélérer le cycle de traitement sans migrer vers un système complètement nouveau. L'accélération du cycle de développement / version augmente considérablement l'efficacité de chaque ingénieur du système et libère plus de temps pour migrer vers une nouvelle plate-forme, telle que Kubernetes."
Si vous êtes curieux de savoir ce qui va suivre, jetez un œil à ce résumé détaillé des nouvelles fonctionnalités passionnantes de CI / CD qui attendent dans les coulisses - à partir de la version 12.4.
Vous avez manqué le Brooklyn GitLab Commit?
Si vous n'avez pas pu assister à la présentation de Marina avec le contexte de notre transition vers Kubernetes, regardez la vidéo complète ci-dessous et rejoignez-nous à l' European GitLab Commit à Londres, le 9 octobre .