👩‍🎤 👨🏿‍🏭 🖐🏽 Sortie de GitLab 12.5 avec la création de clusters EKS et le panneau environnement 💅🏿 💴 ⚠️

Une image pour attirer l'attention

Une nouvelle version de GitLab a été publiée avec la création et le déploiement de clusters EKS, la prise en charge de Crossplane, un panneau d'environnement et de nombreuses autres fonctionnalités intéressantes!

Pour la livraison la plus efficace de logiciels de qualité, vous devez prendre en charge une large gamme d'infrastructures et plusieurs plateformes cloud . La version GitLab de ce mois-ci facilite la configuration, le suivi et la gestion de projets avec une variété de configurations.

Créer et déployer des clusters EKS à partir de GitLab

Comme 85% des plateformes d'entreprise, GitLab s'appuie sur l'approche multicloud . Il est essentiel pour nos utilisateurs de déployer leurs applications sur le cloud de leur choix sans aucun problème. Nous en sommes conscients et sommes heureux de vous présenter l'opportunité de créer des clusters Kubernetes sur EKS d'Amazon en quelques clics. Ce processus est aussi simple que de créer des clusters sur GKE à partir de Google . Sélectionnez simplement EKS, configurez le cluster créé, GitLab allouera automatiquement les ressources et préparera votre cluster, et vous pourrez facilement et rapidement y placer vos applications. GitLab élimine le besoin de terminer manuellement la partie complexe de la création d'un cluster.

Cette fonctionnalité est désormais commutable et activée par défaut sur GitLab.com.

Travailler avec des services cloud gérés avec Crossplane

Nous pensons que l'efficacité opérationnelle est très importante, et nous sommes donc ravis de présenter l' intégration Crossplane en tant qu'application dans GitLab Managed Apps . Crossplane simplifie l'utilisation des dépendances de services cloud, permettant aux administrateurs de configurer de manière déclarative et d'utiliser en toute sécurité les services gérés installés dans le cloud sélectionné, y compris GCP, AWS et Azure. L'intégration avec Auto DevOps simplifie l'allocation des ressources avant de déclarer une variable CI.

Vue rapide de l'état de l'environnement

Parfois, vous rencontrez des changements fréquents dans l'application qui sont assez difficiles à suivre lorsqu'ils progressent dans vos environnements de développement, de mise en scène et de production. Un nouveau panneau d'environnements recueille en un seul endroit des informations sur l'état de tous les environnements dans tous les groupes et projets. Cela signifie que vous pouvez rapidement trouver et identifier les problèmes. Par exemple, "L'environnement ne fonctionne-t-il pas parce que le code est en cours de déploiement ou ne fonctionne-t-il vraiment pas?"

Et encore plus!

12.5 est une excellente version et de nombreuses innovations vous attendent. Séparément, nous voulons noter l' intégration avec Sourcegraph et plusieurs améliorations de sécurité. Lisez la suite pour tout savoir sur les nouvelles fonctionnalités de ce mois-ci!

Au fait, que diriez-vous d'une réunion? L'inscription est ouverte pour la prochaine conférence des utilisateurs de GitLab Commit , qui aura lieu le 14 janvier à San Francisco.

Rejoignez-nous au GitLab Commit ; remplir le questionnaire de publication (en anglais).

Badge GitLab MVP

MVP du mois - gfyoung

L'utilisateur gfyoung a effectué plus de 30 demandes de fusion (dans la localisation russe de GitLab, «demandes de fusion») pour ajouter frozen_string_literals aux tests frozen_string_literals afin d'améliorer les performances et la cohérence, sans compter les nombreuses demandes de fusion dans le code de GitLab lui-même au cours de l'année écoulée. C'est formidable de voir une approche itérative en action, et nous sommes très reconnaissants à gfyoung pour ce travail!

Principales caractéristiques de la sortie de GitLab 12.5

Créez et déployez facilement des clusters EKS à partir de GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de la boucle DevOps: "Configurer"

Kubernetes est impardonnablement complexe, donc créer un cluster à partir de zéro n'est pas une tâche facile. Même avec des services comme le service Elastic Kubernetes (EKS) d'AWS, qui masquent une partie de la complexité de l'abstraction, il faut encore beaucoup plus d'étapes pour commencer. La configuration manuelle, telle que la création d'un plan de contrôle Kubernetes spécial et de nœuds individuels dans EC2, vous distrait de l'objectif principal - lancer vos applications. Chez GitLab, nous nous efforçons d'automatiser toutes les tâches répétitives et souhaitons simplifier la création d'un nouveau cluster. C'est pourquoi nous ajoutons l'intégration avec EKS dans la version 12.5.

Maintenant, sur la page des clusters, vous pouvez sélectionner l'option EKS (cela nécessite une connexion à votre compte AWS). Après vous être connecté, sélectionnez simplement les paramètres nécessaires pour votre cluster et GitLab se chargera du reste.

L'intégration EKS est importante non seulement pour la commodité de travailler avec Kubernetes sur AWS, mais elle fait également partie de notre stratégie multicloud. Avec l' intégration de GKE, nous espérons faciliter non seulement la configuration de Kubernetes, mais aussi le passage au multicloud. Et ce n'est qu'un début, nous voulons que nos utilisateurs disposent d'une large sélection de fournisseurs de cloud pour les déploiements. Vous pouvez utiliser n'importe quel fournisseur avec ses points forts et pouvoir déplacer vos applications vers le cloud sélectionné sans modifier votre flux de travail habituel dans GitLab.

Cette fonctionnalité est désormais commutable et activée par défaut sur GitLab.com. Pour l'activer dans les instances utilisateur, démarrez la console Rails: console gitlab-rails console et exécutez Feature.enable(:create_eks_clusters) .

Documentation sur la création de clusters EKS et le ticket d'origine .

Crossplane dans les applications gérées GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de la boucle DevOps: "Configurer"

Auparavant, les applications Kubernetes pouvaient être lancées à l'aide de GitLab, mais les dépendances de service devaient être configurées, connectées et sécurisées séparément. À partir de la version 12.5, les services cloud peuvent désormais être configurés de façon déclarative avec le projet open source Crossplane, qui hérite de l'API Kubernetes pour la gestion de services tels que PostgreSQL, MySQL, Redis et Storage Buckets.

Crossplane est maintenant disponible en tant qu'application gérée GitLab. Vous pouvez l'installer dans n'importe quel cluster Kubernetes exécutant GitLab. Les services gérés de GCP, AWS et Azure peuvent être configurés et consommés en toute sécurité à l'aide de kubectl dans des pipelines standard (dans la localisation russe des «chaînes de montage» GitLab) GitLab ou à l'aide d'Auto DevOps.

L'utilisation de Crossplane avec Auto DevOps donnera aux utilisateurs la possibilité de gérer des bases de données de cluster, fournissant une solution prête à être publiée. Un grand merci à l'équipe Upbound pour ce beau travail!

Prix en charge de Crossplane dans les applications gérées GitLab

Documentation sur le Crossplane et le ticket d'origine .

Intelligence de code avec Sourcegraph

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Créer"

Les développeurs utilisent souvent des transitions vers les définitions des variables et des fonctions et recherchent des relations lors de l'écriture de logiciels, mais lors de la révision du code, cela n'est généralement pas disponible. Maintenant, lors de l'affichage d'un code ou d'une révision de demande de fusion, une puissante navigation de code de Sourcegraph est devenue disponible.

Dans la version GitLab 12.5, une fois que l'administrateur d'instance a configuré l'intégration de Sourcegraph, vous pouvez accepter de l'utiliser dans vos paramètres. Chez GitLab.com, nous ajoutons progressivement Sourcegraph pour les projets publics. Vous pouvez l'essayer dès maintenant dans ce projet GitLab en incluant Sourcegraph dans vos paramètres utilisateur .

Merci à Sourcegraph d' avoir réalisé cette intégration ! Apprenez-en plus sur elle .

Documentation sourcegraph et ticket original .

Panneau Environnement

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Release"

Les environnements GitLab sont une structure logique qui vous permet de contrôler l'état des environnements physiques dans lesquels votre code est déployé. C'est l'une de ces fonctionnalités qui font de GitLab une véritable solution CD, et pas seulement un outil CI pratique pour gérer le déploiement. Cependant, lorsqu'il existe de nombreux environnements, il devient difficile de les gérer. Auparavant, le suivi de l'état de plusieurs environnements de projets différents était difficile, car vous deviez passer à chaque projet pour afficher ses environnements intégrés.

Le nouveau panneau d'environnements fournit des données sur tous les environnements de vos projets, vous permettant de voir l'intégralité de ce qui se passe dans chaque environnement. Vous pouvez maintenant suivre la façon dont les changements passent du développement au transfert, puis à la production, ou à travers n'importe lequel de vos autres environnements, à partir d'un seul endroit. Avec une nouvelle vue pratique de l'environnement de tous les projets, vous pouvez immédiatement voir quels pipelines se sont terminés avec succès et lesquels ne le sont pas, comprendre où le bloc est apparu et s'il y a plus de problèmes systémiques qui nécessitent une enquête. Le panneau d'environnement vous aidera à résoudre plus efficacement ces problèmes.

Tableau de bord des environnements

Documentation sur le panel d'environnements et le ticket d'origine .

Association de jalons avec libération

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Release"

De nombreuses équipes, dont la nôtre, créent un jalon pour chaque version (dans la localisation russe de GitLab, une «étape»), à laquelle tout est attaché, et pour certaines équipes, la version peut inclure plus d'un sprint. Vous pouvez désormais associer un ou plusieurs jalons à la version, et la page de la version sera remplie de tous les tickets et demandes de fusion inclus dans la version.

Associer des jalons à une version

Documentation sur les versions et les jalons et le ticket d'origine .

Autres améliorations dans GitLab 12.5

API d'audit d'événements pour les groupes

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Gérer"

L'API d'audit d'événements fournit un aperçu de l'état de votre environnement GitLab. Auparavant, seuls les administrateurs pouvaient utiliser cette API pour afficher les événements d'instance . Les utilisateurs de GitLab.com n'ayant pas cet accès, il était nécessaire d'étendre cette fonctionnalité aux propriétaires de groupe.

Nous avons donc rendu possible l'accès aux données d' événements de groupe via l'API GitLab pour vous aider à communiquer vos décisions et à gérer la conformité dans vos groupes. Nous prévoyons de rendre l'audit des événements plus détaillé , et l'API fournira également des informations plus utiles.

Documentation de l'API d'audit des événements pour les groupes et un ticket d'origine .

Les épopées peuvent désormais hériter des dates de début et de fin de leurs épopées imbriquées

(ULTIMATE, GOLD) Étape du cycle DevOps: "Plan"

Dans cette version, nous avons facilité l'utilisation des informations sur le timing de vos épopées (dans la localisation russe des «objectifs» de GitLab). Désormais, les épopées peuvent hériter des dates de début et de fin des jalons non seulement des tâches attachées, mais aussi des épopées imbriquées attachées. Plus besoin de deviner à quel moment les épopées et les tâches ci-jointes doivent être terminées.

Documentation des dates de début et de fin en épopées et ticket original .

Amélioration de la navigation sur les pages du groupe, sous-groupe et projet

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Plan"

Si vous avez une structure complexe de groupes, sous-groupes et projets, il peut être difficile de comprendre exactement où vous en êtes dans la hiérarchie. Maintenant, grâce à l'apparence mise à jour de la barre de navigation de gauche, vous pouvez rapidement comprendre dans quel contexte vous travaillez.

Documentation sur la création de projets et le ticket d'origine .

Les annotations de conception sont affichées dans l'activité du ticket

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Créer"

Auparavant, lors de l'ajout d'une nouvelle annotation ou d'un commentaire à un dessin, celui-ci n'était affiché que dans le dessin lui-même. Désormais, lors de l'ajout de nouvelles annotations, GitLab en ajoutera également une mention dans l'onglet Discussion afin que toutes les personnes impliquées dans la tâche en soient informées. Ainsi, il sera plus facile de travailler ensemble sur des designs et chacun pourra y contribuer.

Conception de la documentation d'annotation et du ticket d'origine .

Git info / refs cache (beta)

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Créer"

Lors de la réception des modifications apportées au référentiel git, le serveur Git annonce une liste de toutes les branches et balises du référentiel. Dans certains cas, 75% de toutes les demandes adressées au serveur Web étaient des demandes de liens (références). Dans le meilleur des cas, lorsque tous les liens sont compressés, c'est une opération relativement peu coûteuse, mais s'il y a des liens décompressés, Git devra les contourner. Et cela peut déjà entraîner des dépenses en raison d'opérations supplémentaires sur le disque, en particulier lors de l'utilisation de stockage avec des latences élevées, par exemple, NFS.

Depuis la version 12.5, les administrateurs d'instance peuvent activer le cache bêta info/refs pour augmenter les performances des déclarations de liens et réduire la charge sur Gitaly avec les demandes d'annonces fréquentes.

En testant cette fonctionnalité sur GitLab.com, nous avons déjà constaté que les opérations de lecture étaient 10 fois plus nombreuses que les opérations d'écriture et que le délai moyen apparent avait diminué de 70%. Nous attendons des résultats encore meilleurs pour les instances de GitLab avec NFS comme référentiel pour Git.

Par défaut, le cache n'est pas encore activé, car nous étudions une demande d'écriture dans le cache plus élevée que prévu, probablement causée par des échecs simultanés. Restez à l'écoute pour gitaly # 2124 .

Mise en cache des informations / références Git (Beta)

Documentation du cache et ticket d'origine .

État fusionnable ajouté à l'API de demande de fusion

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Créer"

L'API de demande de fusion inclut désormais plus de détails sur les raisons pour lesquelles la demande de fusion ne peut pas être acceptée. L'attribut has_conflicts indique s'il y a eu des conflits de fusion et l'attribut blocking_discussions_resolved indique s'il y a eu des discussions non résolues. Ces nouveaux attributs sont particulièrement utiles pour l'automatisation, car ils indiquent les actions nécessaires pour résoudre les conflits.

Merci à Brian Kabiro pour cette fonctionnalité !

Documentation sur l'obtention d'informations sur la demande de fusion et le ticket d'origine .

Passage de valeurs aux `pipelines/new` page via une chaîne de requête

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Vérifier"

Pour créer un nouveau pipeline via le site Web de GitLab, accédez à la page /pipelines/new et remplissez les valeurs requises pour démarrer le pipeline. Auparavant, il était déjà possible d'ajouter le paramètre ref pour sélectionner une branche ou une balise (par exemple, /pipelines/new?ref=master ). Nous avons maintenant ajouté la possibilité de définir de manière similaire d'autres valeurs via la chaîne de requête.

Documentation sur l'utilisation de la chaîne de requête et du ticket d'origine .

Alias de script personnalisés dans gitlab-ci.yml

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Vérifier"

La création de petits «blocs de construction» qui peuvent être utilisés à plusieurs reprises est un outil puissant dans la conception des convoyeurs. Cela vous permettra d'éviter la répétition, de séparer les fonctions en blocs compréhensibles distincts et de créer des chaînes de dépendances dans lesquelles le bloc de code est mis à jour simultanément pour tous les blocs dépendants.

GitLab dispose de plusieurs mécanismes pour appliquer ce modèle dans la conception, y compris des éléments de syntaxe YAML par défaut tels que des ancres et des alias. Toutefois, lorsque vous essayez d'utiliser un tableau d'alias avec le script mots clés, before_script ou after_script , un tableau imbriqué est créé pendant la fusion, ce qui ne fonctionnera pas.

Dans GitLab 12.5, les tableaux de scripts fonctionnent correctement lorsqu'ils sont accessibles via des ancres. Leur utilisation avec include et extends échoue toujours, mais vous pouvez utiliser des ancres dans un fichier séparé pour accéder à un tableau de nouveaux modèles de conception.

Documentation pour les ancres pour les scripts et le ticket d'origine .

Afficher les détails des erreurs JUnit dans la demande de fusion

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Vérifier"

Avant cette version, l'utilisateur recevait des informations sur l'échec des tests, mais sans les données nécessaires pour résoudre le problème et créer rapidement un assemblage réussi. À partir de cette version, GitLab affichera sur le pipeline des données sur les résultats de la réussite du test JUnit.

Cela inclut les résultats des tests réussis, manqués et échoués, ainsi que le calendrier et un aperçu détaillé des tests individuels, y compris une liste de ceux qui ont échoué, pour une identification et une résolution plus rapides des problèmes.

Afficher les détails de l'erreur junit dans la demande de fusion

Documentation sur les résultats des tests Junit et le ticket d'origine .

Documentation contextuelle pour aider les utilisateurs à télécharger des packages NPM

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Package"

Lors d'une récente enquête auprès des utilisateurs, nous avons appris que la principale raison pour laquelle les utilisateurs passent à l'interface utilisateur du registre de packages est qu'ils doivent s'assurer qu'ils utilisent la bonne version du package . L'une des façons dont nous pouvons vous aider est de fournir des extraits de code faciles à copier pour télécharger et installer des packages individuels.

Dans GitLab 12.5, nous sommes heureux d'introduire la première itération pour améliorer la navigation et les flux de travail dans le registre des packages GitLab. Désormais, les utilisateurs peuvent facilement copier le code pour exécuter l' npm install npm setup et la npm setup pour installer plus rapidement les packages dont ils ont besoin.

Documentation contextuelle pour aider les utilisateurs à télécharger des packages NPM

Documentation du registre NPM et ticket d'origine .

API publique pour les fonctionnalités commutables

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Release"

Nous avons ajouté une fonctionnalité API qui vous permettra de configurer et de gérer des fonctionnalités commutables. Auparavant, cela ne pouvait se faire que via l'interface utilisateur.

Documentation API pour les fonctionnalités et le ticket d'origine .

Gestion de cluster basée sur CI

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de la boucle DevOps: "Configurer"

La possibilité d'installer des applications Kubernetes en un seul clic est utile pour démarrer et démarrer rapidement. Cependant, il est parfois nécessaire de configurer le graphique Helm avant l'installation. Une nouvelle approche de la gestion de cluster basée sur CI permettra aux utilisateurs de créer des «projets de gestion de cluster» qui reçoivent cluster-admin privilèges d' cluster-admin cluster sur le cluster et peuvent interagir avec le cluster via CI. Cela vous permettra non seulement d'installer des applications de modèle , mais donnera également aux utilisateurs la possibilité de personnaliser les graphiques avant l'installation. De plus, les utilisateurs pourront utiliser toutes les fonctionnalités GitLab existantes liées à la sécurité, l'authentification, le contrôle de version et l'IC lors de la gestion des applications Kubernetes. À l'avenir, nous allons combiner des installations en un clic avec des installations d'applications basées sur CI.

Gestion des applications de cluster basé sur CI

Documentation de gestion du cluster et ticket d'origine .

Prise en charge de l'exécution d'OpenFaas dans GitLab Serverless

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de la boucle DevOps: "Configurer"

GitLab Serverless prend désormais en charge les runtimes OpenFaaS classiques . Avec leur aide, les développeurs peuvent écrire des fonctions sans serveur pour Knative dans l'une des six langues prises en charge .

Documentation d'exécution prise en charge et ticket d'origine .

Fermez automatiquement les tickets GitLab lorsque vous recevez des signaux de récupération de Prometheus

(ULTIMATE, GOLD) Étape du cycle DevOps: "Monitor"

Les incidents GitLab sont résolus de deux manières:

Quelqu'un résout un problème.
Le système lui-même résout les problèmes.

Après le dépannage, le ticket d'incident doit être fermé afin qu'il n'y ait pas de confusion sur les incidents actifs et ceux qui nécessitent l'élimination des conséquences. Lorsqu'un incident est résolu suite à la résolution d'un problème, Prometheus génère un signal de récupération du système, donnant à GitLab la possibilité de fermer automatiquement le ticket associé à l'incident.

Cela permettra aux spécialistes de la résolution des incidents de ne pas effectuer de travaux manuels inutiles et garantira également que chaque ticket ouvert est un problème urgent qui doit être résolu.

Documentation sur la réponse à l'incident et le ticket d'origine .

Filtrage d'une liste d'erreurs Sentry par en-tête dans GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de boucle DevOps: "Monitor"

Le tri des erreurs nécessite la possibilité de filtrer et de trier la liste d'erreurs en fonction de critères utilisateur adaptés à un cas donné. Vous pouvez désormais rechercher la liste des erreurs Sentry dans le projet GitLab via l'intégration à Sentry. Accédez simplement à Opérations> Suivi des erreurs dans le volet gauche pour rechercher et afficher les erreurs Sentry.

Documentation sur la liste d'erreurs et le ticket d'origine .

Commandes Slack pour ajouter des commentaires de ticket

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de boucle DevOps: "Monitor"

ChatOps vous permet de démarrer des opérations via des commandes et des actions intuitives que vous pouvez saisir directement dans le chat. Nous avons élargi l'ensemble de commandes Slack existant en ajoutant une commande qui vous permet d'ajouter un commentaire à un ticket GitLab sans quitter Slack. Cela vous permettra de ne pas être distrait du travail et de ne pas basculer entre plusieurs interfaces simplement pour transmettre un ticket à un membre de l'équipe ou à un client.

Documentation des équipes et du ticket d'origine .

Modification du panneau des mesures

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de boucle DevOps: "Monitor"

Auparavant, pour créer leur propre version du panneau de configuration, les utilisateurs devaient créer un fichier YAML dans le répertoire racine du référentiel et le remplir complètement. C'était assez compliqué et nécessitait beaucoup d'actions manuelles.

Maintenant, dans GitLab 12.5, cela est devenu beaucoup plus facile. En cliquant sur le bouton «Modifier le tableau de bord», vous serez redirigé vers la page IDE où vous pourrez mettre à jour le fichier YAML déjà créé.

Modifier le tableau de bord des mesures