Udviklere som står bag de populære Linux-distributions projekter "CentOS og Fedora" afsløret for nylig gennem en annonce beslutningen om at oprette en fælles udviklingstjeneste, der hedder som "Git Forge".
Denne nye tjeneste vil blive bygget ved hjælp af GitLab-platformen som bliver hovedplatformen at interagere med Git repositories og at være vært for projekter relateret til distributioner fra CentOS og Fedora.
Når man vurderer mulige løsninger til den nye Git Forge, Pagure og Gitlab blev overvejet. Baseret på undersøgelsen af cirka 300 anmeldelser og forslag fra deltagerne i Fedora-, CentOS-, RHEL- og CPE-projekterne, funktionalitetskravene blev dannet, og beslutningen blev truffet til fordel for Gitlab.
Ud over typiske lageroperationer blev platformssikkerhed, brugervenlighed og stabilitet erklæret blandt nøglekravene.
Kravene omfattede funktioner såsom at sende push-anmodninger gennem HTTPS, betyder at begrænse adgangen til versioner, understøttelse af private versioner, dele adgang mellem eksterne og interne brugeres (for eksempel at arbejde med at rette sårbarheder under embargoen for at afsløre information om et problem), forening af delsystemer til at arbejde med problemrapporter, kode, dokumentation og planlægning af nye funktioner, tilgængeligheden af værktøjer til integration med IDE, support til typiske arbejdsgange.
Blandt GitLab-funktionerne, der i sidste ende påvirkede beslutningen at vælge denne platform, understøttelse af undergrupper med selektiv adgang til arkiver blev nævnt, la mulighed for at bruge en bot til automatiske fusioner (CentOS Stream er påkrævet for at understøtte pakker med kernen), tilstedeværelsen af indbyggede værktøjer til planlægning af udvikling, muligheden for at bruge en færdiglavet SAAS-tjeneste med et garanteret tilgængelighedsniveau (det vil frigøre ressourcer til at vedligeholde serveren infrastruktur).
Beslutningen har allerede givet anledning til kritik blandt udviklere, i forbindelse med at beslutningen blev truffet uden forudgående drøftelse.
også der var bekymring for, at tjenesten ikke ville bruge den gratis fællesskabsudgave af GitLab. Især er de nødvendige funktioner til at implementere Git Forge-kravene beskrevet i meddelelsen kun tilgængelige i den proprietære version af GitLab Ultimate.
Intentionen om at udnytte SAAS-tjenesten leveret af GitLab (app as a service) blev også kritiseret, i stedet for at installere GitLab på deres servere, hvilket kaster tjenesten ud af kontrol (det er f.eks. umuligt at sikre, at alle sårbarheder i systemet er lappet). hurtigt bliver infrastrukturen korrekt vedligeholdt, og der vil ikke blive pålagt et eneste øjebliks telemetri, og sabotage fra tredjepartspersonale vil blive udelukket).
Løsningen passer heller ikke godt med Fedoras grundlæggende principper, som specificerer, at et projekt skal give fortrinsret til gratis alternativer.
I mellemtiden, annoncerede GitLab åbningen af implementeringer af 18 funktioner at tidligere blev de kun tilbudt i betalte udgaver af GitLab:
- Vedhæfte et relateret problem;
- GitLab-eksport til CSV-problem.
- Måden at planlægge, organisere og visualisere udviklingsprocessen for individuelle udgivelser eller funktioner.
- Indbygget service til at forbinde projektdeltagere med tredjeparter via e-mail.
- Webterminal til web-IDE.
- Evnen til at synkronisere filer for at teste kodeændringer i webterminalen.
- Designstyringsværktøjer, der giver dig mulighed for at uploade design og ressourcer til problemet, ved at bruge problemet som et enkelt adgangspunkt til alt det, der kræves for at udvikle en ny funktion.
- Kvalitetsrapporteringskode.
- Understøttelse af Conan (C/C++), Maven (Java), NPM (node.js) og NuGet (.NET) pakkeadministratorer.
- Understøttelse af kanariske installationer, så du kan installere en ny version af applikationen på en lille del af systemet.
- Inkrementel distribution, så nye versioner først kan frigives til et lille antal systemer, hvilket gradvist bringer dækningen op på 100 %.
- Funktionsaktiveringsflag, som giver mulighed for at levere projektet i forskellige udgaver, der dynamisk aktiverer visse funktioner.
- Generel implementeringstilstand, der giver dig mulighed for at vurdere tilstanden af hvert kontinuerligt integrationsmiljø baseret på Kubernetes.
- Understøttelse til at definere flere Kubernetes-klynger i konfiguratoren
- Understøttelse til at definere containernetværkssikkerhedspolitikker, der tillader differentiering af adgang mellem Kubernetes-pods.
kilde: Centos blog - fedora blog