GitLab 13.7 – Quoi de neuf ?

Voici donc sans plus attendre, notre sélection des nouveautés les plus importantes que GitLab 13.7 nous a livré sous le sapin, à consommer sans modération pour ce début d’année.

Pour voir la liste complète de ces nouveautés, vous pouvez également consulter le blog GitLab (anglophone) à cette adresse.

Reviseurs pour les Merge Request

Demander à un collègue de réviser votre code devrait faire partie intégrante de la contribution du code, mais c’est souvent inutilement complexe. Une tâche simple comme demander un avis peut prêter à confusion. Par exemple, comment devriez-vous demander ? Un email ? Un commentaire ? Un message de chat ?

Sans un processus formel, les examens peuvent être incohérents et difficiles à suivre. Auparavant, une option consistait à affecter un réviseur à une demande de fusion, mais même avec cette formalité, l’auteur et le réviseur apparaissaient dans le même champ de destinataire, ce qui rendait difficile pour les autres membres de l’équipe de savoir qui faisait quoi.

GitLab 13.7 introduit des réviseurs pour les demandes de fusion, ce qui permet aux auteurs de demander une révision à quelqu’un. Le nouveau champ « Réviseurs » permet aux utilisateurs d’être désignés comme réviseurs de la même manière que les cessionnaires. Les réviseurs reçoivent une notification les invitant à examiner la demande de fusion. Cela fournit un processus formel pour demander une révision et clarifie les rôles de chaque utilisateur dans une demande de fusion.

Cloner une issue instantanément avec GitLab 13.7

Pour rendre la génération d’issues identiques plus efficace, celles-ci prennent désormais en charge une action rapide / clone, qui crée une nouvelle issue dans le même projet, avec un titre, une description et des métadonnées identiques. L’action rapide / clone remplace un processus plus compliqué, qui implique plusieurs étapes pour créer une issue, copier l’ID ou le chemin du problème source et utiliser l’action rapide copy_meta. Par défaut, les issues sont clonées dans le même projet et n’incluent pas les notes système et les commentaires, mais vous pouvez également modifier le comportement par défaut lors du clonage.

GitLab Runner pour OpenShift

L’image de conteneur GitLab Runner est disponible aujourd’hui pour Red Hat OpenShift Container Platform. Pour installer le runner sur OpenShift, vous pouvez utiliser le nouvel opérateur GitLab Runner disponible à partir du canal bêta de Red Hat Operator Hub – une console Web permettant aux administrateurs de cluster OpenShift de découvrir et de sélectionner les opérateurs à installer sur leur cluster. Operator Hub est déployé par défaut dans OpenShift Container Platform. La transition de GitLab Runner Operator vers le canal stable, et par extension GA, est prévue pour début 2021.

GitLab 13.7 permet une visualisation de l’état des déploiements depuis la page des environnements

Auparavant, vous n’aviez aucun moyen de savoir qu’un déploiement était en cours lors de l’affichage de la page Environnements. Avec l’état du déploiement et les alertes désormais visibles, la page Environnements vous donne une indication de l’action que vous pouvez entreprendre en fonction de l’état du déploiement (réussi, échoué ou en cours). Par exemple, vous souhaiterez peut-être arrêter un déploiement en cours ou restaurer un déploiement terminé.

Gestion du poids des déploiements via l’interface Web (premium / ultimate)

GitLab 13.7, propose désormais de modifier les poids Canary directement à partir des tableaux de déploiement dans l’interface utilisateur. Vous pouvez modifier les pondérations Canary directement à partir de gitlab-ci.yml et de l’API, mais l’intégration dans l’interface utilisateur vous permet de voir le déploiement et de mettre à l’échelle les pods vers le haut ou vers le bas directement à partir des tableaux de déploiement. Cela vous donne un meilleur contrôle sur les déploiements incrémentiels manuels ou chronométrés et vous permet de mieux atténuer les risques.

Support de plusieurs manifest K8S au sein d’un projet (Premium / Ultimate)

Dans les versions précédentes de GitLab, l’agent GitLab Kubernetes exigeait que les utilisateurs collectent toutes les ressources Kubernetes dans un fichier « manifest » unique. Dans cette version de GitLab, l’agent GitLab Kubernetes peut désormais récupérer les manifestes Kubernetes de manière récursive à partir de répertoires spécifiés dans votre projet. Les ingénieurs de votre plateforme peuvent utiliser un référentiel unique pour gérer différents clusters à partir d’un seul endroit et peuvent décrire des déploiements de grande envergure avec un seul agent.

Integration des outils d’alerting avec plusieurs endpoints (Premium / Ultimate)

Les intégrations d’alertes sont une partie essentielle de vos flux de travail de gestion des incidents, c’est pourquoi il est important pour vous et votre équipe d’avoir un contrôle granulaire sur les points de terminaison et les jetons d’authentification. La dernière chose que vous voulez est de supprimer toutes vos alertes en réinitialisant un seul jeton d’authentification! La configuration d’un point de terminaison HTTP pour chacun de vos outils de surveillance permet à votre équipe de gérer séparément chaque outil sans affecter les alertes des autres outils.

Auto rollback en cas d’échec de déploiement (Ultimate)

Si vous rencontrez un problème critique avec un déploiement, les actions manuelles pour le résoudre prennent souvent trop de temps et conduisent à une dégradation de la production qui affecte vos utilisateurs. Vous pouvez désormais tirer parti d’un mécanisme de restauration automatique qui ramène votre déploiement au dernier déploiement réussi. De plus, lorsque GitLab détecte des problèmes en production, il vous en informe automatiquement par une alerte. Cela vous donne la tranquillité d’esprit et un temps de développement précieux pour déboguer, étudier et résoudre les problèmes sans provoquer de temps d’arrêt.

Jettez un oeil à l’explication vidéo ci-dessous :

GitLab 13.7 permet de gérer la fréquence de déploiements par API (Ultimate)

Dans le cadre de la première itération vers la prise en charge native des métriques DORA4 dans GitLab, cette version ajoute la prise en charge de l’API pour la fréquence de déploiement au niveau du projet. Cela vous permet de surveiller l’efficacité de vos déploiements au fil du temps, de trouver facilement les goulots d’étranglement et de prendre rapidement des mesures correctives si nécessaire.

Import des requirements par des outils externes (Ultimate)

Il est essentiel de disposer de tous vos requirements en un seul endroit pour une collaboration efficace. C’est désormais chose possible grâce à la nouvelle fonctionnalité d’import des requirements à partir d’un fichier CSV. Cette fonctionnalité permettra à toute votre équipe de collaborer sur les requirements de GitLab, tout en vous permettant d’interagir facilement avec les clients, les fournisseurs et les organisations externes.