Nous sommes heureux de présenter la version de GitLab 11.6, dans laquelle nous avons étendu les capacités de l'architecture sans serveur sur GitLab et ajouté des clusters de groupes Kubernetes pour simplifier le travail avec l'infrastructure cloud native.
Déployez des développements sans serveur sur n'importe quel cloud via GitLab
L'informatique sans serveur est traitée dynamiquement et lorsque le code est exécuté, le système accède aux ressources cloud, optimisant ainsi l'allocation et la distribution des ressources nécessaires à son exécution. La popularité de cette approche auprès des développeurs augmente, car elle leur permet de se concentrer sur ce qui est vraiment important - par exemple, sur l'écriture de code - et ne nécessite pas de comprendre l'infrastructure sous-jacente sur laquelle votre logiciel fonctionnera.
L'informatique sans serveur sur GitLab utilise Knative, une plateforme Kubernetes conçue pour créer, déployer et gérer des projets sans serveur. Cette fonctionnalité offre aux développeurs un moyen facile de créer leurs développements sans serveur et de les gérer avec d'autres codes dans une interface déjà familière. Pour les entreprises, l'architecture sans serveur vous permet d'utiliser une stratégie multicloud et d'éviter d'être lié à un fournisseur de cloud spécifique.
GitLab continue de simplifier le développement d'applications cloud natives
Avec son registre de conteneurs intégré et l' intégration de Kubernetes, GitLab vous permet de démarrer avec les conteneurs et le développement cloud plus facilement que jamais. Depuis la version 11.6, les utilisateurs peuvent créer des clusters de groupes Kubernetes qui peuvent être utilisés dans tous les projets d'un groupe ou de ses sous-groupes. Cela simplifie encore la configuration des projets cloud natifs et permet aux développeurs de se concentrer sur le développement d'applications de qualité.
Pour les vacances, nous avons publié de nombreuses fonctionnalités intéressantes.
Nos coups de coeur: modifications proposées , terminal Web dans l'IDE Web et graphique de vulnérabilité dans le panneau de sécurité du groupe . Les contributions d'équipe sont désormais plus faciles à accepter, car les modifications proposées dans le commentaire de la différence de demande de fusion (dans la localisation russe de GitLab «demande de fusion») peuvent être acceptées en un seul clic. Toujours dans cette version, la première fonctionnalité de l'IDE Web qui s'exécute sur le serveur, le terminal Web, est devenue disponible. Un nouveau tableau de vulnérabilités est apparu sur le panneau de sécurité du groupe ajouté dans la dernière version, qui montre l'évolution du nombre de vulnérabilités chaque jour, vous permettant de suivre les mesures des modifications.
Lisez la suite et vous découvrirez tout sur les innovations de vacances dans la version GitLab 11.6!
Nous vous invitons à nos réunions
Suzanne a aidé GitLab à revoir notre récent produit, le modèle volontaire d'accessibilité des produits (VPAT), en organisant et en affinant les tâches open source; Elle a également aidé à évaluer l'état actuel du produit à l'aide d'outils d'analyse statique et de tests manuels. VPAT garantit la conformité aux normes d'accessibilité (pour les personnes handicapées et l'interopérabilité), et ce produit est une grande étape dans l'amélioration de l'accessibilité de GitLab pour tout le monde afin que tout le monde puisse l'utiliser et contribuer au développement.
Merci Suzanne Nous apprécions vraiment votre contribution qui aidera plus de gens à utiliser GitLab.
Principales caractéristiques de la sortie de GitLab 11.6
Fonctions sans serveur (version alpha)
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Sur la base de l'intégration avec Knative ( article original , traduction ) ajoutée dans la version GitLab 11.5, nous présentons une nouvelle fonctionnalité - des fonctions sans serveur sous le contrôle de Knative, que les utilisateurs peuvent créer dans leur référentiel.
Vous devrez définir vos fonctions dans le fichier .gitlab-ci.yml du référentiel et utiliser le .gitlab-ci.yml . Chaque fonction sera placée sur votre cluster, et Knative se chargera de toutes et de l'expansion en fonction des ressources requises. Cette fonctionnalité permettra aux développeurs d'applications de publier de nouvelles versions plus rapidement sans se soucier de la configuration et de la maintenance de l'infrastructure.
Documentation des applications et fonctions sans serveur et du ticket d'origine
Lancement de CI / CD pour les demandes de fusion
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Le démarrage d'un travail spécifique dans le cas d'une demande de fusion est devenu plus facile. L'utilisation de la valeur merge_requests conjonction avec les mots clés only/except vous permettra de configurer le lancement pour fonctionner uniquement avec la demande de fusion, ou dans les cas inverses. Cela donne plus de contrôle sur le comportement du pipeline et ouvre également l'accès à de nouvelles variables d'environnement qui pointent vers la branche cible et l'ID de demande de fusion, ce qui vous permet de mettre en œuvre d'autres stratégies de comportement.
Documentation sur le lancement des travaux après les demandes de fusion et le ticket d'origine
Modifications proposées
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
La collaboration sur les demandes de fusion est devenue plus facile - vous n'avez plus besoin de copier le code pour accepter les modifications proposées. Maintenant, des modifications peuvent être suggérées lorsque vous commentez la différence de demande de fusion et acceptées en un seul clic par tout utilisateur disposant d'autorisations d'écriture dans ce fil.
Désormais, cette fonctionnalité fonctionne sur GitLab.com et peut être connectée dans les instances utilisateur de GitLab à l'aide de la fonctionnalité de plug-in diff_suggestions, et dans GitLab 11.7, cette fonctionnalité sera activée par défaut.
Documentation des modifications proposées et ticket d'origine
Terminal Web pour Web IDE (Beta)
(ULTIME)
L'IDE Web facilite et accélère les modifications et le traitement des commentaires de demande de fusion, éliminant ainsi la nécessité de sauvegarder les modifications et de changer les branches localement. Mais faire de grands changements sans terminal pour exécuter des tests, expérimenter avec REPL (boucle de lecture-évaluation-impression - boucle «lire-calculer-sortie») et compiler le code n'est pas facile.
Maintenant, grâce à l'IDE Web, vous pouvez lancer le terminal Web, travailler dans l'éditeur et avoir le terminal sous la main comme vous le feriez localement - suivre ce qui passe par l'API ou vérifier votre syntaxe dans REPL. Le terminal Web est la première fonctionnalité avec un traitement côté serveur dans l'IDE Web, il est configuré à l'aide du nouveau .gitlab/.gitlab-webide.yml .
Les terminaux Web interactifs ne sont pas encore disponibles sur GitLab.com et pour le moment les modifications ne sont pas synchronisées entre l'éditeur et le terminal Web. Vous pouvez suivre la progression du développement ici , dans la prochaine version, nous ajouterons la prise en charge des modifications de la mise en miroir et de l'aperçu en temps réel .
Documentation du terminal Web et ticket original
Modèles de projet pour les groupes
(PREMIUM, ULTIME, ARGENT, OR)
Les modèles de projet aident les utilisateurs à démarrer rapidement de nouveaux projets. Dans la version 11.2 ( article d'origine , traduction ), nous avons introduit des modèles de projet pour les instances utilisateur .
Avec GitLab 11.6, nous sommes heureux d'annoncer que cette fonctionnalité est désormais disponible pour les groupes. Créez un sous-groupe spécial à travers les paramètres du nouveau groupe et les projets de ce sous-groupe deviendront disponibles en tant que modèles. Cela simplifie la configuration initiale et garantit l'uniformité entre vos projets, en particulier dans les grandes structures telles que l'architecture de microservice.
Documentation du modèle de projet et ticket d'origine
Clusters Kubernetes pour les groupes (bêta)
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Souvent, les équipes de développement travaillant sur des projets connexes doivent utiliser le même cluster Kubernetes pour déployer leurs applications. À partir de GitLab 11.6, les utilisateurs pourront créer des clusters Kubernetes au niveau du groupe, qui pourront être utilisés dans tous les projets contenus dans ce groupe ou ses sous-groupes.
Cela simplifiera et accélérera considérablement le processus de configuration de l'infrastructure de vos projets et vous permettra de vous concentrer sur le développement d'applications intéressantes.
Documentation du cluster pour les groupes et le ticket d'origine
Gestionnaire de certificats pour Kubernetes
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
La sécurité est essentielle lors du déploiement d'applications au stade du développement. Le gestionnaire de certificats est un contrôleur de gestion des certificats basé sur Kubernetes qui crée et met à jour automatiquement les certificats SSL à l'aide de Let's Encrypt.
L'utilisation de ce certificat SSL pour les applications servies via Auto DevOps et pour les déploiements via JupyterHub activera HTTPS.
Documentation d'installation de l'application et ticket d'origine
Graphique de vulnérabilité dans le panneau de sécurité du groupe
(ULTIME, OR)
Les tableaux de bord de sécurité de groupe sont le principal outil grâce auquel les professionnels de la sécurité peuvent gérer les vulnérabilités de leurs projets. L'une des exigences les plus importantes est de savoir comment le nombre de vulnérabilités change d'un jour à l'autre et de savoir si l'équipe est capable de résoudre les problèmes assez rapidement.
Dans la version GitLab 11.6, nous avons ajouté un graphique de vulnérabilité au panneau de sécurité du groupe, qui vous permet de suivre facilement les changements de vulnérabilité au cours du dernier mois. Pour chaque niveau de danger, vous pouvez regarder les valeurs des indicateurs de vulnérabilité et, tout au long du programme, examiner plus en détail un moment précis dans le temps.
Documentation du panneau de sécurité de groupe et ticket d'origine
Autres améliorations dans GitLab 11.6
Authentification par jeton matériel basée sur une carte à puce
(PREMIUM, ULTIME)
Pour les organisations où les développeurs travaillent dans des environnements qui utilisent des jetons matériels avec des certificats X.509 et des capacités de carte à puce pour l'authentification (comme les YubiKeys ou les cartes d'accès partagé (CAC)), GitLab prend désormais en charge la création et la connexion d'utilisateurs locaux.
Désormais, les utilisateurs peuvent utiliser des jetons matériels pour accéder à GitLab, ce qui augmente la sécurité et élimine la nécessité de gérer les données sur les connexions / mots de passe qui ne sont associés à aucun appareil physique.
Documentation d'authentification par carte à puce et ticket d'origine
(GRATUIT, BRONZE, ARGENT, OR)
Pour les utilisateurs avec un abonnement payant à GitLab.com, nous avons rendu les informations sur votre statut d'abonnement plus compréhensibles.
Dans la version 11.6, nous avons amélioré la section Facturation sous la page des paramètres de groupe pour inclure des informations détaillées sur votre abonnement de groupe. Maintenant, vous pouvez facilement voir les lieux occupés maintenant et les lieux qui étaient occupés dans le passé, ainsi que les heures de début et de fin de votre abonnement.
Documentation et ticket original
Envoi de notifications à Discord
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
À partir de cette version, vous pouvez intégrer GitLab à Discord , ce qui vous permettra d'envoyer des notifications au canal dans Discord en réponse aux événements GitLab, tels que pousser vers le référentiel, télécharger les mises à jour des tickets, fusionner les demandes et autres.
Merci à Vitaliy Klachkov pour cette fonctionnalité!
Documentation de notification de désaccord et ticket d'origine
Billets promotionnels pour les épopées
(ULTIME, OR)
Le développement de logiciels est un processus créatif auquel toute l'équipe participe et toutes les idées doivent être prises en considération. Nous avons ajouté une nouvelle fonctionnalité avec laquelle les idées qui apparaissent sous la forme de billets peuvent désormais facilement devenir des épopées.
Maintenant, vous pouvez facilement mettre à niveau votre ticket vers une épopée en utilisant la nouvelle action rapide . Entrez /promote dans le commentaire du ticket et cliquez sur Commentaire . Le ticket sera fermé et son contenu sera copié dans la nouvelle épopée, qui apparaîtra dans le groupe parent du projet. En plus du nom, de la description et des discussions sous le ticket, les tags, les participants et même les likes / likes ne seront pas copiés.
Documentation sur l'augmentation des tickets pour les épopées et le ticket original
Amélioration de l'apparence du panneau des paramètres lors du filtrage des tickets et des demandes de fusion
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Nous avons mis à jour la conception de la présentation des résultats de recherche pour les tickets et les tableaux de bord pour les demandes de fusion pour correspondre à la conception dans le reste de GitLab.
Documentation de recherche GitLab et ticket d'origine
Enregistrement de l'ordre de tri des tickets, des demandes de fusion et des épopées pour chaque utilisateur
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Nous avons ajouté la possibilité pour les utilisateurs de définir leur propre ordre de tri pour les tickets, les demandes de fusion, les épopées et même les plannings de tâches. Les informations sur l'attribut par lequel vous triez et sur l'ordre de tri (croissant ou décroissant) sont stockées dans le système, donc lorsque vous revenez à la liste des objets que vous avez consultés plus tôt, ils seront triés exactement comme avant.
Documentation de recherche épique et ticket original
Visualisez les épopées ouvertes et fermées sur une feuille de route
(ULTIME, OR)
Nous avons récemment ajouté la possibilité de fermer des épopées dans GitLab, ce qui vous permet de marquer des épopées terminées ou non pertinentes.
À partir de cette version, nous ajoutons également la possibilité d'afficher les épopées ouvertes, les épopées fermées, ou les deux à la fois sur les feuilles de route. Cela sera utile pour les équipes qui doivent se concentrer uniquement sur les tâches restantes et urgentes (épopées ouvertes), ou qui souhaitent afficher les tâches terminées (épopées fermées), ou qui doivent voir les tâches terminées et en cours sur la même carte. Avec nos nouvelles fonctionnalités, une telle flexibilité devient disponible. De plus, vos paramètres sont désormais enregistrés dans le système pour chaque utilisateur, de sorte que lorsque vous revenez à la feuille de route, elle sera exactement la même que la fois précédente.
Documentation du calendrier des tâches et ticket original
Afficher des tâches similaires
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Au fur et à mesure que les projets se développent, les développeurs créent de nouveaux tickets pour les tâches émergentes, et souvent ces tickets commencent à se répéter.
Afin d'aider les gens à trouver rapidement des réponses et à gagner du temps pour les responsables de projet, maintenant lors de la création d'un nouveau ticket, des tickets similaires sont affichés. Ils apparaissent lorsque vous saisissez un titre dans le formulaire Web de création de ticket. Cela aidera les utilisateurs à trouver immédiatement des tickets similaires, à y basculer et à s'impliquer immédiatement dans les discussions en cours, ce qui offre encore plus de possibilités de collaboration dans GitLab.
Documentation pour les billets similaires et le billet d'origine
Prise en charge de la mise en miroir push via SSH avec authentification par clé publique
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
La mise en miroir de référentiels vous permet de copier des référentiels Git d'un endroit à un autre. Cela facilite le travail avec plusieurs instances de GitLab lors de la création d'un miroir de référentiel sur un autre serveur. Cependant, certains serveurs cibles autorisent uniquement l'accès à Git via SSH avec l'authentification par clé publique.
GitLab prend désormais en charge la mise en miroir SSH avec l'authentification par clé publique en plus de l'authentification SSH par mot de passe et de la mise en miroir HTTP.
Documentation de mise en miroir push et ticket d'origine
Le responsable du projet peut désormais supprimer les pipelines via l'API
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Vous pouvez maintenant supprimer le pipeline à l'aide de l'API. Cela est utile dans les cas où une fuite d'informations secrètes s'est produite dans le pipeline, de nombreux pipelines inutiles ont été créés ou d'autres problèmes se sont produits lorsque les pipelines doivent être supprimés.
Documentation pour retirer les convoyeurs et un ticket original
Les variables de déclenchement sont désormais masquées par défaut dans l'interface utilisateur
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Toutes les variables de déclenchement sont désormais masquées par défaut dans l'interface utilisateur et ne s'affichent que lorsqu'elles sont explicitement spécifiées par l'utilisateur. Cela empêchera la divulgation involontaire de valeurs lors du partage d'un écran ou de la capture d'écran.
Documentation sur l'utilisation des variables de déclenchement et le ticket d'origine
Une notification par e-mail pour les examens des demandes de fusion
(PREMIUM, ULTIME, ARGENT, OR)
Une révision du code est une pratique nécessaire pour chaque projet réussi, mais recevoir une notification par e-mail pour chaque commentaire est parfois inutile. Désormais, une seule notification est envoyée avec une liste de tous les commentaires afin de ne pas salir votre boîte de réception.
La révision de la demande de fusion ( article original , traduction ) présentée dans GitLab 11.4 facilite la révision du code en vous permettant de composer, réviser et envoyer des commentaires en une seule fois.
Cette fonctionnalité est désormais disponible sur GitLab.com et peut également être activée pour les instances d'utilisateurs GitLab à l'aide de la fonctionnalité du plugin batch_review_notification (indicateur de fonctionnalité, bascule de fonctionnalité). Il sera activé par défaut pour les instances utilisateur dans GitLab 11.7.
Fusionner la documentation d'examen de la demande et le ticket d'origine
Amélioration de la page d'affichage du projet
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Dans la version de GitLab 11.6, nous continuons à travailler avec l'interface utilisateur de notre page de projet: nous avons amélioré l'affichage du titre du projet, amélioré le contraste et travaillé avec des espaces vides pour souligner les actions fréquemment utilisées et améliorer la structure globale des informations.
Documentation du projet et ticket original
Info-bulle sur le profil utilisateur
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Dans cette version, nous avons ajouté des info-bulles étendues lorsque vous survolez le nom d'utilisateur sur les pages de tâches et de demande de fusion. Auparavant, nous n'affichions que le nom complet, et maintenant le nom complet de l'utilisateur, l'ID, la société, les informations de localisation et le statut de l'utilisateur, s'ils sont disponibles, seront visibles.
En plus d'ajouter une info-bulle développée sur d'autres pages, nous travaillons sur des améliorations ultérieures des info-bulles pour les tâches et les demandes de fusion qui seront bientôt disponibles.
Billet original
La chaîne de navigation comprend «Nouveau» et «Modifier» pour les jalons et les balises
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Dans cette version, nous améliorons notre chaîne de navigation du fil d'Ariane GitLab pour les jalons et les balises. Lors de la création ou de la modification d'un jalon ou d'une balise, à la fin de la chaîne de navigation, il existe un élément supplémentaire «Nouveau» ou «Modifier», qui est désormais cohérent avec les tickets et les demandes de fusion.
Merci George Tsiolis pour cette fonctionnalité!
Billet original
Prise en charge HTTPS pour les DevOps automatiques
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Auto DevOps chez GitLab répond à de nombreux défis liés à la livraison de logiciels de qualité. GitLab 11.6 étend encore ses capacités en ajoutant la prise en charge de HTTPS.
En utilisant le gestionnaire de certificats pour Kubernetes, Auto DevOps servira automatiquement les applications via HTTPS, offrant une sécurité renforcée pour vos applications.
Documentation Auto DevOps et ticket d'origine
Prise en charge HTTPS pour JupyterHub
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
JupyterHub fournit aux équipes de données un moyen puissant de partager des informations. Souvent, les données confidentielles nécessitent une sécurité accrue.
En utilisant le gestionnaire de certificats pour Kubernetes, JupyterHub servira automatiquement Jupyter sur HTTPS, offrant une sécurité renforcée pour vos données sensibles.
Documentation sur l'installation d'applications sur des clusters et le ticket d'origine
Mappage du code de réponse HTTP Kubernetes
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Pour faciliter et accélérer le dépannage lors de l'installation d'applications gérées par GitLab dans le cluster Kubernetes, nous envoyons maintenant le code de réponse HTTP depuis Kubernetes.
Documentation de gestion de cluster et ticket d'origine
Utilisateurs invités d'or gratuits et illimités
(ULTIME, OR)
Dans la version 11.0, nous avons introduit un nombre illimité d'utilisateurs invités pour les plans Ultimate.
Nous étendons maintenant cela aux plans Gold, afin que les groupes utilisant le plan tarifaire GitLab.com le plus élevé, qu'il s'agisse d'un serveur utilisateur ou d'un SaaS cloud, peuvent bénéficier de l'ajout d'invités sans frais supplémentaires.
Documentation d'accès utilisateur et ticket d'origine
Empêcher les administrateurs de jouer le rôle d'utilisateurs
(NOYAU, DEMARREUR, PREMIUM, ULTIME)
Dans certaines organisations, permettre aux administrateurs d'agir en tant qu'utilisateurs est un risque pour la sécurité car les actions des administrateurs sont attribuées à l'utilisateur au nom duquel ils agissent. Pour résoudre ce problème, nous ajoutons une option personnalisée afin que vous puissiez désactiver cette fonctionnalité.
Documentation sur l'interdiction aux administrateurs de jouer le rôle d'utilisateurs et le ticket d'origine
Filtrage de la matière de Markdown pour TOML et JSON
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Les informations préliminaires sont les métadonnées incluses en haut du document de démarque, souvent utilisées par des générateurs de sites statiques tels que Jekyll et Hugo . Lorsque GitLab convertit les fichiers de démarques des référentiels en HTML pour l'affichage, la matière première conserve son format et s'affiche telle quelle, pour plus de clarté.
En plus des séparateurs de YAML ( --- ), GitLab prend désormais en charge les séparateurs de TOML ( +++ ), les séparateurs de JSON ( ;;; ) et les séparateurs arbitraires, ce qui vous permet de prendre en charge n'importe quel format de données.
Merci à Travis Miller pour cette fonctionnalité!
Documentation initiale et ticket original
Prise en charge de DevOps automatique pour les tableaux de bord de sécurité de groupe
(ULTIME, OR)
Dans la version de GitLab 11.5 ( article original , traduction ), nous avons publié le panneau de sécurité du groupe , qui affiche les résultats de SAST .
Avec la version 11.6, nous ajoutons la dernière version de la définition d' opération SAST au modèle Auto DevOps , et maintenant les résultats sont entièrement compatibles avec le panneau de sécurité du groupe, afin que les utilisateurs puissent utiliser les deux fonctions en même temps.
Remarque: GitLab Runner 11.5 ou supérieur est requis pour définir un nouveau travail SAST; vous pouvez en savoir plus sur cet article de blog .
Documentation Auto DevOps et ticket d'origine
Des notes de version détaillées et des instructions de mise à jour / d'installation peuvent être trouvées dans la publication originale en anglais: GitLab 11.6 publié avec des clusters sans serveur et de groupe .
Cattidourden , rishavant , ainoneko et maryartkey ont travaillé sur la traduction de l'anglais .