Progetti и Riguardo alla decisione di creare il servizio di sviluppo collaborativo Git Forge, che sarà realizzato utilizzando la piattaforma GitLab. GitLab diventerà la piattaforma principale per interagire con i repository Git e per ospitare progetti relativi alle distribuzioni. CentOS e Fedora. Servizio precedentemente utilizzato continuerà ad esistere, ma verrà ceduto alla comunità interessata al suo continuo sviluppo. Pagure verrà rimosso dal team CPE (Community Platform Engineering) impiegato da Red Hat, che mantiene l'infrastruttura per lo sviluppo e la pubblicazione delle release di Fedora e CentOS.
Nel valutare le possibili soluzioni per il nuovo Git Forge, abbiamo preso in considerazione:
Pagure e Gitlab. Basato sullo studio di circa e auguri dai partecipanti al progetto Fedora, CentOSConsiderando i sistemi operativi RHEL e CPE, sono stati definiti i requisiti funzionali ed è stato scelto GitLab. Oltre alle operazioni standard di repository (merging, forking, aggiunta di codice, ecc.), tra i requisiti chiave figuravano la sicurezza, la facilità d'uso e la stabilità della piattaforma.
I requisiti includevano funzionalità quali push HTTPS, restrizione dell'accesso ai rami, supporto per rami privati, separazione dell'accesso utente esterno ed interno (ad esempio, per lavorare alla correzione delle vulnerabilità durante un embargo sulla divulgazione di informazioni sul problema), familiarità con l'interfaccia, unificazione dei sottosistemi per lavorare con report di problemi, codice, documentazione e pianificazione di nuove funzionalità, disponibilità di strumenti per l'integrazione IDE, supporto per flussi di lavoro tipici.
Tra le funzionalità di GitLab che hanno infine influenzato la decisione di scegliere questa piattaforma, sono state menzionate le seguenti: supporto per sottogruppi con accesso selettivo ai repository, la possibilità di utilizzare un bot per le unioni automatiche (richiede CentOS Stream per la manutenzione dei pacchetti del kernel), la presenza di strumenti integrati per la pianificazione dello sviluppo, la possibilità di utilizzare un servizio SAAS già pronto con un livello di disponibilità garantito (libererà risorse per la manutenzione dell'infrastruttura server).
La decisione è già presa Critiche tra gli sviluppatori legate al fatto che la decisione è stata presa senza un'ampia discussione preliminare. C'erano anche preoccupazioni sul fatto che il servizio non avrebbe utilizzato l'edizione gratuita Comminity di GitLab. In particolare, le funzionalità necessarie per implementare i requisiti di Git Forge descritti nell'annuncio sono disponibili solo nella versione proprietaria. .
Sono state sollevate critiche anche sull'intenzione di utilizzare il servizio SAAS (applicazione come servizio) fornito da GitLab, invece di distribuire GitLab sui propri server, il che rende il servizio fuori controllo (ad esempio, è impossibile essere sicuri che tutte le vulnerabilità del sistema vengano risolte tempestivamente, l'infrastruttura è supportata, a un certo punto non lo sarà e il sabotaggio da parte del personale di una società terza è escluso). La soluzione non è compatibile inoltre con , che stabiliscono che il progetto dovrebbe dare la preferenza alle alternative gratuite.
Nel frattempo, GitLab sulle implementazioni open source di 18 funzionalità precedentemente offerte solo nelle edizioni proprietarie di GitLab. Le funzionalità coprono diverse aree della gestione dell'intero ciclo di sviluppo del software, tra cui la pianificazione dello sviluppo, la creazione di progetti, la verifica, l'utilizzo dei pacchetti, la creazione di release, la configurazione e la sicurezza.
Le seguenti funzioni sono state trasferite a quelle gratuite:
- Allegare problemi correlati;
- Problema di esportazione da GitLab a CSV;
- Una modalità di pianificazione, organizzazione e visualizzazione del processo di sviluppo di singole funzionalità o versioni;
- Servizio integrato per mettere in contatto i partecipanti al progetto con terze parti tramite e-mail.
- Terminale Web per Web IDE;
- Possibilità di sincronizzare i file per testare le modifiche al codice nel terminale web;
- Strumenti di gestione della progettazione che consentono di caricare mockup e risorse in un problema, utilizzando il problema come unico punto di accesso a tutto il necessario per sviluppare una nuova funzionalità;
- Rapporti sulla qualità del codice;
- Supporto per i gestori di pacchetti Conan (C/C++), Maven (Java), NPM (node.js) e NuGet (.NET);
- Supporto per distribuzioni canary, che consentono di installare una nuova versione di un'applicazione su un piccolo sottoinsieme di sistemi;
- Distribuzioni incrementali, che inizialmente forniscono nuove versioni solo a un numero limitato di sistemi, aumentando gradualmente la copertura fino al 100%;
- Flag di attivazione delle funzionalità che consentono di distribuire il progetto in diverse edizioni attivando dinamicamente determinate funzionalità;
- Una modalità di panoramica per le distribuzioni che consente di valutare lo stato di integrità di ciascun 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 distribuzioni di prova e carichi di lavoro di produzione);
- Supporto per la definizione di policy di sicurezza della rete di container per limitare l'accesso tra i pod Kubernetes.
Inoltre si può notare Aggiornamenti di GitLab 12.9.1, 12.8.8 e 12.7.8 (Community Edition ed Enterprise Edition), che risolvono la vulnerabilità. Il problema è presente fin dal rilascio di GitLab EE/CE 8.5 e consente di leggere il contenuto di qualsiasi file locale durante lo spostamento di un issue tra progetti.
I dettagli della vulnerabilità saranno resi noti entro 30 giorni.
Fonte: opennet.ru
