Projets и Concernant la décision de créer le service de développement collaboratif Git Forge, qui sera construit sur la plateforme GitLab, GitLab deviendra la plateforme principale pour interagir avec les dépôts Git et héberger les projets liés aux distributions. CentOS et Fedora. Service précédemment utilisé Pagure continuera d'exister, mais sera confié à la communauté intéressée par la poursuite de son développement. Pagure sera retiré de l'équipe CPE (Community Platform Engineering) de Red Hat, qui gère l'infrastructure de développement et de publication des versions de Fedora. CentOS.
Lors de l'évaluation des solutions possibles pour le nouveau Git Forge, nous avons pris en compte
Pagure et Gitlab. Basé sur une étude d'environ et les vœux des participants au projet Fedora, CentOSPour RHEL et CPE, les exigences fonctionnelles ont été définies et GitLab a été choisi. Outre les opérations standard sur les dépôts (fusion, duplication, ajout de code, etc.), la sécurité, la facilité d'utilisation et la stabilité de la plateforme figuraient parmi les critères essentiels.
Les exigences comprenaient des fonctionnalités telles que l'envoi de requêtes push via HTTPS, des moyens de restreindre l'accès aux succursales, la prise en charge des succursales privées, la séparation de l'accès pour les utilisateurs externes et internes (par exemple, pour travailler à l'élimination des vulnérabilités lors d'un embargo sur la divulgation d'informations sur le problème) , interface de familiarité, unification des sous-systèmes pour travailler avec les rapports de problèmes, le code, la documentation et la planification de nouvelles fonctionnalités, disponibilité d'outils d'intégration avec l'IDE, prise en charge des flux de travail standard.
Parmi les fonctionnalités de GitLab qui ont finalement influencé la décision de choisir cette plateforme, les suivantes ont été mentionnées : la prise en charge des sous-groupes avec un accès sélectif aux dépôts, la possibilité d’utiliser un bot pour les fusions automatiques (nécessite CentOS Flux pour la maintenance des paquets du noyau), la présence d'outils intégrés pour la planification du développement, la possibilité d'utiliser un service SAAS prêt à l'emploi avec un niveau de disponibilité garanti (libérera des ressources pour la maintenance de l'infrastructure serveur).
La décision est déjà critiques parmi les développeurs en raison du fait que la décision a été prise sans discussion préalable approfondie. Des inquiétudes ont également été soulevées quant au fait que le service n'utiliserait pas l'édition communautaire gratuite de GitLab. En particulier, les fonctionnalités nécessaires à la mise en œuvre des exigences de Git Forge décrites dans l'annonce ne sont disponibles que dans la version propriétaire. .
L'intention d'utiliser le service SAAS (application as a service) fourni par GitLab, au lieu de déployer GitLab sur ses serveurs, a également été critiquée, ce qui rend le service hors de contrôle (par exemple, il est impossible d'être sûr que toutes les vulnérabilités de le système est rapidement éliminé, les infrastructures sont entretenues, un jour il n'y aura plus et le sabotage par le personnel d'une société tierce est exclu). La solution ne fonctionne pas non plus avec , qui précisent que le projet doit privilégier les alternatives gratuites.
Pendant ce temps, GitLab sur la découverte d'implémentations de 18 fonctionnalités auparavant proposées uniquement dans les éditions propriétaires de GitLab. Les capacités couvrent divers domaines de la gestion du cycle complet de développement logiciel, notamment la planification du développement, la création de projets, la vérification, la gestion des packages, la génération de versions, la configuration et la sécurité.
Les fonctions suivantes ont été transférées à la gamme libre :
- Problème connexe en pièce jointe ;
- Problème d'exportation de GitLab vers CSV ;
- Un mode de planification, d'organisation et de visualisation du processus de développement de fonctionnalités ou de versions individuelles ;
- Service intégré pour connecter les participants au projet avec des tiers par courrier électronique.
- Terminal Web pour l'IDE Web ;
- Possibilité de synchroniser des fichiers pour tester les changements de code dans le terminal Web ;
- Concevoir des contrôles qui vous permettent de télécharger des maquettes et des ressources sur Issue, en utilisant Issue comme point d'accès unique à tout ce dont vous avez besoin pour développer une nouvelle fonctionnalité ;
- Rapports sur la qualité du code ;
- Prise en charge des gestionnaires de packages Conan (C/C++), Maven (Java), NPM (node.js) et NuGet (.NET) ;
- Prise en charge des déploiements Canary, permettant d'installer une nouvelle version de l'application sur une petite partie des systèmes ;
- Distributions incrémentielles, permettant aux nouvelles versions d'être livrées dans un premier temps uniquement à un petit nombre de systèmes, augmentant progressivement la couverture jusqu'à 100 % ;
- Des drapeaux d'activation de fonctionnalités, qui permettent de livrer le projet dans différentes éditions, activant dynamiquement certaines fonctionnalités ;
- Mode aperçu du déploiement, qui vous permet d'évaluer l'état de chaque environnement d'intégration continue basé sur Kubernetes ;
- Prise en charge de la définition de plusieurs clusters Kubernetes dans le configurateur (par exemple, vous pouvez utiliser des clusters Kubernetes distincts pour les implémentations d'essai et les charges de travail) ;
- Prise en charge de la définition de politiques de sécurité du réseau de conteneurs qui vous permettent de limiter l'accès entre les pods Kubernetes.
De plus, on peut noter GitLab met à jour 12.9.1, 12.8.8 et 12.7.8 (Community Edition et Enterprise Edition), qui corrigent la vulnérabilité. Le problème est présent depuis la sortie de GitLab EE/CE 8.5 et permet de lire le contenu de n'importe quel fichier local lors du déplacement d'un problème entre projets.
Les détails sur la vulnérabilité seront divulgués après 30 jours.
Source: opennet.ru
