projekter и om beslutningen om at oprette den kollaborative udviklingstjeneste Git Forge, som vil blive bygget ved hjælp af GitLab-platformen. GitLab vil blive den primære platform til interaktion med Git-arkiver og til hosting af projekter relateret til distributioner. CentOS og Fedora. Tidligere anvendt tjeneste vil fortsat eksistere, men vil blive overdraget til det fællesskab, der er interesseret i fortsat udvikling. Pagure vil blive fjernet fra CPE-teamet (Community Platform Engineering) ansat af Red Hat, som vedligeholder infrastrukturen til udvikling og udgivelse af Fedora-udgivelser og CentOS.
Da vi evaluerede mulige løsninger til det nye Git Forge, kiggede vi på:
Pagure og Gitlab. Baseret på en undersøgelse af ca. og ønsker fra Fedora-projektdeltagere, CentOS, RHEL og CPE, funktionelle krav blev defineret, og Gitlab blev valgt. Ud over standard repository-operationer (merging, forking, tilføjelse af kode osv.) var sikkerhed, brugervenlighed og platformstabilitet blandt de vigtigste krav.
Kravene omfattede funktioner som HTTPS push, begrænsning af branch access, understøttelse af private branches, adskillelse af ekstern og intern brugeradgang (for eksempel at arbejde på at rette sårbarheder under en embargo mod videregivelse af information om problemet), kendskab til grænsefladen, forening af delsystemer til arbejde med problemrapporter, kode, dokumentation og planlægning af nye funktioner, tilgængelighed af værktøjer til IDE-integration, understøttelse af typiske arbejdsgange.
Blandt de GitLab-funktioner, der i sidste ende påvirkede beslutningen om at vælge denne platform, blev følgende nævnt: understøttelse af undergrupper med selektiv adgang til repositorier, muligheden for at bruge en bot til automatiske sammenføjninger (kræver CentOS Stream til vedligeholdelse af kernepakker), tilstedeværelsen af indbyggede værktøjer til udviklingsplanlægning, muligheden for at bruge en færdiglavet SAAS-tjeneste med et garanteret tilgængelighedsniveau (vil frigøre ressourcer til vedligeholdelse af serverinfrastrukturen).
Beslutningen er allerede taget kritik blandt udviklere af, at beslutningen blev truffet uden forudgående bred diskussion. Der var også bekymringer om, at tjenesten ikke ville bruge den gratis Community-udgave af GitLab. Især er de funktioner, der kræves for at implementere Git Forge-kravene, som er beskrevet i annonceringen, kun tilgængelige i den proprietære version. .
Der blev også rejst kritik af intentionen om at bruge SAAS-tjenesten (applikation som en service) leveret af GitLab i stedet for at implementere GitLab på sine egne servere, hvilket sætter tjenesten ud af kontrol (for eksempel er det umuligt at være sikker på, at alle sårbarheder i systemet rettes omgående). infrastrukturen er understøttet, på et tidspunkt vil den ikke være det og sabotage udført af personale fra en tredjepartsvirksomhed er udelukket). Løsningen passer heller ikke med , som fastsætter, at projektet skal prioritere gratis alternativer.
I mellemtiden, GitLab om open source-implementeringer af 18 funktionelle muligheder, der tidligere kun blev tilbudt i proprietære udgaver af GitLab. Kompetencer dækker forskellige områder inden for styring af hele softwareudviklingscyklussen, herunder udviklingsplanlægning, projektoprettelse, verifikation, pakning, generering af udgivelser, konfiguration og sikkerhed.
Følgende funktioner er blevet overført til gratisfunktioner:
- Vedhæftning af relaterede problemer;
- Eksporter problem fra GitLab til CSV;
- En tilstand til planlægning, organisering og visualisering af udviklingsprocessen for individuelle funktionaliteter eller udgivelser;
- Indbygget tjeneste til at forbinde projektdeltagere med tredjeparter via e-mail.
- Webterminal til web-IDE;
- Mulighed for at synkronisere filer til test af ændringer i kode i webterminalen;
- Designstyringsværktøjer, der giver dig mulighed for at uploade mockups og aktiver til et problem, og bruge problemet som et enkelt adgangspunkt til alt, hvad der er nødvendigt for at udvikle en ny funktion;
- Rapporter om kodekvalitet;
- Understøttelse af pakkehåndteringsprogrammer som Conan (C/C++), Maven (Java), NPM (node.js) og NuGet (.NET);
- Understøttelse af canary-implementeringer, som giver dig mulighed for at installere en ny version af en applikation på en lille delmængde af systemer;
- Trinvise distributioner, som i starten kun leverer nye versioner til et lille antal systemer og gradvist øger dækningen til 100 %;
- Funktionsaktiveringsflag, der tillader projektet at blive leveret i forskellige udgaver ved dynamisk at aktivere bestemte funktioner;
- En oversigtstilstand for implementeringer, der giver dig mulighed for at vurdere tilstanden af hvert Kubernetes-baseret kontinuerlig integrationsmiljø;
- Understøttelse af definition af flere Kubernetes-klynger i konfiguratoren (for eksempel kan du bruge separate Kubernetes-klynger til prøveinstallationer og produktionsarbejdsbelastninger);
- Understøttelse af definition af sikkerhedspolitikker for containernetværk for at begrænse adgang mellem Kubernetes-pods.
Derudover kan det bemærkes GitLab 12.9.1, 12.8.8 og 12.7.8 (Community Edition og Enterprise Edition) opdateringer, som retter sårbarheden. Problemet har været til stede siden GitLab EE/CE 8.5 og tillader, at indholdet af enhver lokal fil læses, når en opgave flyttes mellem projekter.
Detaljer om sårbarheden vil blive offentliggjort inden for 30 dage.
Kilde: opennet.ru
