GitLab Community Edition

De Open Source Software
Gitlab logo.png

GitLab é um Gerenciador de Repositórios de software baseado em Git, o qual dispõem de suporte a Wiki, Gerenciamento de Tarefas, Rastreamento de Issues, além de Integração Contínua e Entrega Contínua. É um produto Open Source para ganho de produtividade, da empresa GitLab B.V., disponibilizado sob Licença MIT, similar ao GitHub, porém com a possibilidade armazenamento dos projetos em servidores próprios..


[1]A primeira versão foi disponibilizada no ano de 2011 pelo engenheiro ucraniano Dmitriy Zaporozhets, no ano seguinte já havia centenas de inscrições para utilizar a versão beta, quando foi lançada a primeira versão do GitLab. Em 2013 o cientista holandês Sytse Sijbrandij se une à Dmitriy Zaporozhets no desenvolvimento do projeto GitLab, onde, em 22 de Julho de 2013 dividem o projeto em dois produtos:


Essa divisão foi realizada para atender às solicitações de recursos solicitadas por grandes corporações que aderiram ao uso do GitLab[2]. No ano de 2016 o GitLab já estava contava com uma equipe com mais de 140 funcionários e já havia sido implantado em mais de 100.000 organizações.

Atualmente a equipe de desenvolvimento do projeto GitLab conta com 962 membros, que podem ser verificados em Equipe GitLab.


Licença de Uso

Em fevereiro de 2014 a licença da versão Enterprise foi alterada de Licença Open Source para uma licença proprietária, elaborada pelo GitLab.com, com a finalidade de proteger os direitos autorais dos desenvolvedores. Essa alteração ocorreu pois, segundo GitLab, o modelo de Licença OpenSource combinada com uma assinatura obrigatória poderia ser confusa para possíveis assinantes. Com essa mudança foi possível formalizar e garantir que organizações tenham uma assinatura válida ao usar a Enterprise Edition.


Licença Proprietária

Podem ser verificadas os seguintes tipo de licença no produto GitLab:

  • Creative Commons CC BY-SA 4.0 License: Aplicada para todo conteúdo no repositório do projeto.
  • ee/LICENSE: Aplicada para todo conteúdo dentro do diretório “ee/”, caso exista.
  • MIT Expat License: Aplicada para todo conteúdo client-side JavaScritp, quando utilizado diretamente, ou após ser compilado, organizado, incrementado, ou combinado.
  • Licença Proprietária: Aplicada para todo conteúdo de terceiros incorporado ao Software GitLab, para cada um dos componente utilizados.
  • MIT Expat License: Aplicado para todo conteúdo fora dos diretórios mencionados, ou das restrições descritas.


A empresa GitLab Inc. decidiu por implementar o modelo de negócio com código fonte aberto e código fonte proprietário pois, para continuarem com o projeto precisavam de uma fonte de renda recorrente.

Quando a comunidade contribui com uma feature, no merge request deve ser utilizado uma label para indicar se desejam que a feature seja disponibilizada na versão Open Source ou na Enterprise Edition (Versão Paga). Quando a feature é desenvolvida exclusivamente pela equipe principal do GitLab, são avaliados quais seriam os possíveis compradores para determinar se a mesma será disponibilizada em na versão paga ou aberta. A equipe do GitLab também utiliza o feedback da comunidade para decidir quando é necessário incluir alguma alteração da versão Enterprise na versão de Aberta[3].

O produto GitLab pode ser adquirindo sob os seguintes formatos:


Pricing GitLab.jpg


Contribuindo com o Projeto GitLab

É possível contribuir com o projeto das seguintes formas:

  • Organizando encontros;
  • Gravando vídeos demonstrativos para o YouTube;
  • Realizando palestras em conferências ou eventos;
  • Escrevendo em blogs técnicos;
  • Desenvolvendo o Código-Fonte;
  • Documentando o Código-Fonte;
  • Traduzindo a ferramenta;
  • Colaborando com o Aperfeiçoamento de Uso (User Experience).


Os usuários que estiverem dispostos a contribuir com o projeto deverão seguir o código de conduta disponível em Código de Conduta GitLab.

Para contribuir com o desenvolvimento do código-fonte é necessário preparar o ambiente para desenvolvimento GitLab Development Kit.


Contribuindo com Desenvolvimento

Seja corrigindo bugs, adicionando novos recursos, ajudando nas revisões, o GitLab é uma ótima comunidade de código aberto para desenvolvedores de todas as origens. Muitos começaram a contribuir para o desenvolvimento do GitLab sem estar familiarizado com linguagens como Ruby.


Contribuindo com Documentação

Contribuir com a documentação é uma ótima maneira de se familiarizar com o processo de desenvolvimento do GitLab e conhecer revisores e outros membros da comunidade. Desde a correção de erros de digitação até a melhorar a organização da documentação, é possível encontrará muitas áreas onde contribuir.


Contribuindo com Tradução

O GitLab está sendo traduzido para mais de 35 idiomas, e isso também é impulsionado por membros mais amplos da comunidade. Atualmente a comunidade conta com mais de 1500 membros que estão contribuindo com a tradução do GitLab.


Contribuindo com Design UX

Para ajudar a tornar produto mais fácil de usar existe um grupo diversificado de pessoas trabalhando para isso. É possível ajudar a entender melhor como o usuário utiliza o GitLab e suas necessidades, ao trabalhar com os membros da equipe do GitLab UX.


Dinâmica de Funcionamento do Projeto

Toda alteração é implementada por meio da aceitação de um Merge Request. Quando um membro contribui com o projeto através de um Merge Request, a equipe de desenvolvimento irá revisar as alterações solicitadas, as quais poderão ser rejeitadas. A equipe de desenvolvimento pode conversar entre si para tomarem a decisão, e, em caso de rejeição, os motivos são divulgados.

Se a qualidade do código não atender os padrões do GitLab, o responsável pela aceitação do Merge Request fornecerá orientações para que o contribuidor acesse os documentos guias de estilo de código. Se o código não possuir integridade estrutural, o contribuidor será relatado e poderá receber instruções para melhorias que, depois de executadas, poderá gerar uma atualização e nova solicitação de Merge Request.

Se uma alteração for enviada diversas vezes, a solicitação pode ser encerrada pelo responsável da equipe de desenvolvimento, o qual disponibilizará um resumo pelo qual não está aceitando a solicitação, e o mesmo ficará à disposição para discutir o assunto.

As contribuições da comunidade são revisadas diariamente, porém, se a resposta para uma requisição demorar mais de dois dias, o mesmo pode ser enviado novamente mencionando um possível editor que seja mais adequado para revisar a alteração realizada. Nos casos onde haja diversas alterações, que podem ser atribuídas a diferentes revisores, todos eles podem ser mencionados no Merge Request.

Quando for utilizada alguma biblioteca externa, deverá ser fornecido um link para a biblioteca e uma justificativa para incluí-la.


Detecção de Novas Funcionalidades

O usuário que realizar o desenvolvimento de novas funcionalidades deve atualizar a documentação e submetê-la no mesmo Merge Request que as alterações.

A documentação das novas funcionalidades devem seguir o padrão disponível em Padrão Documentação, a qual deve ser marcada com a label “Documentation”.

Todas funcionalidades implementadas podem ser verificadas através da documentação do projeto, a qual é um documento único e tido como única fonte da verdade (Single Source of Truth - SSOT) .



Casos de Testes

Os padrões para elaboração de casos de testes para novas features, ou alterações, no projeto GitLab pode ser consultada em Padrões de Testes[4].

A maior parte do projeto GitLab é escrita em Ruby on Rails, por isso é utilizado RSpec para execução de todos os testes de backend, para os testes de integração de ponta-a-ponta é utilizado Capybara. Os testes unitários e de integração na parte frontend é realizada com as ferramentas Jest, Karma e Jasmine.

Detalhes de como elaborar os testes podem ser verificados em Testing, onde também é disponibilizado o seguinte exemplo de Teste Unitário[5]:


ExemploTesteUnitario GitLab.jpg


Na documentação podem ser consultados exemplos de como aplicar os casos de testes com as ferramentas utilizadas e quando deve ou não ser utilizado determinado tipo de teste, como por exemplo, o uso de teste unitário é recomendado quando é necessário exportar uma função ou classe que será utilizada em outras partes onde talvez não possam ser controladas, por isso é necessário documentar o comportamento esperado através de testes[6].


Comunidade GitLab

O projeto GitLab conta com uma equipe principal composta atualmente por nove membros, selecionados devido às contribuições significativas que realizam no projeto. Os membros dessa equipe podem convidar um participante da comunidade a se tornar membro da equipe principal, esse participante deverá receber pelo menos dois votos positivos, e nenhuma objeção, pelos demais membros da equipe principal.

A equipe principal de desenvolvimento do projeto GitLab pode ser consultada em Equipe Principal[7].

Com as contribuições e engajamento no projeto os membros podem atingir os níveis descritos a seguir.


  • Contribuinte:
    • Realizar 5 merges não triviais;
    • Iniciar um grupo de reunião;
    • Realizar palestras técnicas sobre o GitLab;
    • Publicar 3 vezes em blogs sobre o GitLab.
  • Herói:
    • Realizar 10 merges não triviais;
    • Organizar 8 eventos de reunião do GitLab por ano;
    • Apresentar o GitLab em uma conferência regional;
    • Publicar 5 vídeos no YouTube sobre o GitLab.
  • Super-Herói:
    • Participar da equipe principal de desenvolvimento;
    • Organizar 12 reuniões do GitLab por ano;
    • Realizar uma palestra sobre o GitLab em uma conferência global;
    • Publicar um artigo ou vídeo sobre o GitLab com mais de 100 mil.


A comunidade de desenvolvimento do GitLab possui, atualmente, 6327 membros inscritos, dos quais 6069 são de contas públicas e 258 de contas privadas. Os membros com maiores contribuições ao longo do ano de 2018, pode ser consultada em Lista Maiores COntribuições 2018[8].

Em Outubro de 2019 o projeto acumula um total de 7253 Merge Request, realizados por 2589 contribuidores.

A seguir pode ser observado um comparativo entre as contribuições realizadas pela comunidade em relação às contribuições realizadas pela equipe principal, nas últimas versões disponibilizadas.


Comparativo Contribuicoes GitLab.jpg


Ecossistema GitLab

O ecossistema GitLab tem como missão promover o projeto não apenas como um produto individual, mas sim como um plataforma, para muito além do que é hoje, apesar de procurar desenvolver recursos nativos na própia plataforma, utiliza-se de parcerias com outros serviços, destacando as vantagens significativas nas associações à integração de outras tecnologias.

Parcerias para integração de ferramentas podem ser solicitadas com Mayank Tahilramani.

Parcerias de Integração GitLab

A seguir são apresentas as atuais parcerias integradas com o projeto GitLab.


Princípios da Equipe

O GitLab busca aplicar os princípios descritos a seguir, visando um sistema de gerenciamento que funcione para todos[9]:

  • Esforçar para aumentar a competência média da equipe a cada novo contratado;
  • Incentivar o feedback e reconhecer os funcionários como seres humanos e não apenas recursos;
  • Investir constantemente no desenvolvimento de habilidades e crescimento da equipe;
  • Conversar com os clientes;
  • Começar pelo problema e não pela solução;
  • Concentrar nas necessidades dos clientes, mantendo a simplicidade;
  • Suponha que você esteja errado;
  • Aproveite processos de feddback ao invés de tentar planejar tudo de uma vez;
  • Utilize métricas de sucesso.


Comunicação

Após se inscrever como membro, o usuário deve ler cuidadosamente o guia geral da comunidade, onde poderá obter as mais variadas informações sobre o produto, a comunidade, instruções de como proceder em determinadas situações, como disponibilizar alterações, descrição dos processos do GitLab, dentre outros assuntos.

O GitLab utiliza Rastreador de Issues, onde são relatados os problemas em abertos e já finalizados, conforme pode ser observado a seguir.


Rastreador Issues GitLab.jpg


Através das issues os membros podem se comunicar, descrevendo o problema identificado, a proposta de solução e discutirem sobre o assunto, conforme pode ser observado a seguir.



Issue GitLab.jpg


A equipe do GitLab mantém contato com comunidade através de conferências, Twitter, Reddit, Hacker News, através dos canais de discussão do GitLab, no Slack[10].

As principais conferências onde normalmente participam representantes do GitLab são:


O GitLab também possui uma comunidade de discussão no Gitter, a qual está integrada para receber notificações de mudanças no projeto GitLab, conforme pode ser observado a seguir.


Gitter GitLab.jpg


Influências

O projeto GitLab é inspirado em projetos sólidos que demonstraram sucesso como Salesforce, Shopify, Twilio, Stripe e GitHub.



Processos de Engenharia de Software



É possível adquirir o GitLab diretamente pelo site, a princípio o cliente poderá testar por 30 dias, e posteriormente adquirir os planos que seguem as modalidades “Livre”, “Bronze”, “Prata” e “Ouro”. Os preços são variados de acordo com a categoria, sendo a modalidade “Livre”, distribuída gratuitamente. Cada modalidade oferece recursos diferentes umas das outras.


Todas as solicitações de mesclagem do projeto requerem as seguintes aprovações antes de sua conclusão:
Vice-presidente de produto
Diretor de Experiência do Usuário

As seguintes pessoas precisam estar na solicitação de mesclagem para se manterem informadas:
Diretor Sênior de Desenvolvimento
Diretor de Qualidade


O fluxo de desenvolvimento do projeto GitLab seguem duas grandes etapas, sendo estas, subdivididas em processos para garantir a qualidade do produto final.
A primeira etapa é chamada de “Faixas de Validação, tendo como processos:
- lista de pendências de validação
- validação do problema
- validação da solução

A segunda etapa é chamada de “Criação de Trilhas”, onde é desenvolvido, lançadas soluções melhores ao longo do tempo, tendo como processos:
- planejamento
- desenvolvimento e teste
- lançamento
- melhorias


A missão do GitLab é criar produtos e experiências consistentes que os usuários amem e valorizem. Para cumprir essa missão, foi criando fluxos de trabalho claramente definido e repetível para transformar uma ideia em algo que ofereça valor ao cliente. É possível entender melhor o fluxo de desenvolvimento do produto, acessando aqui.