Processo

Esta página descreve os processos utilizados pelo time ao longo do projeto.

Sumário

• Gestão do projeto
  • Gerenciamento do backlog do projeto
  • Boards criados
• Desenvolvimento
  • Fluxo de trabalho no Git
  • Práticas de CI/CD

Gestão do projeto

Como ferramenta para gerenciar o projeto e acompanhar o trabalho de cada uma das Sprints, optou-se por utilizar um Project do GitHub. O principal fator que levou a esta decisão foi o fato do GitHub ser a principal ferramenta que a equipe utilizou para hospedar os repositórios remotos do projeto e criar automações, dado que em semestres anteriores alguns membros da equipe haviam relatado muitos períodos de indisponibilidade ao utilizar apenas o GitLab da AGES. Assim, utilizando o GitHub para desenvolvimento e apenas mantendo um mirror daquele repositório no GitLab, faria sentido também centralizarmos o gerenciamento do trabalho das Sprints em um mesmo lugar para evitar o uso de múltiplas ferramentas diferentes.

Além disso, outro fator que levou ao uso do GitHub foi o fato de muitas ferramentas como Trello, Jira ou Azure DevOps terem funcionalidades pagas que a equipe não poderia utilizar.

Projeto do github criado

Gerenciamento do backlog do projeto

Para gerenciamento do backlog, criou-se 3 tipos diferentes de issues nos repositórios do project, identificadas por rótulos (epic, user story, feature, bugfix):

• Épicos (por exemplo Usuário)
• Histórias de usuário (por exemplo US3 Login) - sub issues dos épicos
• Tarefas (por exemplo Criar endpoint de login) - sub issues das histórias de usuário

Além disso, as histórias de usuário e tarefas seriam designadas a iteração específica em que cada uma delas estaria prevista de ser executada, construindo o backlog da Sprint. Para isso, foram criadas as iterações abaixo no projeto:

Cada uma das issues também poderia ser associada a uma prioridade (P0, P1, P2), a um tamanho (XS, S, M, L, XL), e a uma data de início a fim, como pode ser visto no exemplo abaixo. Estas 3 variáveis seriam definidas no momento da Planning em conjunto com todo o time, ao início de cada Sprint.

Boards criados

Quadro Kanban da Sprint atual

Quadro para acompanhamento do trabalho da Sprint atual de forma visual, onde cada coluna reflete uma atividade específica do fluxo de trabalho. Como colunas, definiu-se:

• Todo - Tarefas prontas para serem iniciadas
• Doing - Tarefas em desenvolvimento
• Blocked - Tarefas bloqueadas por outras ou por alguma outra dependência externa
• Code Review - Tarefas aguardando revisão
• Testing - Tarefas sendo testadas
• Done - Tarefas completas (segundo DoD)

Backlog do projeto

Visão completa do backlog do projeto, incluindo o trabalho de todas as Sprints, podendo ser filtrado pelo rótulo das issue. Possui as mesmas colunas do quadro da Sprint atual: Todo, Doing, Blocked, Code Review, Testing, Done.

Roadmap do projeto

Visão completa do cronograma do projeto, com os objetivos de desenvolvimento de cada iteração.

Desenvolvimento

Fluxo de trabalho no Git

Como modelo de fluxo de trabalho no Git iremos nos basear no Git Flow, para termos um maior controle sobre as alterações sendo realizadas no projeto, por meio de Merge Requests, e para conseguirmos lidar bem com muitas pessoas realizando alterações em um repositório ao mesmo tempo.

Branches

Neste modelo, cada repositório possui duas branches principais:

• dev - branch utilizada durante o desenvolvimento, onde todas as novas funcionalidades e correções que ainda não foram publicadas no ambiente de produção serão mescladas.
• main - branch cujo código é utilizado no ambiente de produção (APK), onde novas versões/releases serão mescladas quando estiverem prontas para serem publicadas.

Além disso, para realizar alterações no projeto, podem ser criados outros 2 tipos de branch:

• feature branch - branch criada a partir da develop para desenvolvimento de uma nova funcionalidade.
• fix branch - branch criada a partir da dev para desenvolvimento de correções de bugs.

Por padrão, o nome destas duas branches deve iniciar com o tipo de branch (feat/ ou fix/), seguido pelo identificador da User Story, e por fim o identificador da tarefa presente no board.

Exemplo: fix/US02-5

Commits

Para fins de padronização e melhor organização, utilizaremos Conventional Commits para mensagens de commits.

Como utilizar

A convenção segue o seguinte formato:

!type(?scope): !subject

Dessa maneira, ! indica os atributos obrigatórios e ? indica os atributos não obrigatórios.

• tipo de commit (type)
• o escopo/contexto do commit (scope)
• assunto/mensagem do commit (subject)

Subject: Imperativo ao invés de pretérito

Ao escrever subjects utilizando o imperativo nós estamos dizendo à nossa equipe o que fará o commit se aplicado.

Exemplo:

refactor: change the markup

Ou seja, "If applied, this commit will change the markup"

Type: Quais são os tipos de commit

O type é responsável por nos dizer qual o tipo de alteração ou iteração está sendo feita, das regras da convenção, temos os seguintes tipos:

• feat: indica o desenvolvimento de uma nova feature ao projeto. Exemplo: Acréscimo de um serviço, funcionalidade, endpoint, etc.
• fix: utilizado quando há correção de erros que estão gerando bugs no sistema. Exemplo: Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.
• refactor: usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema. Exemplo: Mudanças de código após um code review
• style: empregado quando há mudanças de formatação e estilo do código que não alteram o sistema de nenhuma forma. Exemplo: Mudar o style-guide, mudar de convenção lint, arrumar indentações, remover espaços em brancos, remover comentários, etc..
• chore: indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento. Exemplo: Mudar regras do eslint, adicionar prettier, adicionar mais extensões de arquivos ao .gitignore
• docs: usado quando há mudanças na documentação do projeto. Exemplo: adicionar informações na documentação da API, mudar o README, etc.
• build: utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas. Exemplo: Gulp, adicionar/remover dependências do npm, etc.
• perf: indica uma alteração que melhorou a performance do sistema. Exemplo: alterar ForEach por while, melhorar a query ao banco, etc.
• ci: utilizada para mudanças nos arquivos de configuração de CI. Exemplo: Circle, Travis, BrowserStack, etc.
• revert: indica a reverão de um commit anterior.
• test: indica qualquer tipo de criação ou alteração de códigos de teste. Exemplo: Criação de testes unitários.

Observações

• Só pode ser utilizado um type por commit;
• A diferença entre build e chore pode ser um tanto quanto sutil e pode gerar confusão, por isso devemos ficar atentos quanto ao tipo correto. No caso do Node.js por exemplo, podemos pensar que quando há uma adição/alteração de certa dependência de desenvolvimento presente em devDependencies, utilizamos o chore. Já para alterações/adições de dependências comuns aos projeto, e que haja impacto direto e real sobre o sistema, utilizamos o build.

Scope: contextualizando o commit

Em repositórios enormes, como monorepos, ou projetos com várias features e mudanças paralelas, não fica bastante claro até onde a mudança que irá chegar pode alterar. Para isso, podemos utilizar o escopo(scope) do commit.

Exemplo:

feat(UserService): add getAppointments endpoint

Desse modo é entendível que a mudança feita é no domínio do UserService.

Referências

• GitFlow
• Conventional Commits

Práticas de CI/CD

TODO