Proyectos y sobre la solución para crear el servicio de desarrollo colaborativo Git Forge, que se construirá utilizando la plataforma GitLab. GitLab será la plataforma principal para interactuar con los repositorios Git y para alojar proyectos relacionados con las distribuciones CentOS y Fedora. El servicio previamente utilizado continuará existiendo, pero será traspasado a la comunidad interesada en continuar con el desarrollo. Pagure será desconectado del soporte del equipo de CPE (Community Platform Engineering) empleado en Red Hat, que se encarga de mantener la infraestructura para el desarrollo y la publicación de las versiones de Fedora y CentOS.
Al evaluar posibles soluciones para el nuevo Git Forge, se consideraron
Pagure y GitLab. Con base en el estudio de alrededor de y solicitudes de los participantes de los proyectos Fedora, CentOS, RHEL y CPE, se formaron los requisitos funcionales y se eligió GitLab. Además de las operaciones típicas con repositorios (fusión, creación de forks, adición de código, etc.), se destacaron como requisitos clave la seguridad, la facilidad de uso y la estabilidad de la plataforma.
Entre los requisitos se incluyeron capacidades como el envío de pull requests por HTTPS, medios para restringir el acceso a ramas, soporte para ramas privadas, separación del acceso entre usuarios externos e internos (por ejemplo, para trabajar en la corrección de vulnerabilidades durante un embargo de divulgación), familiaridad en la interfaz, unificación de subsistemas para gestionar reportes de problemas, código, documentación y planificación de nuevas funcionalidades, y la disponibilidad de herramientas para integración con IDE, y soporte para flujos de trabajo típicos.
De las capacidades de GitLab que influyeron en la decisión final para elegir esta plataforma, se mencionaron el soporte para subgrupos con acceso selectivo a los repositorios, la posibilidad de utilizar un bot para fusiones automáticas (se requiere CentOS Stream para mantener los paquetes del núcleo), la disponibilidad de herramientas integradas para planificación del desarrollo, y la posibilidad de utilizar un servicio SAAS listo con un nivel garantizado de disponibilidad (lo que permitirá liberar recursos para mantener la infraestructura del servidor).
La decisión ya crítica entre los desarrolladores, relacionada con el hecho de que la decisión se tomó sin una amplia discusión previa. También se expresaron preocupaciones de que el servicio no utilizará la edición de Comminity libre de GitLab. En particular, las funcionalidades necesarias para implementar los requisitos descritos en el anuncio de Git Forge están disponibles únicamente en la versión propietaria. .
La crítica también se centró en la intención de aprovechar el servicio SAAS proporcionado por GitLab (aplicación como servicio), en lugar de implementar GitLab en sus propios servidores, lo que saca al servicio de su control (por ejemplo, no se puede tener la certeza de que todas las vulnerabilidades en el sistema se solucionen de manera oportuna, la infraestructura está soportada, en un buen momento no estará y excluida la posible intervención del personal de una empresa externa). La decisión también no se alinea con , que establecen que el proyecto debe dar preferencia a alternativas libres.
Mientras tanto, la empresa GitLab anunció la implementación de 18 funcionalidades que anteriormente solo se ofrecían en las ediciones propietarias de GitLab. Las funcionalidades abarcan diversas áreas de gestión del ciclo completo de desarrollo de software, incluyendo la planificación del desarrollo, creación de proyectos, verificación, gestión de paquetes, generación de lanzamientos, configuración y seguridad.
Entre las funcionalidades traducidas como libres se incluyen las siguientes:
- Adjuntar issues relacionadas;
- Exportar issues de GitLab a CSV;
- Modo de planificación, ordenación y visualización del proceso de desarrollo de funcionalidades o lanzamientos individuales;
- Servicio de soporte integrado para vincular a los participantes del proyecto con terceros a través de email.
- Terminal web para Web IDE;
- Opción de sincronizar archivos para probar cambios en el código en el terminal web;
- Herramientas de gestión de diseño que permiten cargar maquetas y recursos en issues, utilizando las issues como un único punto de acceso a todo lo necesario para el desarrollo de una nueva funcionalidad;
- Informes de calidad de código;
- Soporte para gestores de paquetes Conan (C/C++), Maven (Java), NPM (node.js) y NuGet (.NET);
- Soporte para despliegues canarios, que permiten instalar una nueva versión de la aplicación en una pequeña parte de los sistemas;
- Distribuciones incrementales que permiten entregar nuevas versiones inicialmente solo a un pequeño número de sistemas, ampliando gradualmente la cobertura hasta el 100%;
- Banderas de activación de funcionalidad que permiten entregar el proyecto en varias ediciones, activando dinámicamente ciertas funciones;
- Modo de revisión de implementaciones 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 (por ejemplo, se pueden usar clústeres Kubernetes separados para implementaciones de prueba y cargas de trabajo productivas);
- Soporte para definir políticas de seguridad de red en contenedores, que permiten restringir el acceso entre pods de Kubernetes.
También se puede destacar actualizaciones de GitLab 12.9.1, 12.8.8 y 12.7.8 (Community Edition y Enterprise Edition), que solucionan una vulnerabilidad. El problema aparece desde la versión GitLab EE/CE 8.5 y permite leer el contenido de cualquier archivo local al mover un issue entre proyectos.
Los detalles sobre la vulnerabilidad se revelarán en 30 días.
Fuente: opennet.ru
