O projeto CentOS anunciou o lançamento de um serviço de desenvolvimento colaborativo baseado na plataforma GitLab. A decisão de usar o GitLab como principal plataforma de hospedagem para projetos CentOS e Fedora foi tomada no ano passado. Vale ressaltar que a infraestrutura não foi construída em servidores próprios, mas com base no serviço gitlab.com, que disponibiliza uma seção gitlab.com/CentOS para projetos relacionados ao CentOS.
Atualmente, estão em andamento trabalhos para integrar a seção à base de usuários do projeto CentOS, o que permitirá aos desenvolvedores se conectar ao serviço Gitlab usando contas existentes. Observa-se separadamente que git.centos.org, baseado na plataforma Pagure, continuará a ser considerado como um local para hospedar o código-fonte dos pacotes transferidos do RHEL, bem como a base para a formação do CentOS Stream 8 branch. Mas o branch CentOS Stream 9 já está sendo desenvolvido com base no novo repositório no GitLab que se distingue pela capacidade de conectar membros da comunidade ao desenvolvimento. Outros projetos hospedados em git.centos.org permanecem em vigor por enquanto e não são forçados a migrar.
Durante a discussão da decisão, os oponentes da transição para o modelo SaaS observaram que a utilização de um serviço pronto fornecido pelo GitLab não permite o controle total da infraestrutura, por exemplo, é impossível ter certeza de que a infraestrutura do servidor seja mantido adequadamente, as vulnerabilidades sejam eliminadas prontamente e a telemetria e o ambiente não comecem a ser impostos, não foram comprometidos como resultado de um ataque externo ou de ações de funcionários desonestos.
Na escolha de uma plataforma, além das operações padrão com repositórios (mesclagem, criação de forks, adição de código, etc.), havia requisitos como capacidade de enviar solicitações push via HTTPS, meios de restringir o acesso a filiais, suporte para filiais privadas , separação de acesso de usuários externos e internos (por exemplo, para trabalhar na eliminação de vulnerabilidades durante um embargo de divulgação de informações sobre o problema), familiaridade da interface, unificação de subsistemas para trabalhar com relatórios de problemas, código, documentação e planejamento de novos recursos, disponibilidade de ferramentas para integração com IDE, suporte para fluxos de trabalho padrão, capacidade de usar um bot para mesclagens automáticas (requer CentOS Stream para suportar pacotes de kernel).
Fonte: opennet.ru