Padronização Git

Foi definido que o fluxo de branches utilizado para o desenvolvimento e manutenções de sistemas será uma adaptação do Git Flow.

O fluxo padrão do Git Flow é o apresentado na figura a seguir.

Com base no fluxo padrão do Git Flow teremos as seguintes adaptações:

• Não serão utilizadas branches release. O uso de branches release será avaliado posteriormente.
• Não será utilizada a branch develop em alguns sistemas onde existe um fluxo intenso de demandas urgentes, como por exemplo o eTCE-GO. Neste caso todas as branches serão criadas a partir da branch main. Posteriormente avaliaremos o uso da branch develop neste cenário.

Nomenclatura das branches:

• main​: branch principal e referência para implantação do produto de software em produção.​
• develop​: branch de desenvolvimento e referência para implantação do produto de software nos ambientes de teste e homologação.​
• feature/nome-da-nova-funcionalidade-ou-melhoria​: branch criada como espelho da develop e utilizada pelo desenvolvedor durante a codificação da nova funcionalidade ou melhoria de uma funcionalidade existente.​
• bugfix/identificação-do-bug​: branch criada como espelho da develop e utilizada pelo desenvolvedor durante a codificação da correção de bugs.​
• hotfix/identificação-do-bug​: branch criada como espelho da main e utilizada pelo desenvolvedor durante a codificação da correção de bugs que precisam ser corrigidos urgentemente.​
• tag​: marcação criada na branch main para identificar uma nova versão implantada em produção.​ Exemplo: 1.0.0​

Foi definido que será aplicado o versionamento semântico para todo produto de software desenvolvido e mantido pelo tribunal.

O padrão para a identificação de versão será como definido a seguir:

• MAJOR.MINOR.PATCH​
  • MAJOR: incrementado para grandes mudanças, mudanças incompatíveis com versões anteriores ou uma referência para um conjunto de mudanças.​
  • MINOR: incrementado para adicionar funcionalidades.​
  • PATCH: incrementado para correções de bugs.​
• Exemplos:
  • 1.0.0: primeira versão estável.​
  • 1.1.0: versão com novas funcionalidades compatíveis com a versão 1.0.0.​
  • 1.1.1: versão com correções de bugs compatíveis com a versão 1.1.0.​
  • 2.0.0: segunda versão com mudanças incompatíveis com a versão 1.0.0.

O changelog é um registro, em um documento padronizado, de todas as mudanças realizadas em um produto de software ao longo do tempo. Este serve como histórico de inclusão de novas funcionalidades, correções de bugs e demais manutenções realizadas no software.

Foi definido que deve ser criado um changelog para cada produto de software desenvolvido e mantido pelo tribunal. A cada novo incremento de versão o changelog deve ser atualizado.

O changelog será inicialmente armazenado no GitSource na raiz do projeto do produto de software. O nome do arquivo será changelog.md e será preenchido com o padrão Markdown.

Os seguintes dados devem estar contidos no changelog:

• Versão: ​ número da versão, por exemplo, 2.1.3.​
• Data:​ data da implantação da nova versão em produção.​
• Descrição das Mudanças: ​ uma lista detalhada das mudanças, organizadas pelas categorias a seguir.
  • Novas Funcionalidades: novas funcionalidades ou recursos incluídos.​
  • Correções: correções de bugs, problemas e defeitos.​
  • Alterações: mudanças em funcionalidades existentes.​
  • Melhorias: melhorias de usabilidade, desempenho, otimizações, etc.​
  • Remoções: funcionalidades ou recursos removidos.​
  • Segurança: correções de vulnerabilidades de segurança.

Exemplo de preenchimento: