Processo de Desenvolvimento

Descrição

Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira que o time se organizou e trabalha.

Sumário

• Git Workflow
• Matriz de Responsabilidade
• Plano de Comunicação
• Plano de Riscos

Git Branching Model

O modelo de gestão das branches do Git é baseado no Git Flow "tradicional" com adaptações. Não é previsto o uso de branches hotfix/*, uma vez que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente.

O desenvolvimento nos repositórios devem seguir o fluxo de Git aqui definido:

• uma branch master com o código atualmente em produção;
• uma branch develop com o código em desenvolvimento, com funcionalidades finalizadas mas ainda em fase de testes para validação;
• feature branches para tasks relacionadas às user stories a serem desenvolvidas. Uma branch de task deve ser nomeada com o número único da task, seguida da breve descrição da task (por exemplo, feature/t06-login ou feature/t24-reports-ui);
• quando uma feature é finalizada, um PR da branch feature/ relacionada é aberto com destino à branch develop.

O código da develop é integrado com a master ao final da sprint, após validação dos stakeholders do que foi desenvolvido.

Dessa forma, o fluxo usual de trabalho é o seguinte:

1. antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch develop e pegar as últimas atualizações (pull);
2. criar uma branch para a task com o ID da task (feature/tXX-YYYYY);
3. "enviar" a branch para o remoto (git push -u origin feature/tXX-YYYYY);
4. desenvolver, commitar mudanças e atualizar o remoto (push);
5. voltar para o item 4 até finalizar a task;
6. abrir um PR com destino à branch develop;
7. mover o card da task no Trello para a lista Code Review e avisar no Slack (canal #code-review) que a task está pronta para review;
8. fim! 😃

Plano de Comunicação

Plano de Riscos