els desenvolupadors que estan darrere dels projectes de les populars distribucions de Linux "CentOS i Fedora" van donar a conèixer recentment mitjançant un anunci la decisió de crear un servei de desenvolupament en conjunt, A el qual nomenat com "Git Forge".
Aquest nou servei es construirà utilitzant la plataforma GitLab que es convertirà en la plataforma principal per interactuar amb els repositoris de Git i per allotjar projectes relacionats amb les distribucions de CentOS i Fedora.
A l'avaluar les possibles solucions per al nou Git Forge, es van considerar Pagure i Gitlab. Basat en l'estudi d'aproximadament 300 revisions i suggeriments dels participants dels projectes Fedora, CentOS, RHEL i CPE, es van formar els requisits de funcionalitat i es va prendre la decisió a favor d'Gitlab.
A més de les operacions típiques amb repositoris, la seguretat, la usabilitat i l'estabilitat de la plataforma es van declarar entre els requisits clau.
Els requisits incloïen característiques tals com enviar sol·licituds push a través d'HTTPS, mitjans per restringir l'accés a versions, suport per a versions privades, compartir l'accés entre usuaris externs i interns (per exemple, per treballar en la reparació de vulnerabilitats durant l'embargament de revelar informació sobre un problema), unificació de subsistemes per treballar amb informes de problemes, codi, documentació i planificació de noves característiques, la disponibilitat d'eines per a la integració amb l'IDE, suport per a fluxos de treball típics.
Entre les característiques de GitLab que finalment van influir en la decisió de triar aquesta plataforma, es va esmentar el suport de subgrups amb accés selectiu a repositoris, la possibilitat d'usar un bot per a fusions automàtiques (Es requereix CentOS Stream per suportar paquets del nucli), la presència d'eines integrades per al desenvolupament de la planificació, la possibilitat d'usar un servei SAAS llest per a usar amb un nivell de disponibilitat garantit (alliberarà recursos per mantenir la infraestructura de servidor ).
La decisió ja ha causat crítiques entre els desenvolupadors, en relació amb el fet que la decisió es va prendre sense una discussió preliminar prèvia.
També va haver-hi preocupacions que el servei no faria servir l'edició Comminity gratuïta de GitLab. En particular, les capacitats necessàries per implementar els requisits de Git Forge descrits en l'anunci només estan disponibles en la versió patentada de GitLab Ultimate.
La intenció d'aprofitar el servei SAAS proveït per GitLab (aplicació com a servei) també va ser criticada, en lloc d'implementar GitLab en els seus servidors, el que descontrola el servei (per exemple, és impossible assegurar-se que totes les vulnerabilitats en el sistema es reparin ràpidament, la infraestructura es mantingui adequadament i no s'imposarà un sol moment de telemetria i es descartarà el sabotatge per part de personal de tercers).
La solució tampoc va bé amb els principis fonamentals de Fedora, que especifiquen que un projecte ha de donar preferència a alternatives gratuïtes.
Mentrestant, GitLab va anunciar l'obertura d'implementacions de 18 funcionalitats que abans només s'oferien en edicions de paga de GitLab:
- Adjuntant un problema relacionat;
- Problema d'exportació de GitLab a CSV.
- La manera de planificar, organitzar i visualitzar el procés de desenvolupament de funcionalitats o llançaments individuals.
- Servei incorporat per vincular participants de el projecte amb tercers mitjançant correu electrònic.
- Terminal web per IDE web.
- La capacitat de sincronitzar arxius per provar canvis en el codi en el terminal web.
- Dissenyi eines d'administració que li permetin carregar dissenys i recursos per al problema, utilitzant el problema com un únic punt d'accés a tot el que es requereix per desenvolupar una nova característica.
- Codi d'informes de qualitat.
- Suport per a gestors de paquets Conan (C / C ++), Maven (Java), NPM (NODE.JS) i NuGet (.NET).
- Suport per implementacions canàries, el que li permet instal·lar una nova versió de l'aplicació en una petita part de el sistema.
- Distribució incremental, permetent primer lliurar noves versions per només un petit nombre de sistemes, portant gradualment la cobertura a el 100%.
- Banderes d'activació de funcionalitat, que donen l'oportunitat de lliurar el projecte en diverses edicions, activant dinàmicament certes característiques.
- Mode d'implementació general que permet avaluar l'estat de cada entorn d'integració contínua basat en Kubernetes.
- Suport per a definir múltiples clústers d'Kubernetes al configurador
- Suport per definir polítiques de seguretat de la xarxa de contenidors que permeten diferenciar l'accés entre els pods de Kubernetes.
font: Bloc Centos - Bloc Fedora