Projets и sur la décision de créer un service de développement collaboratif Git Forge, qui sera construit à l'aide de la plateforme GitLab. GitLab deviendra la principale plateforme d'interaction avec les référentiels Git et d'hébergement de projets liés aux distributions CentOS et Fedora. Service déjà utilisé continuera d'exister, mais sera confié aux soins d'une communauté intéressée par un développement continu. Pagure ne bénéficiera plus du support de l'équipe CPE (Community Platform Engineering) employée chez Red Hat, qui s'occupe de maintenir l'infrastructure pour le développement et la publication des versions de Fedora et 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 souhaits des participants aux projets Fedora, CentOS, RHEL et CPE, les exigences de fonctionnalité ont été formées et le choix a été fait en faveur de Gitlab. Outre les opérations standards avec les référentiels (fusion, création de forks, ajout de code, etc.), la sécurité, la facilité d'utilisation et la stabilité de la plateforme figuraient parmi les exigences clés.
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, on a mentionné la prise en charge de sous-groupes avec un accès sélectif aux référentiels, la possibilité d'utiliser un bot pour les fusions automatiques (CentOS Stream est requis pour maintenir les packages avec le noyau), le présence d'outils intégrés pour planifier le développement, 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 du 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