Il progetto CentOS ha annunciato il lancio di un servizio di sviluppo collaborativo basato sulla piattaforma GitLab. La decisione di utilizzare GitLab come piattaforma di hosting principale per i progetti CentOS e Fedora è stata presa lo scorso anno. È interessante notare che l'infrastruttura non è stata costruita sui propri server, ma sulla base del servizio gitlab.com, che mette a disposizione una sezione gitlab.com/CentOS per i progetti relativi a CentOS.
Attualmente si sta lavorando per integrare la sezione con la base utenti del progetto CentOS, che consentirà agli sviluppatori di connettersi al servizio Gitlab utilizzando account esistenti. Si segnala separatamente che git.centos.org, basato sulla piattaforma Pagure, continuerà ad essere considerato come luogo in cui ospitare il codice sorgente dei pacchetti trasferiti da RHEL, nonché come base per la formazione del CentOS Stream 8 Ma il ramo CentOS Stream 9 è già in fase di sviluppo sulla base del nuovo repository in GitLab e si distingue per la capacità di connettere i membri della comunità allo sviluppo. Altri progetti ospitati su git.centos.org rimangono per ora attivi e non sono costretti a migrare.
Durante la discussione della decisione, gli oppositori del passaggio al modello SaaS hanno notato che l'uso del servizio già pronto fornito da GitLab non consente il controllo completo dell'infrastruttura, ad esempio è impossibile essere sicuri che l'infrastruttura del server viene mantenuto correttamente, le vulnerabilità vengono eliminate tempestivamente e la telemetria e l'ambiente non iniziano a essere compromessi a causa di un attacco esterno o delle azioni di dipendenti disonesti.
Quando si sceglie una piattaforma, oltre alle operazioni standard con i repository (unione, creazione di fork, aggiunta di codice, ecc.), c'erano requisiti come la possibilità di inviare richieste push tramite HTTPS, mezzi per limitare l'accesso alle filiali, supporto per filiali private , separazione dell'accesso per utenti esterni ed interni (ad esempio, per lavorare sull'eliminazione delle vulnerabilità durante un embargo sulla divulgazione di informazioni sul problema), familiarità dell'interfaccia, unificazione di sottosistemi per lavorare con segnalazioni di problemi, codice, documentazione e pianificazione di nuovi funzionalità, disponibilità di strumenti per l'integrazione con IDE, supporto per flussi di lavoro standard, possibilità di utilizzare un bot per unioni automatiche (richiede CentOS Stream per supportare i pacchetti del kernel).
Fonte: opennet.ru