GitLab 11.3 publié avec le référentiel Maven et des environnements sécurisés

Une image pour attirer l'attention


Avec la nouvelle version de GitLab 11.3, nous sommes heureux de vous présenter la prise en charge des référentiels Maven, des propriétaires de code, des environnements sécurisés et des prévisions pour les épopées. Tout cela contribuera à automatiser la gestion des environnements et du code, ce qui permettra aux développeurs Java d'être encore plus efficaces.


Dépôt Maven


Nous avons étendu notre prise en charge des projets Java en intégrant les référentiels Maven directement dans GitLab. Les développeurs Java apprécieront un moyen sûr et standardisé de lier les bibliothèques Maven à un système de contrôle de version et de gagner du temps en réutilisant ces bibliothèques dans d'autres projets. Cette fonctionnalité est disponible avec GitLab Premium.


Propriétaires de code et environnements protégés


Les plans payants commençant par GitLab Starter ont la possibilité d'affecter des propriétaires de code au fichier, en indiquant les membres de l'équipe responsables de cette partie du code. Ceci est une préparation pour les futures versions, où le contrôle interne sur le niveau de code sera renforcé.


À partir de GitLab Premium, les opérateurs (responsables du déploiement) peuvent également utiliser des environnements sécurisés pour configurer les autorisations qui déterminent qui peut déployer le code en production. Cela réduira considérablement le risque que quelqu'un envoie du code qui ne devrait pas être ajouté. Et en principe, cela augmentera la sécurité de l'environnement.


Prévisions pour Epics


La gestion de portefeuille est apparue dans GitLab Ultimate, qui prédira automatiquement les dates de début et de fin de l'épopée , en fonction du calendrier des tâches dans les jalons. Grâce à cette innovation, les gestionnaires de portefeuille pourront comparer les dates de début et de fin prévues avec le travail prévu pour les jalons, se faire une idée des arriérés potentiels au sein de l'épopée. Cela vous permettra de prendre des décisions plus rapidement sur ce que vous finirez et sur le moment où ajuster les plans.


Tout le monde peut contribuer.


Beaucoup de ces changements ont été apportés par l'énorme communauté GitLab. Nous attendons avec impatience de recevoir vos commentaires et améliorations pour ces nouvelles fonctionnalités. Ensemble, nous formons une grande équipe!


Faites-nous savoir ce que vous pensez dans les commentaires sur l'article du blog - et sur Habré aussi. Qu'attendez-vous de cette version? Sur quoi devrions-nous continuer à travailler?


Nous vous invitons à nos réunions et à la version diffusée sur le Web 11.3 .


Badge GitLab MVP


MVP du mois - George Tsiolis


George a ajouté une fonctionnalité très populaire que beaucoup ont demandé d'ajouter: les utilisateurs peuvent désormais inclure leurs contributions privées au développement dans le calendrier sur la page de profil.


Merci, George, pour vos contributions continues à l'amélioration de GitLab, vous recevrez bientôt un kit de marchandises sympa!


Nouvelles fonctionnalités clés pour GitLab 11.3


Dépôt Maven


(PREMIUM, ULTIME, ARGENT, OR)


Pour les éditeurs de logiciels, il est important d'avoir un moyen simple et sécurisé de gérer les dépendances. Les outils de gestion de packages, tels que Maven pour les développeurs Java, fournissent un moyen standardisé de distribuer les bibliothèques et de gérer leurs versions sur tous les projets.


Dans la version 11.3, nous sommes heureux de fournir un support de référentiel Maven intégré directement dans GitLab. Les développeurs de services de bas niveau peuvent désormais publier leurs bibliothèques dans le référentiel Maven du projet. Ils n'ont qu'à partager un simple extrait XML avec d'autres équipes qui souhaitent utiliser cette bibliothèque, et Maven avec GitLab fera le reste.


Jetez un œil à un projet de test qui pousse l'assemblage dans le référentiel GitLab Maven et vous verrez à quel point c'est simple!


Dépôt Maven


Documentation du référentiel GitLab Maven et ticket d'origine .


Terminaux Web interactifs pour les coureurs Shell et Kubernetes


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Le travail CI / CD est effectué par Runners, tout comme les utilisateurs le configurent dans le pipeline. Mais ce processus ne peut pas être contrôlé, et si le travail échoue, les utilisateurs ne seront pas en mesure de comprendre les détails et de déterminer la source présumée du problème. Les terminaux Web interactifs vous permettent de vous connecter aux travaux en cours ou terminés et d'exécuter manuellement des commandes, ce qui permet de mieux comprendre ce qui se passe dans le système.


Terminaux Web interactifs pour Shell et Kubernetes Runners


Documentation du terminal Web interactif et ticket original .


Amélioration de la réutilisation du code dans .gitlab-ci.yml


(DEMARREUR, PREMIUM, ULTIME, BRONZE, ARGENT, OR)


La réutilisation du code de processus CI / CD est une excellente pratique qui permet de rendre la livraison des logiciels cohérente, d'écrire et de maintenir moins de code pour chaque travail individuel. Nous proposons un moyen flexible et puissant de réutiliser le code dans les modèles YAML à l'aide du extends .


Améliorez les inclus dans `.gitlab-ci.yml` pour réutiliser les scripts


Prolonge la documentation des blocs et le ticket d'origine .


Les dépôts dans les dépôts privés peuvent désormais être inclus dans le graphique de la page de l'utilisateur


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Chez GitLab, nous aimons les logiciels open source. Mais parfois, vous devez travailler sur un projet privé que vous (jusqu'à présent) n'êtes pas prêt à ouvrir au public. Ou vous pouvez être limité pour des raisons de confidentialité. Dans tous les cas, GitLab est de votre côté.


Dans cette version, nous présentons la possibilité d'inclure des contributions de développement privé dans le calendrier d'investissement sur votre page. Si vous avez activé ce paramètre pour votre profil, les contributions aux projets privés seront également affichées dans le calendrier des dépôts et dans les dépôts quotidiens. Ainsi, votre travail actif sur des projets privés dans GitLab sera présenté avec précision, sans divulguer aucun détail secret.


Merci George Tsiolis pour cette fonctionnalité!


Inclure les contributions privées dans le graphique des contributions des utilisateurs


Documentation sur les dépôts privés dans le profil et le ticket d'origine .


Refonte de la page du projet


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


GitLab se concentre constamment sur l'amélioration de l'interface de notre produit.


Avec GitLab 11.3, nous mettons à jour les pages de l'interface utilisateur du projet pour mieux présenter les informations du projet. Nous avons structuré les informations de cette page, et aligné la section supérieure à gauche et optimisé le retrait verticalement, vous pouvez donc maintenant afficher rapidement des informations sur le projet et son contenu.


Aperçu du projet repensé


Documentation du projet et ticket d'origine .


Environnements protégés


(PREMIUM, ULTIME, ARGENT, OR)


Les opérateurs sont souvent responsables de la protection de l'environnement dans lequel nous envoyons le code quotidiennement; cette tâche devient particulièrement importante lors du déploiement de code en production.


Avec les environnements protégés, l'opérateur obtient un contrôle total sur les utilisateurs, groupes ou comptes autorisés à incorporer du code dans cet environnement, ce qui garantit la sécurité des environnements.


Environnements protégés


Documentation sur les environnements protégés et le ticket d'origine .


Propriétaires de code


(DEMARREUR, PREMIUM, ULTIME, BRONZE, ARGENT, OR)


Un examen du code est la pratique fondamentale de tout projet réussi, mais il n'est pas toujours clair qui devrait examiner les modifications. Désormais, pour chaque fichier GitLab, vous pouvez affecter un ou plusieurs propriétaires de code, en indiquant les membres de l'équipe qui sont responsables du code dans votre projet.


Les propriétaires de code sont attribués à l'aide du fichier CODEOWNERS dans un format similaire à gitattributes et sont affichés sous les détails de la validation lors de l'affichage du fichier dans GitLab.


Dans les versions futures, les propriétaires de code seront également impliqués dans les processus de demande de fusion pour proposer et approuver ceux qui confirmeront la demande de fusion. Et également dans les branches protégées, seuls les propriétaires de code peuvent modifier les fichiers .


Propriétaires de code


Documentation sur les propriétaires de code et le ticket d'origine .


Prédictions pour les épopées avec des dates de jalon intégrées


(ULTIME, OR)


Avant cette version, vous pouvez définir des dates fixes de début et de fin pour l'épopée, ce qui était très utile pour la planification épique de haut niveau et le suivi du temps. Cependant, comme les tâches sont attachées à l'épopée et affectées à un jalon spécifique, il serait bien que les dates épiques reflètent ces jalons.


À partir de cette version, vous pouvez basculer entre une valeur fixe pour ces dates et une valeur dynamique pour les From milestones . Comme le début prévu, la première date de début sera sélectionnée parmi toutes les étapes liées aux tâches de cette épopée. Ce délai changera dynamiquement lors de l'ajout et de la suppression de tâches, de l'ajout et de la suppression de jalons à ces tâches ou lors du changement de dates de jalons. De même, la date de fin dynamique de l'épopée fonctionnera.


Cette fonctionnalité sera utile pour les équipes qui souhaitent une transition transparente de la planification descendante à long terme à la planification ascendante à court terme. Vous trouverez plus d'informations dans un article sur les feuilles de route épiques , que nous avons publié il y a quelques semaines.


Des prévisions épiques avec des dates d'étape intégrées


Documentation sur les épopées et ticket original .


Autres améliorations dans GitLab 11.3


La notification d'une nouvelle épopée peut être connectée manuellement


(ULTIME, OR)


Dans la dernière version, nous avons ajouté des notifications par e-mail sur les nouvelles épopées pour les utilisateurs qui configurent des notifications d'activité de groupe au niveau de la Watch . Dans cette version, nous ajoutons encore plus de fonctionnalités pour personnaliser quelque chose. Désormais, en utilisant le niveau Custom , vous pouvez activer ou désactiver les notifications sur cet événement, ainsi que sur d'autres événements.


Nouvel événement épique en tant que notification personnalisée


Documentation des notifications et du ticket d'origine .


Action rapide pour ajouter une tâche à l'épopée à partir de la page des tâches


(ULTIME, OR)


À partir de la page épique, il est assez facile d'y ajouter ou de supprimer une tâche déjà jointe, ce qui est pratique lorsque vous travaillez sur l'épopée elle-même.


Mais parfois, vous travaillez sur une tâche et souhaitez l'attacher à une épopée existante, dont vous connaissez le nom. Maintenant, il est facile de le faire avec une action rapide sur la page des tâches en insérant l'URL épique. Dans la prochaine version, une action rapide apparaîtra pour rechercher une épopée par nom, avec auto-complétion .


Une action rapide sera également ajoutée pour détacher la tâche de l'épopée jointe.


Action rapide pour ajouter un problème à l'épopée (à partir des problèmes)


Documentation d'action rapide et ticket original .


Autorisation de confirmation indépendante des demandes de fusion


(DEMARREUR, PREMIUM, ULTIME, BRONZE, ARGENT, OR)


L'utilisateur qui a créé la demande de fusion peut ne pas être l'auteur des modifications et les autres utilisateurs peuvent ajouter des modifications supplémentaires à la demande de fusion ouverte. Les responsables peuvent désormais autoriser l'auto-approbation des demandes de fusion dans les paramètres du projet.


Auparavant, il était supposé que l'utilisateur qui avait ouvert la demande de fusion l'approuvait par défaut (y compris les modifications apportées par d'autres personnes) et qu'il ne participait donc pas à l'approbation de la demande de fusion. Il existe de nombreuses situations où ce n'est pas le cas et il sera contre d'autres changements. L'ajout d'une autorisation explicite supprime cette hypothèse.


Documentation sur l'auto-confirmation des demandes de fusion et le ticket d'origine .


Afficher les langues du référentiel dans l'aperçu du projet


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Lors de la visualisation de projets dans GitLab, il est important et utile de voir immédiatement les langages de programmation utilisés dans le référentiel.


Dans cette version, nous ajoutons un panneau de langages de programmation à la vue d'ensemble du projet qui affiche l'utilisation relative des langages dans le projet.


Afficher les langues du référentiel dans l'aperçu du projet


Documentation du projet et ticket d'origine .


Modèles de fichiers personnalisés pour les instances utilisateur


(PREMIUM, ULTIME)


Les modèles pour les .gitignore LICENSE , .gitignore , Dockerfile et .gitlab-ci.yml facilitent l'ajout de ces fichiers communs aux projets. Des modèles personnalisés pour ces fichiers peuvent désormais être ajoutés aux instances utilisateur de GitLab en sélectionnant le modèle de référentiel avec eux.


Les modèles personnalisés sont utiles lorsque les modèles GitLab sont trop universels. Par exemple, si l'entreprise nécessite l'utilisation d'une licence utilisateur dans chaque projet, ou s'il existe un Dockerfile complexe qui doit être utilisé pour chaque microservice.


Merci à Daniel Barker d' avoir ajouté des modèles de licence personnalisés .


Documentation du référentiel de modèles pour l'instance et le ticket d'origine .


Modèles de fichiers Web IDE


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Les modèles de fichiers pour .gitignore , .gitignore , Dockerfile et .gitlab-ci.yml facilitent l'ajout de ces fichiers partagés aux projets et peuvent désormais être utilisés dans l'IDE Web. Les modèles de fichiers dans Web IDE facilitent le lancement d'un nouveau projet dans l'environnement Web IDE et maintiennent ces fichiers importants à jour.


Modèles de fichiers dans l'IDE Web


Documentation Web IDE et ticket d'origine .


Champ de nom de projet ajouté lors de la création d'un nouveau projet


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Pour ajouter le nom du projet à votre projet GitLab nouvellement créé, vous avez dû entrer dans les paramètres du projet et écrire la partie «lisible par l'homme» correspondante de l'adresse du projet (URL sémantique) auparavant.


Avec GitLab 11.3, nous ajoutons un champ de nom de projet au formulaire Créer un projet. De plus, l'URL sémantique est désormais générée automatiquement à partir du nom du projet, alors qu'elle peut toujours être modifiée manuellement. Cela accélère et simplifie la création d'un nouveau projet.


Définir le nom du projet lors de la création d'un nouveau projet


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


Stockage des fichiers Wiki téléchargés dans un référentiel Wiki


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Les images téléchargées sur le wiki via l'éditeur wiki sont désormais stockées dans le référentiel Git. Ces images seront affichées sur l'aperçu local à l'aide de Gollum .


Auparavant, les images étaient enregistrées dans le répertoire de téléchargement du projet, au même endroit que le reste des pièces jointes téléchargées dans les tickets et les demandes de fusion. Cela a conduit à l'impossibilité d'une visualisation locale adéquate du wiki, ainsi qu'à l'impossibilité de transférer vers un autre référentiel Git.


Documentation Wiki et ticket original .


Prise en charge SAST pour Groovy


(ULTIME, OR)


Le test de sécurité des applications statiques (SAST) est conçu pour détecter les vulnérabilités dans le code source dès que ce code entre dans le référentiel. Pour ce faire, le code recherche les modèles connus et les erreurs courantes pouvant entraîner des problèmes de sécurité dans l'application. C'est pourquoi chaque langue a besoin d'un support spécial.


Avec GitLab 11.3, nous ajoutons Groovy à la liste des langues prises en charge par GitLab SAST. Les projets qui utilisent cette langue sont désormais détectés automatiquement, vous n'avez donc pas besoin de modifier quoi que ce soit dans le code ou dans les définitions de pipeline pour activer cette fonctionnalité. Auto DevOps le prend également en charge dans le cadre de sa configuration par défaut.


Documentation SAST et ticket original .


Filtre d'événement de poussée de crochet Web de branche


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Les webhooks pour les événements push facilitent la notification automatique des services externes des nouveaux validations. Cependant, les branches ont généralement une importance différente. Les événements push peuvent désormais être filtrés par branche, de sorte que les services externes ne seront informés que des modifications importantes pour vous.


Auparavant, les hooks Web n'étaient pas filtrés par GitLab et la plupart des systèmes externes ne pouvaient pas filtrer les événements entrants. Cela signifiait que vous ne pouviez pas intégrer ces services externes directement avec GitLab si vous vouliez qu'un seul sous-ensemble d'événements push soit utilisé par un service externe.


Merci Duana Saskia pour cette fonctionnalité!


Filtrer les événements push de webhook par branche


Documentation du crochet Web et ticket original .


Alertes métriques de bibliothèque


(ULTIME, OR)


GitLab 11.2 a ajouté la possibilité de définir des alertes pour les mesures personnalisées , ce qui a permis aux développeurs de recevoir des notifications en cas de problème avec leurs applications.


Dans GitLab 11.3, nous avons étendu la prise en charge des alertes pour toutes les mesures, y compris les mesures par défaut fournies avec nos mesures de bibliothèque .


Alertes pour les statistiques de bibliothèque


Documentation d'alerte pour les métriques et un ticket d'origine .


DevOps automatiques activés par défaut


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Auto DevOps est devenu accessible au public dans GitLab version 11.0, et bien qu'il soit largement utilisé, nous voulons que tous les utilisateurs de GitLab profitent de ses vastes capacités. Les DevOps automatiques déjà prêts à l'emploi offrent des avantages significatifs, de la construction automatique (Auto Build) à la surveillance automatique (Auto Monitoring).


À partir de GitLab 11.3, Auto DevOps sera activé par défaut sur GitLab.com et les instances utilisateur afin que chaque projet puisse profiter de ces fonctionnalités.


Consultez la documentation sur l' activation / la désactivation des DevOps automatiques si vous souhaitez la désactiver pour votre projet ou pour l'instance entière.


DevOps automatiques activés par défaut


Documentation Auto DevOps et ticket d'origine .


Améliorations apportées à GitLab Geo


(PREMIUM, ULTIME)


Nous nous concentrons constamment sur l'amélioration de Geo , notre fonctionnalité pour les équipes géographiquement réparties. Certaines des améliorations importantes de GitLab 11.3:



Vous pouvez également découvrir comment nous avons créé GitLab Geo .


Documentation de configuration géographique et tableau des tâches géographiques .


Désactivation automatique des DevOps automatiques pour un projet lors de la première défaillance du pipeline


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Chez GitLab, l'une des valeurs clés du produit est "activée par défaut" . Lorsque nous introduisons une nouvelle fonctionnalité personnalisée, qui à notre avis est très importante, nous l'activons par défaut afin que tout le monde puisse en bénéficier. Bien que Auto DevOps prenne en charge les projets qui utilisent les langages de programmation les plus populaires, certains projets spécialisés peuvent nécessiter une configuration supplémentaire.


Étant donné que nous voulons être sûrs de ne pas exécuter les pipelines Auto DevOps pour les projets qui ne sont pas pris en charge, nous désactiverons Auto DevOps en cas de défaillance de l'un des pipelines. GitLab en informera le propriétaire du projet afin que s'il le souhaite, il puisse apporter les modifications de configuration nécessaires pour continuer à travailler avec Auto DevOps. Les propriétaires de projet peuvent réactiver Auto DevOps après avoir apporté les modifications nécessaires.


Désactiver automatiquement les DevOps automatiques pour le projet lors de la première défaillance du pipeline


Documentation d'activation Auto DevOps et ticket d'origine .


Gitaly v1.0


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


L'accès à Git pour une utilisation régulière de GitLab peut désormais s'effectuer entièrement via Gitaly, le service GitPC GitLab pour accéder à Git. Cela signifie que vous pouvez exécuter Gitaly sur votre serveur sans NFS, lorsque toutes les fonctionnalités supplémentaires sont activées.


Dans la prochaine version de Gitaly v1.1, toutes les fonctionnalités seront incluses par défaut. Toutes les fonctionnalités restantes utiliseront Gitaly, vous pouvez donc vous passer de NFS.


Lisez notre article de blog sur le chemin vers Gitaly v1.0 .


Documentation Gitaly et épopée originale .


GitLab Runner 11.3


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


Nous publions également GitLab Runner 11.3 dans cette version. GitLab Runner est un projet open source qui est utilisé pour exécuter votre travail CI / CD et renvoyer les résultats à GitLab.


Les changements les plus importants:


Une liste de toutes les modifications peut être trouvée dans le CHANGELOG GitLab Runner.


Documentation de GitLab Runner


La liste des composants logiciels Open Source utilisés par GitLab est désormais disponible en ligne


(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)


À partir de GitLab 11.3, nous rendons plus accessible la liste des logiciels open source utilisés par GitLab. Avant cette version, il était disponible dans chacun de nos packages Linux, ce qui nécessitait le chargement et l'extraction de contenu.


Maintenant, nous publions immédiatement ces informations en ligne afin qu'elles soient plus faciles à trouver, ainsi que leur lien. La liste est disponible pour GitLab CE et GitLab EE .




Des notes de version détaillées et des instructions de mise à jour / d'installation peuvent être trouvées dans la publication anglaise originale: GitLab 11.3 publié avec Maven Repository et Protected Environments .


Cattidourden , ainoneko , rishavant et nick_volynkin ont travaillé sur la traduction de l'anglais.

Source: https://habr.com/ru/post/fr425819/


All Articles