Los desarrolladores que están detrás de los proyectos de las populares distribuciones de Linux “CentOS y Fedora” dieron a conocer recientemente mediante un anuncio la decisión de crear un servicio de desarrollo en conjunto, al cual nombrado como “Git Forge”.

Este nuevo servicio se construirá utilizando la plataforma GitLab que se convertirá en la plataforma principal para interactuar con los repositorios de Git y para alojar proyectos relacionados con las distribuciones de CentOS y Fedora.

Al evaluar las posibles soluciones para el nuevo Git Forge, se consideraron Pagure y Gitlab. Basado en el estudio de aproximadamente 300 revisiones y sugerencias de los participantes de los proyectos Fedora, CentOS, RHEL y CPE, se formaron los requisitos de funcionalidad y se tomó la decisión a favor de Gitlab.

Además de las operaciones típicas con repositorios, la seguridad, la usabilidad y la estabilidad de la plataforma se declararon entre los requisitos clave.

Los requisitos incluían características tales como enviar solicitudes push a través de HTTPS, medios para restringir el acceso a versiones, soporte para versiones privadas, compartir el acceso entre usuarios externos e internos (por ejemplo, para trabajar en la reparación de vulnerabilidades durante el embargo de revelar información sobre un problema), unificación de subsistemas para trabajar con informes de problemas, código, documentación y planificación de nuevas características, la disponibilidad de herramientas para la integración con el IDE, soporte para flujos de trabajo típicos.

Entre las características de GitLab que finalmente influyeron en la decisión de elegir esta plataforma, se mencionó el soporte de subgrupos con acceso selectivo a repositorios, la posibilidad de usar un bot para fusiones automáticas (se requiere CentOS Stream para soportar paquetes con el núcleo), la presencia de herramientas integradas para el desarrollo de la planificación, la posibilidad de usar un servicio SAAS listo para usar con un nivel de disponibilidad garantizado (liberará recursos para mantener la infraestructura del servidor).

La decisión ya ha causado críticas entre los desarrolladores, en relación con el hecho de que la decisión se tomó sin una discusión preliminar previa.

También hubo preocupaciones de que el servicio no usaría la edición Comminity gratuita de GitLab. En particular, las capacidades necesarias para implementar los requisitos de Git Forge descritos en el anuncio solo están disponibles en la versión patentada de GitLab Ultimate .

La intención de aprovechar el servicio SAAS provisto por GitLab (aplicación como servicio) también fue criticada, en lugar de implementar GitLab en sus servidores, lo que descontrola el servicio (por ejemplo, es imposible asegurarse de que todas las vulnerabilidades en el sistema se reparen rápidamente, la infraestructura se mantenga adecuadamente y no se impondrá un solo momento de telemetría y se descartará el sabotaje por parte de personal de terceros).

La solución tampoco va bien con los principios fundamentales de Fedora, que especifican que un proyecto debe dar preferencia a alternativas gratuitas.

Mientras tanto, GitLab anunció la apertura de implementaciones de 18 funcionalidades que antes solo se ofrecían en ediciones de paga de GitLab:

• Adjuntando un problema relacionado;
• Problema de exportación de GitLab a CSV.
• El modo de planificar, organizar y visualizar el proceso de desarrollo de funcionalidades o lanzamientos individuales.
• Servicio incorporado para vincular participantes del proyecto con terceros mediante correo electrónico.
• Terminal web para IDE web.
• La capacidad de sincronizar archivos para probar cambios en el código en el terminal web.
• Diseñe herramientas de administración que le permitan cargar diseños y recursos para el problema, utilizando el problema como un único punto de acceso a todo lo que se requiere para desarrollar una nueva característica.
• Código de informes de calidad.
• Soporte para gestores de paquetes Conan (C/C ++), Maven (Java), NPM (node.js) y NuGet (.NET).
• Soporte para implementaciones canarias, lo que le permite instalar una nueva versión de la aplicación en una pequeña parte del sistema.
• Distribución incremental, permitiendo primero entregar nuevas versiones para solo un pequeño número de sistemas, llevando gradualmente la cobertura al 100%.
• Banderas de activación de funcionalidad, que dan la oportunidad de entregar el proyecto en varias ediciones, activando dinámicamente ciertas características.
• Modo de implementación general que permite evaluar el estado de cada entorno de integración continua basado en Kubernetes.
• Soporte para definir múltiples clústeres de Kubernetes en el configurador
• Soporte para definir políticas de seguridad de la red de contenedores que permiten diferenciar el acceso entre los pods de Kubernetes.

Fuente: Blog Centos – Blog Fedora