Progetti e sulla creazione di un servizio di sviluppo collaborativo Git Forge, che sarà costruito utilizzando la piattaforma GitLab. GitLab diventerà la piattaforma principale per interagire con i repository Git e per l'hosting di progetti legati alle distribuzioni CentOS e Fedora. Il servizio precedentemente utilizzato continuerà a esistere, ma sarà affidato alla comunità interessata a portare avanti lo sviluppo. Pagure sarà dismesso dalla supervisione della squadra di CPE (Community Platform Engineering) di Red Hat, che si occupa della manutenzione dell'infrastruttura per lo sviluppo e la pubblicazione delle versioni di Fedora e CentOS.
Nella valutazione delle possibili soluzioni per il nuovo Git Forge sono stati considerati
Pagure e GitLab. Sulla base dell'analisi di circa e richieste da parte dei partecipanti ai progetti Fedora, CentOS, RHEL e CPE, sono stati definiti i requisiti funzionali e si è optato per GitLab. Oltre alle operazioni standard con i repository (merge, creazione di fork, aggiunta di codice, ecc.), i requisiti chiave includevano sicurezza, facilità d'uso e stabilità della piattaforma.
Tra i requisiti vi sono funzionalità come l'invio di richieste push tramite HTTPS, strumenti di controllo degli accessi ai rami, supporto per rami privati, separazione dell'accesso tra utenti esterni e interni (ad esempio, per lavorare sulla risoluzione di vulnerabilità durante il periodo di embargo sulla divulgazione delle informazioni) e facilità d'uso dell'interfaccia, unificazione dei sottosistemi per la gestione di segnalazioni di problemi, codice, documentazione e pianificazione di nuove funzionalità, disponibilità di strumenti per integrazione con IDE e supporto per flussi di lavoro standard.
Tra le funzionalità di GitLab che hanno influenzato definitivamente la decisione di scegliere questa piattaforma, si citano il supporto per sottogruppi con accesso selettivo ai repository, la possibilità di utilizzare un bot per fusioni automatiche (richiede CentOS Stream per il mantenimento dei pacchetti col kernel), la presenza di strumenti integrati per la pianificazione dello sviluppo e la possibilità di utilizzare un servizio SAAS con un livello di disponibilità garantito (permette di liberare risorse per il mantenimento dell'infrastruttura server).
La decisione è già criticismo tra gli sviluppatori riguardante la decisione presa senza un ampio dibattito preliminare. Sono emerse anche preoccupazioni sul fatto che il servizio non utilizzerà la versione Community di GitLab. In particolare, le funzionalità necessarie per implementare i requisiti descritti nell'annuncio per Git Forge sono disponibili solo nella versione proprietaria. .
La critiche riguardano anche l'intenzione di utilizzare il servizio SAAS fornito da GitLab (applicazione come servizio), invece di implementare GitLab sui propri server, il che porta il servizio fuori dal controllo (ad esempio, non si può essere certi che tutte le vulnerabilità nel sistema vengano risolte prontamente. la infrastruttura sia mantenuta, e che ad un certo punto non ci sarà ed esclusa la possibilità di sabotaggio da parte del personale di terze parti). La decisione non è in linea con , che stabiliscono che il progetto deve privilegiare alternative libere.
Nel frattempo, GitLab sull'apertura di 18 funzionalità precedentemente offerte solo nelle versioni proprietary di GitLab. Queste funzionalità coprono vari aspetti della gestione dell'intero ciclo di sviluppo software, inclusi la pianificazione dello sviluppo, la creazione di progetti, la verifica, la gestione dei pacchetti, la generazione di rilasci, la configurazione e la sicurezza.
Le seguenti funzioni sono state rese disponibili gratuitamente:
- Collegamento di issue correlate;
- Esportazione delle issue da GitLab in CSV;
- Modalità di pianificazione, ordinamento e visualizzazione del processo di sviluppo di singole funzionalità o rilasci;
- Servizio integrato per collegare i membri del progetto a terze parti tramite email.
- Web terminal per Web IDE;
- Possibilità di sincronizzare i file per testare le modifiche al codice nel web terminal;
- Strumenti di gestione del design che consentono di caricare nei rilasci layout e risorse, utilizzando le issue come unico punto di accesso a tutto ciò che è necessario per sviluppare una nuova funzionalità;
- Report sulla qualità del codice;
- Supporto per i gestori di pacchetti Conan (C/C++), Maven (Java), NPM (node.js) e NuGet (.NET);
- Supporto per i deployment canary, che consentono di installare una nuova versione dell'applicazione su una piccola parte dei sistemi;
- Distribuzioni incrementali, che permettono inizialmente di consegnare nuove versioni solo a un numero ristretto di sistemi, ampliando gradualmente la copertura fino al 100%;
- Flag di attivazione delle funzionalità, che consentono di fornire il progetto in diverse edizioni, attivando dinamicamente determinate funzionalità;
- Modalità di revisione dei deployment, che consente di valutare lo stato di ogni ambiente di integrazione continua basato su Kubernetes;
- Supporto per la definizione di più cluster Kubernetes nel configuratore (ad esempio, è possibile utilizzare cluster Kubernetes separati per implementazioni di test e carichi di lavoro di produzione);
- Supporto per la definizione delle politiche di sicurezza di rete dei contenitori, che consentono di separare l'accesso tra i pod di Kubernetes.
Inoltre, si può notare aggiornamenti GitLab 12.9.1, 12.8.8 e 12.7.8 (Community Edition e Enterprise Edition), che risolvono una vulnerabilità. Il problema si manifesta a partire dal rilascio di GitLab EE/CE 8.5 e consente di leggere il contenuto di qualsiasi file locale durante lo spostamento di issue tra progetti.
I dettagli sulla vulnerabilità saranno rivelati tra 30 giorni.
Fonte: opennet.ru
