Fedora e CentOS executan Git Forge. GitLab abre 18 capacidades propietarias

Proxectos CentOS и Fedora сообщили sobre a decisión de crear un servizo de desenvolvemento colaborativo Git Forge, que se construirá utilizando a plataforma GitLab. GitLab converterase na plataforma principal para interactuar cos repositorios Git e para hospedar proxectos relacionados coas distribucións CentOS e Fedora. Servizo utilizado anteriormente Pagure seguirá existindo, pero será entregado ao coidado dunha comunidade interesada no desenvolvemento continuado. Pagure será eliminado do soporte do equipo CPE (Community Platform Engineering) empregado en Red Hat, que se dedica ao mantemento da infraestrutura para o desenvolvemento e publicación de versións de Fedora e CentOS.

Ao avaliar posibles solucións para o novo Git Forge, consideramos
Pagure e Gitlab. Baseado nun estudo de aproximadamente Comentarios de 300 e os desexos dos participantes nos proxectos Fedora, CentOS, RHEL e CPE, formáronse requisitos de funcionalidade e escolleuse a favor de Gitlab. Ademais das operacións estándar con repositorios (fusión, creación de bifurcacións, engade de código, etc.), entre os requisitos fundamentais figuraba a seguridade, a facilidade de uso e a estabilidade da plataforma.

Os requisitos incluían funcións como o envío de solicitudes push a través de HTTPS, medios para restrinxir o acceso a sucursais, soporte para sucursais privadas, separación de acceso para usuarios externos e internos (por exemplo, para traballar na eliminación de vulnerabilidades durante un embargo sobre a divulgación de información sobre o problema). , interface de familiaridade, unificación de subsistemas para traballar con informes de problemas, código, documentación e planificación de novas funcionalidades, dispoñibilidade de ferramentas para a integración con IDE, soporte para fluxos de traballo estándar.

Das capacidades de GitLab que finalmente influíron na decisión de escoller esta plataforma, menciónuse o soporte para subgrupos con acceso selectivo aos repositorios, a posibilidade de usar un bot para fusións automáticas (requírese CentOS Stream para manter os paquetes co núcleo), o presenza de ferramentas integradas para o desenvolvemento de planificación, a capacidade de usar un servizo SAAS preparado cun nivel de dispoñibilidade garantido (liberará recursos para manter a infraestrutura do servidor).

A decisión xa está causado críticas entre os desenvolvedores debido ao feito de que a decisión foi tomada sen unha extensa discusión previa. Tamén se manifestou a preocupación de que o servizo non utilizase a edición gratuíta de Comminity de GitLab. En particular, as capacidades necesarias para implementar os requisitos para Git Forge descritos no anuncio só están dispoñibles na versión propietaria. GitLab Ultimate.

Tamén se criticou a intención de utilizar o servizo SAAS (aplicación como servizo) que ofrece GitLab, en lugar de implantar GitLab nos seus servidores, o que descontrola o servizo (por exemplo, é imposible asegurarse de que todas as vulnerabilidades en o sistema son inmediatamente eliminados, correctamente mantense as infraestruturas, algún día non haberá telemetría imposta e exclúese a sabotaxe por parte do persoal dunha empresa allea). A solución tampouco funciona Principios fundacionais de Fedora, que especifican que o proxecto debe dar preferencia ás alternativas libres.

Mentres tanto, GitLab anunciou sobre o descubrimento de implementacións de 18 funcionalidades ofrecidas anteriormente só en edicións propietarias de GitLab. As capacidades abarcan varias áreas de xestión do ciclo completo de desenvolvemento de software, incluíndo planificación do desenvolvemento, creación de proxectos, verificación, xestión de paquetes, xeración de versións, configuración e seguridade.

As seguintes funcións foron transferidas ao rango libre:

  • Anexando cuestión relacionada;
  • Problema de exportación de GitLab a CSV;
  • Un modo de planificación, organización e visualización do proceso de desenvolvemento de funcionalidades individuais ou versións;
  • Servizo integrado para conectar os participantes do proxecto con terceiros mediante o correo electrónico.
  • Terminal web para Web IDE;
  • Capacidade de sincronizar ficheiros para probar cambios no código no terminal web;
  • Deseña controis que che permiten cargar maquetas e activos para emitir, utilizando issue como un único punto de acceso a todo o que necesitas para desenvolver unha nova función;
  • Informes de calidade do código;
  • Soporte para xestores de paquetes Conan (C/C++), Maven (Java), NPM (node.js) e NuGet (.NET);
  • Soporte para despregamentos canario, que lle permite instalar unha nova versión da aplicación nunha pequena parte dos sistemas;
  • Distribucións incrementais, que permiten que as novas versións sexan entregadas só a un pequeno número de sistemas nun primeiro momento, aumentando gradualmente a cobertura ata o 100 %;
  • Bandeiras de activación de funcionalidades, que permiten entregar o proxecto en varias edicións, activando dinámicamente determinadas características;
  • Modo de visión xeral do despregamento, que permite avaliar o estado de cada ambiente de integración continua baseado en Kubernetes;
  • Compatibilidade para definir varios clústeres de Kubernetes no configurador (por exemplo, pode usar clústeres de Kubernetes separados para implementacións de proba e cargas de traballo);
  • Compatibilidade para definir políticas de seguranza da rede de contedores que che permitan limitar o acceso entre os pods de Kubernetes.

Ademais, pódese sinalar publicación GitLab actualiza 12.9.1, 12.8.8 e 12.7.8 (Community Edition e Enterprise Edition), que corrixen a vulnerabilidade. O problema está presente desde o lanzamento de GitLab EE/CE 8.5 e permite ler o contido de calquera ficheiro local ao mover un problema entre proxectos.
Os detalles sobre a vulnerabilidade revelaranse despois de 30 días.

Fonte: opennet.ru

Engadir un comentario