Projetos e sobre a solução para a criação do serviço colaborativo de desenvolvimento Git Forge, que será construído utilizando a plataforma GitLab. O GitLab se tornará a plataforma primária para interagir com repositórios Git e para hospedagem de projetos relacionados aos distribuições CentOS e Fedora. O serviço anteriormente utilizado continuará a existir, mas será transferido para a responsabilidade da comunidade interessada em continuar o desenvolvimento. O Pagure será desvinculado da equipe CPE (Community Platform Engineering) empregada na Red Hat, que é responsável pela manutenção da infraestrutura para desenvolvimento e publicação das versões do Fedora e CentOS.
Na avaliação das possíveis soluções para o novo Git Forge, foram considerados
Pagure e GitLab. Com base na análise de cerca de e sugestões dos participantes dos projetos Fedora, CentOS, RHEL e CPE, foram formulados requisitos funcionais e a escolha recaiu sobre o GitLab. Além das operações padrão com repositórios (mesclagem, criação de forks, adição de código etc.), entre os requisitos chave declarados estavam segurança, facilidade de uso e estabilidade da plataforma.
Os requisitos incluíram funcionalidades como envio de pull requests via HTTPS, ferramentas de controle de acesso a branches, suporte a branches privadas, separação de acesso entre usuários externos e internos (por exemplo, para trabalhar na correção de vulnerabilidades durante o embargo de divulgação de informações sobre o problema), familiaridade da interface, unificação de subsistemas para lidar com relatórios de problemas, código, documentação e planejamento de novas funcionalidades, e a presença de ferramentas de integração com IDEs, além do suporte a workflows padrão.
Das funcionalidades do GitLab que influenciaram a decisão pela escolha dessa plataforma, destacam-se o suporte a subgrupos com acesso seletivo a repositórios, a possibilidade de utilizar um bot para fusões automáticas (requer CentOS Stream para manter os pacotes com o kernel), a presença de ferramentas integradas para planejamento de desenvolvimento e a possibilidade de usar um serviço SAAS pronto com nível garantido de disponibilidade (o que permitirá liberar recursos para a manutenção da infraestrutura de servidores).
A decisão já críticas entre os desenvolvedores, relacionadas ao fato de que a decisão foi tomada sem discussão ampla prévia. Também foram expressas preocupações de que o serviço não utilizaria a edição Community do GitLab. Em particular, as funcionalidades necessárias para implementar os requisitos descritos no anúncio para o Git Forge estão disponíveis apenas na versão proprietária. .
A intenção de usar o serviço SAAS (software como serviço) fornecido pela GitLab também foi criticada, em vez de implantar o GitLab em seus próprios servidores, o que retira o serviço de seu controle (por exemplo, não é possível garantir que todas as vulnerabilidades no sistema sejam corrigidas prontamente. sustentada pela infraestrutura, em um determinado momento, não haverá e a possibilidade de uma intervenção por parte da equipe de uma empresa externa). A decisão também não está alinhada com , que estabelecem que o projeto deve priorizar alternativas livres.
Enquanto isso, a empresa GitLab anunciou a implementação de 18 funcionalidades que anteriormente eram oferecidas apenas nas edições proprietárias do GitLab. As funcionalidades abrangem diversas áreas de gestão do ciclo de desenvolvimento de software, incluindo planejamento de desenvolvimento, criação de projetos, verificação, trabalho com pacotes, formação de lançamentos, configuração e proteção.
As seguintes funções foram traduzidas para versões livres:
- Anexação de issues relacionadas;
- Exportação de issues do GitLab para CSV;
- Modo de planejamento, organização e visualização do processo de desenvolvimento de recursos funcionais ou lançamentos;
- Serviço de atendimento integrado para conectar os participantes do projeto a terceiros por meio de e-mail.
- Terminal Web para Web IDE;
- Capacidade de sincronizar arquivos para testar alterações no código no terminal web;
- Ferramentas de gestão de design que permitem carregar maquetes e recursos nas issues, usando as issues como um único ponto de acesso a tudo que é necessário para o desenvolvimento de uma nova funcionalidade;
- Relatórios de qualidade de código;
- Suporte a gerenciadores de pacotes Conan (C/C++), Maven (Java), NPM (node.js) e NuGet (.NET);
- Suporte a implantações canário, permitindo instalar uma nova versão do aplicativo em uma pequena parte dos sistemas;
- Distribuições incrementais que permitem entregar novas versões inicialmente para um pequeno número de sistemas, aumentando gradualmente a cobertura até 100%;
- Flags de ativação de funcionalidades que possibilitam fornecer o projeto em diferentes edições, ativando dinamicamente certas capacidades;
- Modo de visão geral das implantações, permitindo avaliar o estado de cada ambiente de integração contínua baseado no Kubernetes;
- Suporte à definição de múltiplos clusters Kubernetes no configurador (por exemplo, é possível utilizar clusters Kubernetes separados para implantações de teste e cargas de trabalho);
- Suporte à definição de políticas de segurança de rede para contêineres, permitindo restringir o acesso entre pods do Kubernetes.
Adicionalmente, pode-se destacar atualizações do GitLab 12.9.1, 12.8.8 e 12.7.8 (Edição Community e Edição Enterprise), nas quais uma vulnerabilidade foi corrigida. O problema se manifesta a partir do lançamento do GitLab EE/CE 8.5 e permite a leitura do conteúdo de qualquer arquivo local ao mover issues entre projetos.
Detalhes sobre a vulnerabilidade serão divulgados em 30 dias.
Fonte: opennet.ru
