prosjekter и om beslutningen om å opprette en samarbeidende utviklingstjeneste, Git Forge, som skal bygges ved hjelp av GitLab-plattformen. GitLab vil bli den primære plattformen for samhandling med Git-repositorier og for å være vert for prosjekter relatert til CentOS- og Fedora-distribusjonene. Den tidligere brukte tjenesten vil fortsette å eksistere, men vil bli overlevert til et fellesskap som er interessert i fortsatt utvikling. Pagure vil bli fjernet fra CPE-teamet (Community Platform Engineering) ansatt av Red Hat, som vedlikeholder infrastrukturen for utvikling og publisering av Fedora- og CentOS-utgivelser.
Da vi evaluerte mulige løsninger for den nye Git Forge, så vi på:
Pagure og Gitlab. Basert på studien av omtrent og forespørsler fra deltakere i Fedora-, CentOS-, RHEL- og CPE-prosjektene, ble det formulert krav til funksjonalitet og et valg ble tatt til fordel for Gitlab. I tillegg til typiske operasjoner med repositorier (sammenslåing, oppretting av forks, legge til kode osv.), ble sikkerhet, brukervennlighet og stabilitet for plattformen erklært blant de viktigste kravene.
Kravene inkluderte funksjoner som HTTPS push, begrensning av tilgang til grener, støtte for private grener, separasjon av ekstern og intern brukertilgang (for eksempel for å jobbe med å fikse sårbarheter under en embargo mot å avsløre informasjon om problemet), kjennskap til grensesnittet, samling av delsystemer for arbeid med problemrapporter, kode, dokumentasjon og planlegging av nye funksjoner, tilgjengelighet av verktøy for IDE-integrasjon, støtte for typiske arbeidsflyter.
Blant GitLab-funksjonene som til slutt påvirket beslutningen om å velge denne plattformen, ble følgende nevnt: støtte for undergrupper med selektiv tilgang til repositorier, muligheten til å bruke en bot for automatiske sammenslåinger (krever CentOS Stream for å vedlikeholde kjernepakker), tilstedeværelsen av innebygde verktøy for planlegging av utvikling, muligheten til å bruke en ferdig SAAS-tjeneste med garantert tilgjengelighetsnivå (vil frigjøre ressurser for å vedlikeholde serverinfrastruktur).
Avgjørelsen er allerede tatt Kritikk blant utviklere knyttet til det faktum at avgjørelsen ble tatt uten forutgående bred diskusjon. Det var også bekymring for at tjenesten ikke ville bruke den gratis Community-utgaven av GitLab. Spesielt er funksjonene som er nødvendige for å implementere kravene til Git Forge beskrevet i kunngjøringen bare tilgjengelige i den proprietære versjonen. .
Det ble også reist kritikk mot intensjonen om å bruke SAAS-tjenesten (applikasjon som en tjeneste) levert av GitLab, i stedet for å distribuere GitLab på sine egne servere, noe som setter tjenesten ut av kontroll (for eksempel er det umulig å være sikker på at alle sårbarheter i systemet blir rettet raskt, infrastrukturen støttes, på et tidspunkt vil den ikke være det og sabotasje utført av personell fra et tredjepartsselskap er utelukket). Løsningen er heller ikke kompatibel med , som fastsetter at prosjektet skal prioritere gratis alternativer.
I mellomtiden, GitLab om implementeringer med åpen kildekode av 18 funksjonelle funksjoner som tidligere kun ble tilbudt i proprietære utgaver av GitLab. Funksjonene dekker ulike områder for håndtering av hele programvareutviklingssyklusen, inkludert utviklingsplanlegging, prosjektoppretting, verifisering, arbeid med pakker, utforming av utgivelser, konfigurasjon og sikkerhet.
Følgende funksjoner er overført til gratisfunksjonene:
- Vedlegg av relaterte problemer;
- Eksporter problemet fra GitLab til CSV;
- En modus for å planlegge, organisere og visualisere utviklingsprosessen for individuelle funksjoner eller utgivelser;
- Innebygd tjeneste for å koble prosjektdeltakere med tredjeparter via e-post.
- Webterminal for web-IDE;
- Mulighet til å synkronisere filer for å teste endringer i kode i webterminalen;
- Designadministrasjonsverktøy som lar deg laste opp mockups og ressurser til en utgave, og bruke utgaven som et enkelt tilgangspunkt til alt som trengs for å utvikle en ny funksjon;
- Rapporter om kodekvalitet;
- Støtte for pakkebehandlere for Conan (C/C++), Maven (Java), NPM (node.js) og NuGet (.NET);
- Støtte for canary-distribusjoner, som lar deg installere en ny versjon av et program på et lite delsett av systemer;
- Inkrementelle distribusjoner, som i utgangspunktet leverer nye versjoner til bare et lite antall systemer, og gradvis øker dekningen til 100 %;
- Funksjonalitetsaktiveringsflagg som tillater at prosjektet leveres i forskjellige utgaver ved dynamisk å aktivere bestemte funksjoner;
- En oversiktsmodus for distribusjoner som lar deg vurdere tilstanden til hvert Kubernetes-baserte kontinuerlige integrasjonsmiljø;
- Støtte for å definere flere Kubernetes-klynger i konfiguratoren (for eksempel kan du bruke separate Kubernetes-klynger for prøvedistribusjoner og produksjonsarbeidsbelastninger);
- Støtte for å definere sikkerhetspolicyer for containernettverk for å begrense tilgang mellom Kubernetes-poder.
I tillegg kan det bemerkes GitLab 12.9.1, 12.8.8 og 12.7.8 (Community Edition og Enterprise Edition)-oppdateringer, som retter opp sårbarheten. Problemet har vært tilstede siden utgivelsen av GitLab EE/CE 8.5 og tillater at innholdet i enhver lokal fil leses når et problem flyttes mellom prosjekter.
Detaljer om sårbarheten vil bli offentliggjort innen 30 dager.
Kilde: opennet.ru
