projekter и om beslutningen om at skabe en kollaborativ udviklingstjeneste Git Forge, som vil blive bygget ved hjælp af GitLab-platformen. GitLab bliver den primære platform til at interagere med Git-depoter og til hosting af projekter relateret til CentOS- og Fedora-distributioner. Tidligere brugt service vil fortsætte med at eksistere, men vil blive overdraget til et samfund, der er interesseret i fortsat udvikling. Pagure vil blive fjernet fra støtten fra CPE (Community Platform Engineering) teamet ansat hos Red Hat, som er engageret i at vedligeholde infrastrukturen til udvikling og udgivelse af Fedora og CentOS udgivelser.
Da vi vurderede mulige løsninger til den nye Git Forge, overvejede vi
Pagure og Gitlab. Baseret på en undersøgelse af ca og ønsker fra deltagere i Fedora, CentOS, RHEL og CPE projekterne, funktionalitetskrav blev dannet og valget blev truffet til fordel for Gitlab. Ud over standardoperationer med repositories (fletning, oprettelse af gafler, tilføjelse af kode osv.), blev sikkerhed, brugervenlighed og stabilitet af platformen angivet blandt nøglekravene.
Kravene omfattede funktioner såsom afsendelse af push-anmodninger over HTTPS, midler til at begrænse adgangen til filialer, support til private filialer, adskillelse af adgang for eksterne og interne brugere (for eksempel at arbejde på at eliminere sårbarheder under en embargo mod at afsløre oplysninger om problemet) , familiarity interface, ensretning af delsystemer til arbejde med problemrapporter, kode, dokumentation og planlægning af nye funktioner, tilgængelighed af værktøjer til integration med IDE, understøttelse af standard arbejdsgange.
Af de GitLab-funktioner, der i sidste ende påvirkede beslutningen om at vælge denne platform, blev der nævnt understøttelse af undergrupper med selektiv adgang til arkiver, muligheden for at bruge en bot til automatiske fusioner (CentOS Stream er påkrævet for at vedligeholde pakker med kernen), tilstedeværelse af indbyggede værktøjer til planlægning af udvikling, evnen til at bruge en færdiglavet SAAS-tjeneste med et garanteret tilgængelighedsniveau (vil frigøre ressourcer til vedligeholdelse af serverinfrastrukturen).
Beslutningen er allerede kritik blandt udviklere på grund af, at beslutningen blev truffet uden omfattende forudgående diskussion. Der blev også rejst bekymring for, at tjenesten ikke ville bruge den gratis Comminity-udgave af GitLab. Især er de nødvendige muligheder for at implementere kravene til Git Forge beskrevet i meddelelsen kun tilgængelige i den proprietære version .
Hensigten med at bruge SAAS-tjenesten (applikation som en tjeneste) leveret af GitLab, i stedet for at installere GitLab på sine servere, blev også kritiseret, hvilket tager tjenesten ud af kontrol (det er f.eks. umuligt at være sikker på, at alle sårbarheder i systemet elimineres omgående, infrastruktur vedligeholdes, en dag bliver der nej og sabotage udført af personale fra en tredjepartsvirksomhed er udelukket). Løsningen virker heller ikke med , som specificerer, at projektet skal give fortrinsret til gratis alternativer.
I mellemtiden, GitLab om opdagelsen af implementeringer af 18 funktionaliteter, der tidligere kun blev tilbudt i proprietære udgaver af GitLab. Funktionerne dækker forskellige områder af styring af den fulde softwareudviklingscyklus, herunder udviklingsplanlægning, projektoprettelse, verifikation, pakkehåndtering, udgivelsesgenerering, konfiguration og sikkerhed.
Følgende funktioner er blevet overført til det frie område:
- Vedhæfte relateret problemstilling;
- Eksporter problem fra GitLab til CSV;
- En måde at planlægge, organisere og visualisere udviklingsprocessen for individuelle funktioner eller udgivelser;
- Indbygget service til at forbinde projektdeltagere med tredjeparter ved hjælp af e-mail.
- Webterminal til Web IDE;
- Evne til at synkronisere filer for at teste ændringer i kode i webterminalen;
- Designkontroller, der giver dig mulighed for at uploade mockups og aktiver til udstedelse, ved at bruge problemet som et enkelt adgangspunkt til alt, hvad du behøver for at udvikle en ny funktion;
- Kodekvalitetsrapporter;
- Support til pakkeadministratorer Conan (C/C++), Maven (Java), NPM (node.js) og NuGet (.NET);
- Understøttelse af kanariske installationer, så du kan installere en ny version af applikationen på en lille del af systemerne;
- Inkrementelle distributioner, der gør det muligt at levere nye versioner til kun et lille antal systemer i starten, hvilket gradvist øger dækningen til 100 %;
- Funktionalitetsaktiveringsflag, som gør det muligt at levere projektet i forskellige udgaver, der dynamisk aktiverer visse funktioner;
- Implementeringsoversigtstilstand, som giver dig mulighed for at vurdere tilstanden for hvert kontinuerligt integrationsmiljø baseret på Kubernetes;
- Understøttelse til at definere flere Kubernetes-klynger i konfiguratoren (du kan f.eks. bruge separate Kubernetes-klynger til prøveimplementeringer og arbejdsbelastninger);
- Understøttelse til at definere containernetværkssikkerhedspolitikker, der giver dig mulighed for at begrænse adgangen mellem Kubernetes-pods.
Derudover kan det bemærkes GitLab opdaterer 12.9.1, 12.8.8 og 12.7.8 (Community Edition og Enterprise Edition), som løser sårbarheden. Problemet har været til stede siden udgivelsen af GitLab EE/CE 8.5 og gør det muligt at læse indholdet af enhver lokal fil, når et problem flyttes mellem projekter.
Detaljer om sårbarheden vil blive afsløret efter 30 dage.
Kilde: opennet.ru