Ir para o conteúdo

Políticas de Contribuição

Workflow

Master-Devel

Observações

No projeto Puma:

  • A develop é equivalente à dev
  • A master é equivalente à main

Develop e Master Branches

Ao invés de uma única branch master, esse fluxo de trabalho usa duas branches para registrar o histórico do projeto. A branch master armazena o histórico do lançamento oficial, e a branch develop serve como uma branch de integração para recursos. Também é conveniente marcar todos os commits na branch master com um número de versão.

A primeira etapa serve para complementar a branch master padrão com uma branch develop. Um jeito simples de alcançar esse resultado é com um desenvolvedor criando uma branch develop no local e fazendo o push para o servidor:

Feature Branches

Cada novo recurso deve residir em sua própria branch, que pode ser enviada ao repositório central para backup/colaboração. Mas, em vez de criar a branch da master, as branches de recursos usam a develop como seu branch pai. Quando um recurso é concluído, ele é mesclado de volta ao develop. Os recursos nunca devem interagir diretamente com o master.

Feature Branches

Criando Feature Branch

git checkout develop
git pull origin develop
git checkout -b feature_branch

Finalizando Feature Branch

Quando você terminar o trabalho de desenvolvimento do recurso, o próximo passo é mesclar o feature_branch em develop. Você deve então abrir um Pull Request de feature_branch para develop, que será revisado por um dos membros da equipe EPS.

Kanban

O ZenHub foi a ferramenta escolhida para auxiliar a equipe na condução do scrum, que utilizará sua funcionalidade de pipelines para fins rastreabilidade e transparência do trabalho a ser realizado na sprint.

As pipelines utilizadas serão:

  • Backlog - Todo o Backlog atualizado do produto.
  • Sprint Backlog - Issues/histórias que foram alocadas para a Sprint.
  • Ice Box - Issues/histórias que foram retiradas da coluna In Progress numa Sprint por algum motivo de força maior.
  • In Progress - Issues/Histórias sendo trabalhadas no momento.
  • Review - Necessário revisão de EPS.
  • Done - Issue/história concluída.

Assim que uma história técnica ou de usuário respeitar a definição de pronto acordada, e, caso possua testes unitários, e a build esteja passando, o responsável por ela abrirá um Pull Request, e assim que for revisado por um membro de EPS, que, caso aceite a história, ela poderá ser movida para done. Além disso, a cobertura de testes deverá estar em 90%.

Política de Issues

  • Issues em português.

Histórias de Usuário

  • Utilizar a(s) label(s) US.

Deve seguir o template abaixo:

  • Descrição

    • Deve seguir o formato:
    • Como [persona], eu [quero], [para que].

  • Critérios de Aceitação

    • Lista de critérios que precisam ser alcançados para que a User Story atenda os requisitos do usuário e seja aceita pelos POs.

  • Tarefas Técnicas

    • Lista de tarefas que indicam passos(a partir do ponto de vista técnico) para que a implementação da User Story seja concluída com êxito.

Melhorias

  • Utilizar a(s) label(s) ENHANCEMENT.

Deve seguir o template abaixo:

  • Descrição

    • Descrição da melhoria indicando quais aspectos serão aprimorados/atualizados.

  • Critérios de Aceitação

    • Lista de critérios que precisam ser alcançados para que a melhoria seja feita da maneira correta.

  • Tarefas Técnicas (Opcional)

    • Lista de tarefas que indicam passos(a partir do ponto de vista técnico) para que a melhoria seja concluída com êxito.

BUGs

  • Utilizar a(s) label(s) BUG.

Deve seguir o template abaixo:

  • Descrição

    • Descrição do BUG.
    • Passos para reproduzir o BUG.

  • Critérios de Aceitação

    • Lista de critérios que precisam ser alcançados para que o BUG seja considerado resolvido.

  • Tarefas Técnicas (Opcional)

    • Lista de tarefas que indicam passos(a partir do ponto de vista técnico) para que a solução do BUG seja concluída com êxito.

Definição de Done (DoD)

  • Critérios de Aceitação cumpridos;
  • Tarefas Técnicas, se houverem, concluídas.

Política de Branches

  • Branches em português.

  • A Branch deve ter uma TAG que faça referência ao problema que esta branch resolverá.

  • Exemplo:

Uma branch para a issue "#13 Validacao de Cadastro de Usuário" deve ser como:

git checkout -b 13-validacao_cadastro_usuario
  • Se o título da edição for muito grande, use apenas as primeiras palavras significativas para criá-la

Política de Commits

  • Commits em português

  • Um bom commit deve sempre ser capaz de completar a seguinte frase.

se aplicado, este commit irá [commit message]

  • Exemplo prático:
git commit -m Corrigir bug no formulário de cadastro de usuário
git commit -m Adicionar funcionalidade de correção de senha

Histórico de Versão

Data Versão Descrição Autores
02/03/2022 1.0 Criação do documento Eugênio Siqueira
14/03/2022 1.0 Adição do tópico política de issues Gustavo Nogueira

Referências