Projekter og om løsningen til at oprette en samarbejdsudviklingstjeneste Git Forge, som vil blive bygget ved hjælp af GitLab-platformen. GitLab vil blive den primære platform til interaktion med Git-repositories og til hosting af projekter relateret til distributioner af CentOS og Fedora. Den tidligere anvendte tjeneste vil fortsætte med at eksistere, men vil blive overdraget til et community, der er interesseret i at fortsætte udviklingen. Pagure vil blive taget ud af pleje af det fuldtidsansatte team i Red Hat CPE (Community Platform Engineering), der arbejder med at vedligeholde infrastrukturen for udvikling og publicering af udgivelser af Fedora og CentOS.
Ved vurderingen af mulige løsninger til den nye Git Forge blev der overvejet
Pagure og GitLab. Baseret på en gennemgang af omkring og ønsker fra deltagere i projekterne Fedora, CentOS, RHEL og CPE, blev der dannet krav til funktionaliteten, og valget faldt på GitLab. Udover standardoperationer med repositories (fusion, oprettelse af forks, tilføjelse af kode osv.) blev sikkerhed, brugervenlighed og stabilitet på platformen fremhævet som nøglekrav.
Kravene inkluderede funktioner som muligheden for at sende push-anmodninger via HTTPS, værktøjer til begrænsning af adgang til grene, støtte til private grene, opdeling af adgang for eksterne og interne brugere (f.eks. til at arbejde med at rette sårbarheder under embargo for offentliggørelse af information om problemet), en velkendt brugerflade, standardisering af undersystemer til håndtering af fejlrapporter, kode, dokumentation og planlægning af nye funktioner samt tilstedeværelsen af værktøjer til integration med IDE'er, støtte til typiske arbejdsprocesser.
Blandt de funktioner i GitLab, der endeligt påvirkede beslutningen om at vælge denne platform, blev nævnt understøttelse af undergrupper med selektiv adgang til repositories, muligheden for at bruge en bot til automatiske fusioner (CentOS Stream krævet for at vedligeholde pakker med kernen), tilstedeværelsen af indbyggede værktøjer til planlægning af udvikling, muligheden for at bruge en færdig SAAS-tjeneste med garanteret tilgængelighed (vil frigøre ressourcer til vedligeholdelse af serverinfrastrukturen).
Beslutningen er allerede kritik blandt udviklere vedrørende beslutningen, der blev truffet uden forudgående bred diskussion. Der blev også fremsat bekymringer om, at tjenesten ikke ville anvende den åbne Community-udgave af GitLab. Specifikt er funktionerne, der er nødvendige for at implementere de i annoncebeskrivelsen nævnte krav til Git Forge, kun tilgængelige i den proprietære version. .
Kritik blev også rettet mod intentionen om at benytte den service, som GitLab tilbyder som SAAS (software som en tjeneste), i stedet for at implementere GitLab på egne servere, hvilket fjerner tjenesten fra ens kontrol (for eksempel kan man ikke være sikker på, at alle sårbarheder i systemet hurtigt rettes, støttet infrastruktur, som på et givet tidspunkt ikke vil være og udelukket diversionsmuligheder fra personale i tredjepartsfirmaer). Beslutningen stemmer heller ikke overens med , som fastslår, at projektet skal prioritere åbne alternativer.
I mellemtiden har GitLab annonceret implementeringen af 18 funktionaliteter, der tidligere kun blev tilbudt i de proprietære udgaver af GitLab. Funktionerne dækker forskellige områder inden for styring af hele softwareudviklingscyklussen, herunder udviklingsplanlægning, projektoprettelse, validering, håndtering af pakker, udgivelse, konfiguration og sikkerhed.
De følgende funktioner er blevet overført til den åbne version:
- Vedhæftning af relaterede issues;
- Eksport af issues fra GitLab til CSV;
- Planlægnings-, sorterings- og visualiseringsmodus for udviklingsprocessen for individuelle funktioner eller udgivelser;
- Indbygget servicetjeneste til at forbinde projektmedlemmer med eksterne parter via email.
- Web-terminal til Web IDE;
- Mulighed for filsynkronisering til test af ændringer i koden i web-terminalen;
- Designledelsesværktøjer, der muliggør upload af skitser og ressourcer til issues, der bruger issues som et centralt adgangspunkt for alt, hvad der er nødvendigt for at udvikle en ny funktion;
- Rapporter om kodekvalitet;
- Understøttelse af pakkeadministratorer som Conan (C/C++), Maven (Java), NPM (node.js) og NuGet (.NET);
- Understøttelse af kanariefugleudrulninger, der muliggør installation af en ny version af applikationen på en lille del af systemerne.
- Inkrementelle distributioner, der i starten kun leverer nye versioner til et begrænset antal systemer og gradvist øger dækningen til 100%;
- Aktiveringsflage for funktionalitet, der muliggør levering af projektet i forskellige udgaver ved dynamisk at aktivere bestemte funktioner;
- Oversigtsmodus for udrulninger, der gør det muligt at vurdere status for hvert miljø med kontinuerlig integration baseret på Kubernetes;
- Understøttelse af definitionen af flere Kubernetes-klynger i konfigurationsværktøjet (for eksempel kan separate Kubernetes-klynger bruges til testimplementeringer og arbejdsmængder);
- Understøttelse af definitionen af netværkssikkerhedspolitikker for containere, der muliggør adgangsbegrænsninger mellem Kubernetes-pods.
Yderligere kan det nævnes opdateringer af GitLab 12.9.1, 12.8.8 og 12.7.8 (Community Edition og Enterprise Edition), hvor en sårbarhed er blevet eliminert. Problemet opstår fra udgivelsen af GitLab EE/CE 8.5 og gør det muligt at læse indholdet af enhver lokal fil, når issues flyttes mellem projekter.
Detaljer om sårbarheden vil blive afsløret om 30 dage.
Kilde: opennet.ru
