Padrões da Evológica

Versionamento de Sistemas

O padrão de versionamento utilizado pela empresa é:

Major.Minor.Revision.Build

Onde cada número é incrementado quando:

Major: 

Incrementado quando há uma alteração grande no sistema. Ex: refatoração de todo sistema, refatoração de uma integração que cause incompatibilidade com a versão anterior, subida da primeira versão do sistema para produção.

Minor: 

Incrementado quando há implementação de novas funcionalidades. 

Revision: 

Incrementado quando mudanças pequenas. Ex: alteração na visualização de um dado, alteração da cor de uma tela.

Build: 

Incrementado quando há um bugfix.

Para conhecimento:

Sobre versionamento 1

Semantic Versioning

Semantic Versioning com Imagens

 h1 {

 font-size: 20px;

 padding-top: 50px;

 }

 h2 {

 	text-decoration: underline;

 font-size: 18px;

 padding-top: 20px;

 }

Git flow - Evológica



Criação de branch

Padrão de Versionamento Git-flow

No diagrama abaixo, apresentamos um padrão de versionamento conhecido no mercado como git-flow. Este modelo foi concebido de maneira simples e direta com o intuito de exemplificar o fluxo de trabalho utilizando o git-flow. Vale ressaltar que ele pode ser incrementado com outros pontos do git-flow comumente utilizados no mercado.

Passo a Passo:

1 - Criação de uma Issue no GitLab

É criada uma issue no GitLab dentro do repositório, direcionando uma tarefa ao programador.

2 - Criação de uma Branch a partir da Issue

O programador, por sua vez, cria uma branch a partir da issue/demanda. A imagem abaixo mostra onde realizar a criação da branch a partir da issue, dentro da tela da própria issue.

3 - Criação de Branches para Tarefas Específicas

A partir da branch da issue/demanda, o programador cria uma branch para cada tarefa dentro da sua demanda principal. Exemplo: 542-SEGAUTO-RQ001, 542-SEGAUTO-RQ002, 542-SEGAUTO-RQ003.

4 - Merge Request (MR)

Depois que o desenvolvimento da tarefa é concluído, é feito um Merge Request (MR) da branch da tarefa para a branch da demanda que ele recebeu. Isso facilita a revisão do código, focando apenas na parte que foi alterada. A imagem abaixo é um exemplo de como definir a branch fonte (aquela que você vai criar o MR) e a branch de destino que receberá a solicitação de merge.

Os padrões para um merge request estarão em um tópico dedicado: Padrões de MR (Clique aqui)
Padrões para Merge Request (MR)

Padrões e Sugestões para Títulos e Descrições de Merge Requests

Ao criar um Merge Request (MR) dentro do fluxo git-flow, é crucial seguir padrões e fornecer informações claras para facilitar a revisão e aprovação do código. Aqui estão algumas sugestões:

Título do Merge Request:

O título deve ser conciso e informativo, fornecendo uma visão geral da alteração realizada. Sugestões de padrões incluem:

[Número da Issue] - Descrição Concisa da Tarefa

Exemplo: #542 - Implementação da Feature XYZ

[Tipo de Alteração] - Descrição da Alteração

Exemplo: Feature: Adiciona Autenticação de Usuário

Descrição do Merge Request:

A descrição é uma oportunidade para fornecer detalhes adicionais sobre a alteração. Inclua informações como:

Contexto da Alteração:

Explique por que essa alteração é necessária. Se relaciona a uma issue específica, mencione-a.

Lista de Mudanças:

Enumere as principais alterações realizadas. Isso ajuda os revisores a entenderem as diferenças no código.

Testes Realizados:

Descreva os testes que foram realizados para garantir a integridade da alteração.

Screenshots (se aplicável):

Inclua capturas de tela antes e depois, se a alteração afetar a interface do usuário.

Referências:

Adicione links para documentação relevante, discussões ou referências que possam auxiliar na compreensão da alteração.

Exemplo Prático:

Título do Merge Request:

#542 - Adiciona Funcionalidade de Pesquisa de Usuário

Descrição do Merge Request:

Contexto da Alteração:

Esta alteração atende à Issue #542, que solicitou a implementação de uma barra de pesquisa para facilitar a localização de usuários no sistema.

Lista de Mudanças:

Adição de barra de pesquisa na barra de navegação.

Atualização da lógica de busca no backend.

Testes Realizados:

Testes de unidade para a nova funcionalidade.

Testes de integração para garantir compatibilidade com outras partes do sistema.

Screenshots:

Screenshot da nova barra de pesquisa.

Referências:

Documentação da Issue #542.

Ao seguir essas sugestões, torna-se mais fácil para os revisores entenderem e avaliarem a proposta de alteração apresentada no Merge Request.