prosjekter и om beslutningen om å lage en samarbeidsutviklingstjeneste Git Forge, som skal bygges ved hjelp av GitLab-plattformen. GitLab vil bli den primære plattformen for å samhandle med Git-depoter og for å være vert for prosjekter relatert til CentOS- og Fedora-distribusjoner. Tidligere brukt tjeneste vil fortsette å eksistere, men vil bli overlatt til omsorg for et fellesskap som er interessert i fortsatt utvikling. Pagure vil bli fjernet fra støtten til CPE (Community Platform Engineering)-teamet ansatt hos Red Hat, som er engasjert i å vedlikeholde infrastrukturen for utvikling og publisering av Fedora og CentOS-utgivelser.
Når vi evaluerte mulige løsninger for den nye Git Forge, vurderte vi
Pagure og Gitlab. Basert på en studie av ca og ønsker fra deltakere i Fedora-, CentOS-, RHEL- og CPE-prosjektene, funksjonalitetskrav ble dannet og valget ble tatt til fordel for Gitlab. I tillegg til standardoperasjoner med repositories (sammenslåing, lage gafler, legge til kode osv.), ble sikkerhet, brukervennlighet og stabilitet på plattformen oppgitt blant nøkkelkravene.
Kravene inkluderte funksjoner som å sende push-forespørsler over HTTPS, midler for å begrense tilgangen til filialer, støtte for private filialer, adskillelse av tilgang for eksterne og interne brukere (for eksempel å jobbe med å eliminere sårbarheter under en embargo mot å avsløre informasjon om problemet) , familiaritetsgrensesnitt, forening av delsystemer for arbeid med problemrapporter, kode, dokumentasjon og planlegging av nye funksjoner, tilgjengelighet av verktøy for integrasjon med IDE, støtte for standard arbeidsflyter.
Av GitLab-funksjonene som til slutt påvirket beslutningen om å velge denne plattformen, ble det nevnt støtte for undergrupper med selektiv tilgang til repositories, muligheten til å bruke en bot for automatiske sammenslåinger (CentOS Stream kreves for å vedlikeholde pakker med kjernen), tilstedeværelse av innebygde verktøy for planlegging av utvikling, muligheten til å bruke en ferdig SAAS-tjeneste med garantert tilgjengelighetsnivå (vil frigjøre ressurser for vedlikehold av serverinfrastrukturen).
Avgjørelsen er allerede kritikk blant utbyggere på grunn av at avgjørelsen ble tatt uten omfattende forutgående diskusjon. Det ble også reist bekymring for at tjenesten ikke ville bruke den gratis Comminity-utgaven av GitLab. Spesielt funksjonene som er nødvendige for å implementere kravene for Git Forge beskrevet i kunngjøringen er kun tilgjengelig i den proprietære versjonen .
Intensjonen om å bruke SAAS-tjenesten (application as a service) levert av GitLab, i stedet for å distribuere GitLab på sine servere, ble også kritisert, noe som tar tjenesten ut av kontroll (det er for eksempel umulig å være sikker på at alle sårbarheter i systemet elimineres umiddelbart, infrastruktur vedlikeholdes, en dag blir det nei og sabotasje utført av personell i et tredjepartsselskap er utelukket). Løsningen fungerer heller ikke med , som spesifiserer at prosjektet skal gi fortrinn til gratis alternativer.
I mellomtiden, GitLab om oppdagelsen av implementeringer av 18 funksjoner som tidligere kun ble tilbudt i proprietære utgaver av GitLab. Mulighetene dekker ulike områder for å administrere hele programvareutviklingssyklusen, inkludert utviklingsplanlegging, prosjektoppretting, verifisering, pakkeadministrasjon, utgivelsesgenerering, konfigurasjon og sikkerhet.
Følgende funksjoner er overført til friområdet:
- Legger ved relatert problem;
- Eksporter problem fra GitLab til CSV;
- En måte å planlegge, organisere og visualisere utviklingsprosessen for individuell funksjonalitet eller utgivelser;
- Innebygd tjeneste for å koble prosjektdeltakere med tredjeparter ved hjelp av e-post.
- Webterminal for Web IDE;
- Evne til å synkronisere filer for å teste endringer i kode i webterminalen;
- Designkontroller som lar deg laste opp mockups og eiendeler til utstedelse, ved å bruke problemet som ett enkelt tilgangspunkt til alt du trenger for å utvikle en ny funksjon;
- Kode kvalitetsrapporter;
- Støtte for pakkeforvaltere Conan (C/C++), Maven (Java), NPM (node.js) og NuGet (.NET);
- Støtte for kanarie-utplasseringer, slik at du kan installere en ny versjon av applikasjonen på en liten del av systemene;
- Inkrementelle distribusjoner, som gjør at nye versjoner kan leveres til kun et lite antall systemer først, og øker gradvis dekningen til 100 %;
- Funksjonalitetsaktiveringsflagg, som gjør det mulig å levere prosjektet i ulike utgaver, dynamisk aktivere visse funksjoner;
- Oversiktsmodus for distribusjon, som lar deg vurdere tilstanden til hvert kontinuerlige integrasjonsmiljø basert på Kubernetes;
- Støtte for å definere flere Kubernetes-klynger i konfiguratoren (du kan for eksempel bruke separate Kubernetes-klynger for prøveimplementeringer og arbeidsbelastninger);
- Støtte for å definere sikkerhetspolicyer for containernettverk som lar deg begrense tilgangen mellom Kubernetes-poder.
I tillegg kan det bemerkes GitLab oppdaterer 12.9.1, 12.8.8 og 12.7.8 (Community Edition og Enterprise Edition), som fikser sårbarheten. Problemet har vært tilstede siden utgivelsen av GitLab EE/CE 8.5 og gjør at innholdet i enhver lokal fil kan leses når et problem flyttes mellom prosjekter.
Detaljer om sårbarheten vil bli offentliggjort etter 30 dager.
Kilde: opennet.ru