Proyectos и sobre la decisión de crear un servicio de desarrollo colaborativo Git Forge, que se construirá utilizando la plataforma GitLab. GitLab se convertirá en la plataforma principal para interactuar con repositorios Git y alojar proyectos relacionados con distribuciones CentOS y Fedora. Servicio utilizado anteriormente seguirá existiendo, pero será entregado al cuidado de una comunidad interesada en su desarrollo continuo. Pagure dejará de recibir soporte del equipo CPE (Ingeniería de plataforma comunitaria) empleado en Red Hat, que se dedica a mantener la infraestructura para el desarrollo y publicación de las versiones de Fedora y CentOS.
Al evaluar posibles soluciones para el nuevo Git Forge, consideramos
Pagure y Gitlab. Basado en un estudio de aproximadamente y deseos de los participantes en los proyectos Fedora, CentOS, RHEL y CPE, se formaron requisitos de funcionalidad y se optó por Gitlab. Además de las operaciones estándar con repositorios (fusionar, crear bifurcaciones, agregar código, etc.), entre los requisitos clave se mencionaron la seguridad, la facilidad de uso y la estabilidad de la plataforma.
Los requisitos incluían características como el envío de solicitudes push a través de HTTPS, medios para restringir el acceso a sucursales, soporte para sucursales privadas, separación del acceso para usuarios externos e internos (por ejemplo, trabajar para eliminar vulnerabilidades durante un embargo sobre la divulgación de información sobre el problema). , interfaz de familiaridad, unificación de subsistemas para trabajar con informes de problemas, código, documentación y planificación de nuevas funciones, disponibilidad de herramientas para la integración con IDE, soporte para flujos de trabajo estándar.
De las capacidades de GitLab que finalmente influyeron en la decisión de elegir esta plataforma, se mencionó el soporte para subgrupos con acceso selectivo a los repositorios, la capacidad de usar un bot para fusiones automáticas (se requiere CentOS Stream para mantener los paquetes con el kernel), la presencia de herramientas integradas para planificar el desarrollo, la capacidad de utilizar un servicio SAAS listo para usar con un nivel garantizado de disponibilidad (liberará recursos para mantener la infraestructura del servidor).
La decisión ya está críticas entre los desarrolladores debido a que la decisión se tomó sin una discusión previa extensa. También surgieron preocupaciones de que el servicio no utilizaría la edición comunitaria gratuita de GitLab. En particular, las capacidades necesarias para implementar los requisitos para Git Forge descritos en el anuncio están disponibles solo en la versión propietaria. .
También se criticó la intención de utilizar el servicio SAAS (aplicación como servicio) proporcionado por GitLab, en lugar de implementar GitLab en sus servidores, lo que descontrola el servicio (por ejemplo, es imposible estar seguro de que todas las vulnerabilidades en el sistema se elimina rápidamente, Se mantiene la infraestructura, un día no habrá y se excluye el sabotaje por parte del personal de una tercera empresa). La solución tampoco funciona con , que especifican que el proyecto debe dar preferencia a alternativas libres.
Mientras tanto, GitLab sobre el descubrimiento de implementaciones de 18 funcionalidades que anteriormente se ofrecían solo en ediciones propietarias de GitLab. Las capacidades cubren varias áreas de gestión del ciclo completo de desarrollo de software, incluida la planificación del desarrollo, la creación de proyectos, la verificación, la gestión de paquetes, la generación de versiones, la configuración y la seguridad.
Se han transferido las siguientes funciones al campo libre:
- Adjuntar problema relacionado;
- Exportar problema de GitLab a CSV;
- Un modo de planificar, organizar y visualizar el proceso de desarrollo de funcionalidades o lanzamientos individuales;
- Servicio integrado para conectar a los participantes del proyecto con terceros mediante correo electrónico.
- Terminal web para IDE web;
- Capacidad de sincronizar archivos para probar cambios en el código en la terminal web;
- Diseñe controles que le permitan cargar maquetas y activos para emitir, utilizando el problema como un único punto de acceso a todo lo que necesita para desarrollar una nueva característica;
- Informes de calidad del código;
- Soporte para administradores de paquetes Conan (C/C++), Maven (Java), NPM (node.js) y NuGet (.NET);
- Soporte para implementaciones canary, lo que le permite instalar una nueva versión de la aplicación en una pequeña parte de los sistemas;
- Distribuciones incrementales, que permiten que las nuevas versiones se entreguen solo a una pequeña cantidad de sistemas al principio, aumentando gradualmente la cobertura hasta el 100%;
- Banderas de activación de funcionalidad, que permiten entregar el proyecto en varias ediciones, activando dinámicamente ciertas características;
- Modo de descripción general de la implementación, que le 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, puede usar clústeres de Kubernetes separados para implementaciones de prueba y cargas de trabajo);
- Soporte para definir políticas de seguridad de red de contenedores que le permiten limitar el acceso entre pods de Kubernetes.
Adicionalmente, se puede señalar Actualizaciones de GitLab 12.9.1, 12.8.8 y 12.7.8 (Community Edition y Enterprise Edition), que corrigen la vulnerabilidad. El problema ha estado presente desde el lanzamiento de GitLab EE/CE 8.5 y permite leer el contenido de cualquier archivo local al mover un problema entre proyectos.
Los detalles sobre la vulnerabilidad se revelarán después de 30 días.
Fuente: opennet.ru