Projecten en over de beslissing om een service voor gezamenlijke ontwikkeling Git Forge te creĆ«ren, die zal worden opgebouwd met behulp van het GitLab-platform. GitLab wordt het primaire platform voor interactie met Git-repositories en voor het hosten van projecten die verband houden met de distributies CentOS en Fedora. De eerder gebruikte dienst zal blijven bestaan, maar zal worden overgedragen aan de gemeenschap die geĆÆnteresseerd is in de voortzetting van de ontwikkeling. Pagure zal worden uitgefaseerd onder de zorg van het door Red Hat ingeschakelde CPE-team (Community Platform Engineering), dat verantwoordelijk is voor het onderhoud van de infrastructuur voor de ontwikkeling en publicatie van releases van Fedora en CentOS.
Bij de evaluatie van mogelijke oplossingen voor de nieuwe Git Forge werden
Pagure en GitLab overwogen. Op basis van een studie van ongeveer en wensen van deelnemers aan de projecten Fedora, CentOS, RHEL en CPE, zijn de functionele vereisten vastgesteld en is de keuze gevallen op GitLab. Naast de standaard bewerkingen met repositories (samenvoegen, forks aanmaken, code toevoegen, enz.) zijn de belangrijkste vereisten veiligheid, gebruiksgemak en stabiliteit van het platform.
De vereisten omvatten mogelijkheden zoals het verzenden van push-verzoeken via HTTPS, middelen voor het beperken van toegang tot takken, ondersteuning voor privƩ-takken, het scheiden van toegang voor externe en interne gebruikers (bijvoorbeeld voor het oplossen van kwetsbaarheden tijdens een embargo op het vrijgeven van informatie over het probleem), gebruiksvriendelijkheid van de interface, uniformiteit van subsystemen voor het werken met probleemmeldingen, code, documentatie en planning van nieuwe mogelijkheden, en de beschikbaarheid van middelen voor integratie met IDE's, ter ondersteuning van typische werkprocessen.
Van de mogelijkheden van GitLab die uiteindelijk invloed hadden op de beslissing om dit platform te kiezen, worden de ondersteuning voor subgroepen met selectieve toegang tot repositories, de mogelijkheid om een bot te gebruiken voor automatische samenvoegingen (CentOS Stream is vereist voor het onderhouden van pakketten met de kernel), de aanwezigheid van ingebouwde middelen voor ontwikkelingsplanning en de mogelijkheid om gebruik te maken van een kant-en-klare SAAS-service met gegarandeerd niveau van beschikbaarheid genoemd (dit zal middelen vrijmaken voor het onderhoud van de serverinfrastructuur).
De beslissing is al genomen. kritiek onder ontwikkelaars over het feit dat de beslissing werd genomen zonder voorafgaande uitgebreide discussie. Er zijn ook zorgen geuit dat de service de vrij beschikbare Community-editie van GitLab niet zal gebruiken. In het bijzonder zijn de mogelijkheden die nodig zijn om aan de aangekondigde vereisten voor Git Forge te voldoen, alleen beschikbaar in de proprietaire versie. .
Kritiek werd ook geuit op de intentie om gebruik te maken van de door GitLab aangeboden SAAS-service (software als dienst), in plaats van GitLab op eigen servers te implementeren, wat de service buiten de controle plaatst (bijvoorbeeld, het is niet zeker dat alle kwetsbaarheden in het systeem snel worden verholpen, ondersteunt de infrastructuur, op een gegeven moment zal het niet zijn en het uitsluiten van sabotage door personeel van een externe onderneming). De beslissing is ook niet in overeenstemming met , waarin is gedefinieerd dat het project de voorkeur moet geven aan open-source alternatieven.
Ondertussen heeft het bedrijf GitLab de implementatie aangekondigd van 18 functionaliteiten die eerder alleen in de proprietaire edities van GitLab werden aangeboden. De mogelijkheden bestrijken verschillende gebieden van het volledige ontwikkelingsproces, waaronder ontwikkelingsplanning, projectopzet, verificatie, pakketbeheer, releasevorming, configuratie en beveiliging.
Onder de open-source zijn de volgende functies vertaald:
- Het koppelen van gerelateerde issues;
- Exporteren van issues vanuit GitLab naar CSV;
- Planningsmodus, ordenen en visualiseren van het ontwikkelingsproces van specifieke functionaliteiten of releases;
- Ingebouwde servicedienst voor het verbinden van projectdeelnemers met externe personen via email.
- Webterminal voor Web IDE;
- Mogelijkheid voor bestandsynchronisatie om wijzigingen in de code te testen in de webterminal;
- Ontwerpbeheer tools waarmee ontwerpen en middelen in issues kunnen worden geĆ¼pload, gebruikmakend van issues als het enige toegangspunt tot alles wat nodig is voor de ontwikkeling van een nieuwe functionaliteit;
- Kwaliteitsrapporten van de code;
- Ondersteuning voor pakketbeheerders Conan (C/C++), Maven (Java), NPM (node.js) en NuGet (.NET);
- Ondersteuning voor canary-implementaties, waarmee een nieuwe versie van de applicatie op een klein aantal systemen kan worden geĆÆnstalleerd;
- Incrementele uitgaven die in eerste instantie nieuwe versies alleen naar een klein aantal systemen leveren, en geleidelijk het bereik tot 100% uitbreiden;
- Activeringsvlaggen voor functionaliteit die het mogelijk maken om het project in verschillende edities te leveren, door bepaalde mogelijkheden dynamisch te activeren;
- Overzichtsmodus voor implementaties die de staat van elke omgeving voor continue integratie op basis van Kubernetes kunnen evalueren;
- Ondersteuning voor het definiƫren van meerdere Kubernetes-clusters in de configurator (bijvoorbeeld, aparte Kubernetes-clusters voor testimplementaties en productieworkloads kunnen worden gebruikt);
- Ondersteuning voor het definiƫren van netwerken veiligheidsbeleid voor containers, die de toegang tussen Kubernetes-pods kunnen splitsen.
Daarnaast kan worden vermeld updates GitLab 12.9.1, 12.8.8 en 12.7.8 (Community Edition en Enterprise Edition), waarin een kwetsbaarheid is verholpen. Het probleem doet zich voor vanaf de release van GitLab EE/CE 8.5 en maakt het mogelijk om de inhoud van elk lokaal bestand te lezen bij het verplaatsen van issue tussen projecten.
Details over de kwetsbaarheid worden binnen 30 dagen openbaar gemaakt.
Bron: opennet.ru
