Il progetto CentOS ha annunciato il lancio di un servizio per lo sviluppo collaborativo, basato sulla piattaforma GitLab. La decisione di utilizzare GitLab come piattaforma primaria per l'hosting dei progetti CentOS e Fedora è stata presa lo scorso anno. È interessante notare che l'infrastruttura è stata sollevata non sui propri server, ma sulla base del servizio gitlab.com, dove è stata creata una sezione per i progetti legati a CentOS su gitlab.com/CentOS.
Attualmente si sta lavorando all'integrazione della sezione con la base utenti del progetto CentOS, il che consentirà agli sviluppatori di collegarsi al servizio GitLab usando gli account già esistenti. Si sottolinea inoltre che git.centos.org, basato sulla piattaforma Pagure, continuerà a essere considerato come luogo per l'archiviazione del codice sorgente dei pacchetti trasferiti da RHEL, nonché come base per la creazione del ramo CentOS Stream 8. Tuttavia, il ramo CentOS Stream 9 è già in fase di sviluppo su un nuovo repository in GitLab e permette la partecipazione allo sviluppo da parte dei membri della comunità. Altri progetti ospitati su git.centos.org rimangono al loro posto e non sono costretti a migrare.
I detrattori della transizione verso il modello SaaS, durante la discussione della decisione presa, hanno sottolineato che l'utilizzo di un servizio pronto fornito da GitLab non consente di controllare completamente l'infrastruttura; ad esempio, non si può essere certi che l'infrastruttura server sia adeguatamente mantenuta, che le vulnerabilità siano risolte tempestivamente, che venga imposta telemetria o che l'ambiente non sia stato compromesso a seguito di attacchi esterni o azioni di dipendenti disonesti.
Nella scelta della piattaforma, oltre alle operazioni standard sui repository (fusioni, creazione di fork, aggiunta di codice, ecc.), sono stati richiesti requisiti come la possibilità di inviare richieste push tramite HTTPS, strumenti per limitare l'accesso ai rami, supporto per rami privati, separazione dell'accesso per utenti esterni e interni (ad esempio, per lavorare sulla risoluzione di vulnerabilità durante un embargo sulla divulgazione delle informazioni sul problema), familiarità con l'interfaccia, unificazione dei sottosistemi per la gestione dei messaggi sui problemi, del codice, della documentazione e della pianificazione di nuove funzionalità, disponibilità di strumenti per l'integrazione con le IDE, supporto per flussi di lavoro standard e la possibilità di utilizzare un bot per fusioni automatiche (si richiede CentOS Stream per mantenere i pacchetti del kernel).
Fonte: opennet.ru
