Projetos и sobre a decisão de criar um serviço de desenvolvimento colaborativo Git Forge, que será construído utilizando a plataforma GitLab. O GitLab se tornará a principal plataforma para interagir com repositórios Git e para hospedar projetos relacionados às distribuições CentOS e Fedora. Serviço usado anteriormente continuará a existir, mas será entregue aos cuidados de uma comunidade interessada no desenvolvimento contínuo. Pagure será afastado do suporte da equipe CPE (Community Platform Engineering) empregada na Red Hat, que se dedica à manutenção da infraestrutura para o desenvolvimento e publicação das versões Fedora e CentOS.
Ao avaliar possíveis soluções para o novo Git Forge, consideramos
Pagure e Gitlab. Com base em um estudo de cerca e desejos dos participantes dos projetos Fedora, CentOS, RHEL e CPE, foram formados requisitos de funcionalidade e a escolha foi feita em favor do Gitlab. Além das operações padrão com repositórios (fusão, criação de forks, adição de código, etc.), a segurança, a facilidade de uso e a estabilidade da plataforma foram apontadas entre os principais requisitos.
Os requisitos incluíam recursos como envio de solicitações push por HTTPS, meios de restrição de acesso a filiais, suporte para filiais privadas, separação de acesso para usuários externos e internos (por exemplo, para trabalhar na eliminação de vulnerabilidades durante um embargo à divulgação de informações sobre o problema) , interface de familiaridade, unificação de subsistemas para trabalhar com relatórios de problemas, código, documentação e planejamento de novas funcionalidades, disponibilidade de ferramentas para integração com IDE, suporte para fluxos de trabalho padrão.
Das capacidades do GitLab que acabaram por influenciar a decisão de escolha desta plataforma, foram mencionados o suporte a subgrupos com acesso seletivo aos repositórios, a capacidade de usar um bot para fusões automáticas (o CentOS Stream é necessário para manter pacotes com o kernel), o presença de ferramentas integradas para planejamento de desenvolvimento, possibilidade de utilização de um serviço SAAS pronto e com nível de disponibilidade garantido (liberará recursos para manutenção da infraestrutura de servidores).
A decisão já está críticas entre os desenvolvedores devido ao fato de a decisão ter sido tomada sem ampla discussão prévia. Também foram levantadas preocupações de que o serviço não usaria a edição Comminity gratuita do GitLab. Em particular, os recursos necessários para implementar os requisitos do Git Forge descritos no anúncio estão disponíveis apenas na versão proprietária .
Também foi criticada a intenção de utilizar o serviço SAAS (aplicação como serviço) fornecido pelo GitLab, em vez de implantar o GitLab em seus servidores, o que tira o serviço do controle (por exemplo, é impossível ter certeza de que todas as vulnerabilidades em o sistema é imediatamente eliminado, infraestrutura for mantida, um dia não haverá e a sabotagem por parte de pessoal de uma empresa terceirizada está excluída). A solução também não funciona com , que especifica que o projeto deve dar preferência a alternativas livres.
Enquanto isso, GitLab sobre a descoberta de implementações de 18 funcionalidades antes oferecidas apenas em edições proprietárias do GitLab. Os recursos abrangem diversas áreas de gerenciamento do ciclo completo de desenvolvimento de software, incluindo planejamento de desenvolvimento, criação de projetos, verificação, gerenciamento de pacotes, geração de releases, configuração e segurança.
As seguintes funções foram transferidas para o free range:
- Anexando problema relacionado;
- Problema de exportação do GitLab para CSV;
- Um modo de planejar, organizar e visualizar o processo de desenvolvimento de funcionalidades ou lançamentos individuais;
- Serviço integrado para conectar participantes do projeto com terceiros usando e-mail.
- Terminal Web para Web IDE;
- Capacidade de sincronizar arquivos para testar alterações no código no terminal web;
- Controles de design que permitem fazer upload de mockups e assets para emissão, usando a emissão como um ponto único de acesso a tudo que você precisa para desenvolver um novo recurso;
- Relatórios de qualidade de código;
- Suporte aos gerenciadores de pacotes Conan (C/C++), Maven (Java), NPM (node.js) e NuGet (.NET);
- Suporte para implantações canário, permitindo instalar uma nova versão da aplicação em uma pequena parte dos sistemas;
- Distribuições incrementais, permitindo que novas versões sejam entregues inicialmente apenas a um pequeno número de sistemas, aumentando gradualmente a cobertura até 100%;
- Flags de ativação de funcionalidades, que possibilitam entregar o projeto em diversas edições, ativando dinamicamente determinadas funcionalidades;
- Modo de visão geral de implantação, que permite avaliar o estado de cada ambiente de integração contínua baseado em Kubernetes;
- Suporte para definir vários clusters Kubernetes no configurador (por exemplo, você pode usar clusters Kubernetes separados para implementações de teste e cargas de trabalho);
- Suporte para definição de políticas de segurança de rede de contêineres que permitem limitar o acesso entre pods do Kubernetes.
Além disso, pode-se notar Atualizações do GitLab 12.9.1, 12.8.8 e 12.7.8 (Community Edition e Enterprise Edition), que corrigem a vulnerabilidade. O problema está presente desde o lançamento do GitLab EE/CE 8.5 e permite que o conteúdo de qualquer arquivo local seja lido ao mover um problema entre projetos.
Detalhes sobre a vulnerabilidade serão divulgados após 30 dias.
Fonte: opennet.ru