Guia De Politica De Contribuicões

Histórico de Revisões

Data	Versão	Descrição	Autor
20/04/2018	1.0	Políticas	Thiago Pereira

---

1. Introdução
2. Políticas

---

1. Introdução

Este documento tem como objetivo padronizar e explicitar as políticas de contribuição a serem seguidas pela equipe durante o desenvolvimento do projeto.

2. Políticas

2.1 Política de Contribuição na Wiki

Com o intuito de manter a rastreabilidade e controle das alterações feitas na Wiki do projeto, o usuário que for adicionar ou modificar algum conteúdo deverá incluir uma pequena mensagem, no campo adequado, explicando a alteração feita. Esta mensagem deve estar em inglês com o verbo no gerúndio e o ponto final ao fim da frase.

Exemplo:

• “Adding policy guide.”

2.2 Política de Commits

Os commits devem ser atômicos, representando uma funcionalidade ou parte dela. A mensagem deve descrever o que foi produzido, de forma sucinta. Além disso, o commit deve ser iniciado com uma hash acompanhado do número, que representa a issue a qual esse commit pertence. Assim como a mensagem para contribuir na wiki, o commit deverá ser em inglês atendendo o seguinte padrão. < #Número da issue - Texto com a primeira letra da frase maiúscula, verbo no gerúndio, terminando com o ponto final. > .

Exemplo:

• “#2 - Adding user model.”
• "#17 - Creating user tests."

2.3 Política de Branches

Haverá apenas um repositório com uma branch principal (master) e uma branch auxiliar de desenvolvimento (devel). Será necessária a criação de branches auxiliares para o desenvolvimento de cada história de usuário ou história técnica, essas serão ramificações da devel. Após o término da funcionalidade, os desenvolvedores responsáveis deverão mesclar o conteúdo da branch auxiliar na qual a funcionalidade foi desenvolvida com a branch auxiliar de desenvolvimento (devel). Essa tarefa deve ser realizada com o comando merge. A funcionalidade deverá ser integrada a master através do pull request, onde o qualidade do código será analisada.

As branches auxiliares deverão ser criadas a partir do padrão a seguir: US<Número da User story>-<Descrição> ou TS<Número da Technical story>-<Descrição>. Onde US representa as histórias de usuário e TS histórias técnicas.

Exemplos:

• “US01-Login”
• "US07-FilterCompany"

2.4 Política de Aprovação do Código

O código será aprovado caso seja funcional e siga todas as especificações da folha de estilo com a aplicação das técnicas de programação, tais como: identação, presença de loggings, comentários, ou seja, o uso de programação defensiva. Além disso o código deverá conter uma cobertura de testes mínima determinada pelo time, assim como, satisfazer todos os requisitos das ferramentas de análise de código. O Scrum Master da sprint em questão deverá revisar o código presente em cada pull request. Caso não obedeça às regras e não seja explicado o não uso de uma das especificações estabelecidas acima o Scrum Master deverá recusar o pull request a branch master e voltar a branch devel para a última versão estável.