Cette version majeure est également l’occasion pour GitLab de rompre avec certaines fonctionnalités passées. La liste des breaking changes est disponible ici : https://about.gitlab.com/blog/2021/06/04/gitlab-moving-to-14-breaking-changes/
Comme d’habitude, nous vous avons résumé cette actualité afin que vous puissiez apercevoir les nouveautés les plus importantes le temps d’un café (ou deux) !
GitLab 14.0 amène les Epic Boards pour une visualisation continue
Les Epic Boards permettent désormais de visualiser en continu l’état des epics. Les versions précédentes de GitLab vous obligeaient à afficher et à trier les epics dans une liste pour afficher l’état général. Garder les epics à jour signifiait apporter la plupart des modifications via la page de détail de celle-ci. Les tableaux d’epics vous permettent de visualiser et d’affiner toutes vos epics en un seul endroit, à l’aide d’une interface personnalisable par glisser-déposer simple à prendre en main.
L’Epic Boards change également la donne pour gérer et visualiser les workflows, tels que les états de workflow de création (Brouillon, Rédaction, Terminé), les états de workflow DevOps (comme Planifié, En développement et En production) ou tout autre états personnalisé que vous pouvez modéliser avec des labels étendus.
Registry de modules Terraform module intégrée à GitLab 14.0
Les modules Terraform jouent un rôle central dans la création de composants d’infrastructure standard dans l’ensemble d’une organisation. Jusqu’à GitLab 13.12, les utilisateurs de GitLab devaient utiliser une registry de modules Terraform externe, des modules locaux ou des modules basés sur Git. Bien que ces options fonctionnent bien, elles n’aident pas à la distribution des modules et elles ne prennent pas en charge correctement la gestion des versions, ce qui présente des risques pour les utilisateurs de modules.
GitLab 14.0 étend nos possibilités d’Infrastructure-as-Code avec une registry de modules Terraform. Désormais, vous pouvez utiliser la registry de modules Terraform intégré à GitLab pour découvrir les modules Terraform avec prise en charge du semantic versionning pour les mises à niveau et la maintenance. De plus, vous pouvez facilement publier des modules à l’aide de GitLab CI/CD.
Tout en suivant les best-practices de Terraform, nous vous recommandons de développer chaque module Terraform dans un projet GitLab dédié. Pour simplifier la transition vers cette registry, les utilisateurs peuvent héberger et publier plusieurs modules à partir d’un seul référentiel GitLab.
Un menu de navigation supérieur simplifié
GitLab 14.0 introduit un tout nouveau menu de navigation simplifié pour vous aider à vous rendre où vous allez plus rapidement et avec moins de clics. Ce nouveau menu consolidé offre les fonctionnalités combinées des menus précédents Projets, Groupes et Plus. Il vous donne accès à vos projets, groupes et fonctionnalités au niveau de l’instance en un seul clic.
Merge request reviews intégrées à VSCode
En tant que développeur, vous passez souvent la majorité de votre temps à travailler dans votre environnement de développement local. Lorsque vous recevez une merge request, cela vous oblige à quitter votre éditeur et à effectuer cette révision dans GitLab. Lors de votre review dans GitLab, vous devrez peut-être également utiliser votre éditeur local pour obtenir plus de contexte sur les modifications proposées.
GitLab Workflow version 3.21.0 pour Visual Studio Code (VS Code) prend désormais en charge le processus complet de révision des demandes de fusion, y compris les threads. Sélectionnez l’icône GitLab dans VS Code pour ouvrir la barre latérale et afficher les demandes de fusion que j’examine. Sélectionnez un aperçu de la demande de fusion pour afficher les détails complets et les discussions de la demande de fusion.
La barre latérale contient également une liste de tous les fichiers modifiés dans la demande de fusion. La sélection de fichiers ouvre le diff pour vous permettre de revoir les modifications dans VS Code. Lors de l’affichage du diff, vous pouvez lire les commentaires laissés sur les fichiers et créer de nouveaux commentaires en sélectionnant un numéro de ligne et en créant votre commentaire. Tous les commentaires que vous fournissez dans VS Code sont disponibles dans l’interface Web de GitLab, ce qui vous permet d’effectuer facilement vos révisions dans VS Code et aux autres utilisateurs de participer à GitLab.
Nous vous conseillons cette vidéo pour en savoir plus : https://youtu.be/F5ypjlOZ4-0
Refonte de la navigation de la barre latérale dans GitLab version 14.0
GitLab est de plus en plus grand. Au fur et à mesure que de nouvelles fonctionnalités et catégories sont introduites, la navigation dans la barre latérale est devenue moins intuitive.
Avec GitLab 14.0, la barre latérale gauche a été repensée et restructurée pour une utilisation, une cohérence et une expérience améliorées. Ces changements sont destinés à mieux correspondre au modèle du cycle de vie DevOps et à offrir une expérience plus prévisible et cohérente lors de la navigation au sein des projets et groupes.
Edition de la page wiki avec un éditeur WYSIWYG
Éditer le contenu du wiki pourrait être tellement plus facile ! De nombreux wikis GitLab utilisent le formatage Markdown, et pour certains utilisateurs, Markdown est un obstacle à une collaboration efficace. Dans cette version, vous avez désormais accès à une expérience d’édition Markdown riche et moderne dans votre wiki, afin que vous puissiez éditer en toute confiance.
La rétroaction instantanée et les outils d’édition visuelle rendent l’édition de wiki plus intuitive et suppriment les obstacles à la collaboration. GitLab enregistre les modifications en tant que Markdown lorsque vous avez terminé, afin que les utilisateurs qui souhaitent modifier directement le Markdown puissent le faire. Vous pouvez même taper Markdown dans le nouvel éditeur et il formatera automatiquement le texte au fur et à mesure que vous tapez.
GitLab 14.0 introduit l’éditeur de contenu dans le Wiki avec la prise en charge de la plupart des types de contenu de base de Markdown comme les en-têtes, le texte en gras et en italique, les listes, les blocs de code et les liens.
Regroupement des vulnérabilités DAST identiques en une seule vulnérabilité
Dans GitLab 13.12 et versions antérieures, toutes les vulnérabilités DAST trouvées dans une analyse étaient répertoriées individuellement pour chaque URL sur laquelle la vulnérabilité a été trouvée. En conséquence, de nombreuses vulnérabilités étaient en doublon lorsque le correctif était un seul fichier ou un changement de configuration. Par exemple : un problème avec un en-tête de serveur envoyé avec chaque réponse HTTP était signalé sur chaque page du site, plutôt que signalé comme un problème unique avec plusieurs occurrences.
Pour réduire la surcharge de gestion des vulnérabilités, GitLab combine des vulnérabilités identiques trouvées sur plusieurs pages en une seule vulnérabilité signalée dans le rapport DAST. Les détails de la vulnérabilité incluent une liste de toutes les URL où la vulnérabilité a été trouvée, plutôt que des vulnérabilités individuelles créées dans la liste des vulnérabilités et le tableau de bord pour chaque page.
GitLab 14.0 propose un Cluster Management Template
GitLab 14.0 s’éloigne de l’approche basée sur des modèles CI/CD pour la gestion des clusters. L’ancienne méthode cache trop de logique, restreint les personnalisations et les extensions de vos applications.
Avec la nouvelle approche, vous pouvez facilement créer un projet de gestion de cluster à partir d’un modèle de projet et contrôler entièrement vos applications. Un projet créé à l’aide du nouveau modèle contient le code nécessaire pour les tâches de gestion de cluster, y compris la prise en charge intégrée de plusieurs applications. Vous pouvez facilement étendre le projet à d’autres applications et les posséder complètement.
De plus, de nouvelles applications seront installées à l’aide de Helm v3. Si vous avez d’anciennes applications installées à l’aide de Helm v2, vous pouvez consulter le guide de migration Helm et le guide de migration GitLab Managed Apps.
Pré-complétion de l’éditeur de pipeline CI/CD avec un modèle initial
L’éditeur de pipeline dans GitLab est votre zone centrale d’interaction avec les pipelines CI/CD.
Auparavant, lors de l’écriture de votre première pipeline avec l’éditeur, une configuration vierge vous était présentée. Bien que parfaitement utile pour les auteurs de pipelines expérimentés, c’était un peu un saut pour ceux qui débutaient.
Dans cette version, si un projet n’a pas de pipeline configuré, l’éditeur précharge un modèle montrant un exemple de pipeline en 3 étapes. Vous pouvez enregistrer et exécuter cette pipeline immédiatement pour le voir en action dans votre projet. En plus de cela, il contient également des commentaires qui vous aident à comprendre la syntaxe, ainsi que des conseils et astuces pour vous aider à commencer à personnaliser le modèle en fonction de vos besoins. Il est maintenant beaucoup plus facile d’obtenir votre premier pipeline vert !
Intégration du scan de conteneurs avec Trivy
L’analyse des conteneurs dans GitLab utilise désormais le moteur Trivy par défaut.
Ce changement offre aux clients des mises à jour plus rapides des renseignements sur les vulnérabilités, des résultats plus précis et une prise en charge d’un plus grand nombre de systèmes d’exploitation. Les utilisateurs qui exécutent l’analyse des conteneurs avec les paramètres par défaut sont basculés de manière transparente et automatique vers le nouveau moteur de GitLab 14.0..
Délai pour les merge request au niveau du groupe
Dans le cadre des efforts de prise en charge des métriques DORA4 dans GitLab, le graphique des délais de merge request est désormais disponible au niveau du groupe.
Vous pouvez désormais utiliser un graphique qui montre combien de temps il faut aux demandes de fusion pour être déployées dans un environnement de production (pas seulement dans des projets individuels, mais agrégés à travers un groupe
Identifiez quel job a déclenché les pipelines avec GitLab 14.0
Auparavant, il était difficile de déterminer quel job déclenchait une pipeline en aval. À partir de la version 14.0, chaque pipeline en aval affiche le nom de la tâche qui l’a déclenché. Cela facilite le suivi du flux d’exécution dans des pipelines complexes qui déclenchent des pipelines en aval.
Installez les packages PyPI de votre groupe ou sous-groupe
Vous pouvez utiliser la packages registry de votre projet pour publier et installer des packages PyPI.
Lorsque vous installez un package PyPI, vous devez spécifier dans quel projet réside le package. Cela fonctionne bien si vous avez un petit nombre de projets. Si vous avez plusieurs projets imbriqués dans un groupe, vous pourriez rapidement vous retrouver à ajouter des dizaines, voire des centaines de sources différentes.
Pour les grandes organisations avec de nombreuses équipes, il est courant qu’une équipe publie des packages dans la packages registry de leur projet avec le code source et les pipelines. Cependant, ils doivent également pouvoir installer facilement des dépendances d’autres projets au sein de leur organisation.
Vous pouvez maintenant installer des packages de votre groupe. Vous n’avez donc pas à vous rappeler quel package réside dans quel projet. Pour ce faire, utilisez l’API simple pour spécifier un package : GET groups/:id/packages/pypi/files/:sha256/:file_identifier.
Master devient MAIN pour les branches par défaut
Chaque projet Git possède une branche initiale, nommée master par défaut. C’est la première branche à être créée automatiquement lorsque vous créez un nouveau projet.
Les futures versions de Git changeront le nom de branche par défaut dans Git de master à main. En coordination avec le projet Git et la communauté au sens large, GitLab a modifié le nom de branche par défaut pour les nouveaux projets à partir de GitLab 14.0. Cela n’affectera pas les projets existants.
