Ir para o conteúdo

Plano de Gerenciamento de Configuração de Software (GCS)

Histórico de Versão

Data Versão Descrição Autor
26/08/2020 1.0 Criação e Formatação do tópico 1 Rafael Makaha
14/10/2020 2.0 Criação e Formatação do tópico 2 Rafael Makaha e João Vítor

Sumário

1. Políticas de Repositório

1.1 Política de Commits

Adota-se para este projeto padrões para o comentário e execução dos commits. O idioma padrão para efetuar commits neste repositório é o inglês. As mensagens devem ser sucintas e expressarem de forma clara e objetiva a ação do commit.

Como exemplo, considere o trabalho da construção de uma tela inicial da aplicação. O commit deverá ser efetuado como segue:

git commit -m "Create new home Screen"

Atente ainda para os seguintes aspectos: * O commit deve iniciar com letras maiúsculas. * O commit deve iniciar com verbo no infinitivo. Exemplos:
-"Fix login auth error"
-"Create User model"
-"Refactor profile View"
-"Translate flat pages"

1.2 Política de Branches

O repositório possui uma branch master, que possui objetivo de manter a versão estável do projeto. Possui também uma branch para desenvolvimento chamada devel, cujo objetivo é manter-se atualizada. Desta forma nenhum commit deve ser efetuado diretamente nestas branchs. As alterações devem ser criadas inicialmente em branchs de funcionalidades ou de configuração e correção, toda branch de funcionalidade deve ser criada a partir da branch devel.

A imagem a seguir, ilustra como deve ser a organização das branchs e os eventos de criação e merge de acordo com o Git Flow.

Como pode ser visto, após a etapa de desenvolvimento em uma branch de funcionalidade ser concluída, deve ser submetido um pull request em caso de alguma revisão ou merge da mesma. O pull request deve ser conferido por um membro da equipe e se estiver em conformidade, então o pull request é aceito.

1.3 Padrão para criação e uso das branches

Deve-se criar novas branches para trabalho seguindo padrão GitFlow. Estas devem ser criadas a partir da branch develop, e devem seguir a nomenclatura padrão abaixo, redigidas no idioma inglês.

O código das branchs deve estar sincronizado com alguma Issue do repositório, sendo então o nome padrão para as branchs no formato:
i401_validate_username
i397_create_cluster_group

1.4 Automatização de Fechamento de Issue

Caso termine sua funcionalidade e deseje fechar a Issue automaticamente é possivel através das palavras chaves na descrição do commit ou pull request:
resolves: #numeroDaIssue
Em caso de múltiplas issues é necessário replicar o comando:
resolves: #numeroDaIssue
resolves: #numeroDaIssue2
resolves: #numeroDaIssue3

1.5 Pull Requests tempestivos e permanentes

Nesse projeto adotamos a política dos pull requests tempestivos e permanentes, ou seja, a partir do primeiro commit deve ser criado o pull request de merge da branch da issue com a develop. Esse pull request é, portanto, tempestivo - criado no primeiro commit - e permanente - permanece aberto enquanto o trabalho da issue estiver sendo executado. Além disso, sugere-se, para alterações no frontend, o envio também de prints ou gifs que ajudem a entender o trabalho realizado.

O autor do pull request deve assignar o grupo de revisão: https://github.com/orgs/ejplatform/teams/revision

1.6 Conflitos nos Pull Requests

A branch do PR deve estar sempre atualizado com a branch de desenvolvimento (develop) em caso de conflitos, deve-se realizar um rebase na branch com a develop

  • Exceções: commits que podem ser feitos diretamente na devel
  • Fix de conteúdo e css (não arquiteturais)
  • Tradução
  • Cobertura de teste
  • Atualizar assets
  • Commits de melhoramentos/bugfix de pipeline (que precisam ser commitados na branch do pipeline)

1.7 Validações de produto

As validações de produto acontecem motivadas pelos PRs do develop para a master. Sempre que um revisor fizer o merge dos PRs vindos das branches de issue pra develop, gera um PR correspondente pra master, acionando a validação de produto, focada na release.

2. Integração Contínua e Entrega Contínua

2.1. Integração Contínua

O projeto é composto por dois repositórios de códigos e um de documentação. Os repositórios de código são um backend - referente a API do projeto - e um frontend mobile.

Ambos respositórios utilizam a linguagem JavaScript para desenvolvimento. Mas se diferem nos frameworks utilizados, onde o backend utiliza NodeJS em conjunto com as bibliotecas de testes Jest e Supertest; e o frontend utiliza React Native em conjunto com as bibliotecas de testes Jest e Enzyme.

Será utilizado o Github Actions para a realização da Integração Contínua por meio do workflow disponível na ferramenta e sua facilidade de utilização.

2.2. Entrega Contínua

A Entrega Contínua é realizada, também, por meio do Github Actions. As alterações realizadas nas branches Develop e Master seguirão um fluxo de trabalho para a realização de uma Build de homologação e uma Build de Produção, respectivamente.

2.3. Pipeline