Arquitetura do Sistema

Descrição

Esta seção irá abordar a arquitetura selecionada para o Backend e Frontend, além dos dados relativos ao deploy.

Sumário

• Arquitetura do Sistema
  • Descrição
  • Sumário
  • GitFlow
    • Instalação do Git
    • Git Branching Model
    • Padrões de Commit
    • Code Review
  • Arquitetura Geral da Aplicação
  • Deploy
    • Recipes API
    • Diagrama de Deploy
  • Backend
    • Definições de Tecnologias
    • Módulos do Sistema
    • Diagrama de Fluxo
  • Frontend
    • Definições de Tecnologias
    • Módulos do Sistema
    • Diagramas de Componentes
    • Diagrama do Sistema

GitFlow

Nas sessões abaixo será ensinado a instalação Git em sua máquina de acordo com seu sistema operacional, bem como a configuração de uma chave SSH que irá vincular seus repositórios locais com a sua conta do GitLab. Também, iremos discorrer a respeito do Gitflow adotado para o projeto e seu fluxo de desenvolvimento.

Instalação do Git

TBD

Git Branching Model

Utilizaremos o modelo de gestão de branches tradicional, realizando algumas adaptações. As alterações que faremos são:

• Não utilização de branches no modelo hotfix/*, visto que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente;
• Integração da branch de release/* com a branch de develop/*, com o propósito de unificar suas funcionalidades;

O desenvolvimento nos repositórios frontend e backend deverá seguir o fluxo descrito abaixo:

• 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/t01-login ou feature/t05-dropdown-list-login);
• 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 Discord (canal #code-review) que a task está pronta para review;
8. fim! 😸

Padrões de Commit

Quando realizar um commit, tente manter o seguinte padrão nas mensagens:

• título: número da task e breve descrição da mudança;
• se preciso, adicione um descrição mais longa da mudança, do porquê ela se faz necessária ou do porquê foi feito dessa forma; essa descrição longa deve estar separada do título por uma linha em branco;
• se mais de uma pessoa participou das mudanças do commit: indique a co-autoria conforme exemplo abaixo, também separada por uma linha em branco da descrição longa (o Git precisa de um formato bem específico nessa parte, com uma pessoa por linha; não é preciso adicionar uma linha para a pessoa que está fazendo o commit, porque o Git já pega isso automaticamente).

Exemplo:

#01: Tela de login

Criada tela de login e definida rotas, a construção do componente de seleção do perfil não faz parte dessa task.

Co-authored-by: Marcos Silva <[email protected]>

Code Review

Após o desenvolvimento de uma task, um pull/merge request (PR) deve ser aberto com destino à branch develop do repositório relativo à task: app ou api. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.

Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo que PRs abertos até dois dias antes de uma entrega serão integrados (se cumprirem todas as regras do code review).

Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:

• app:

• api:

Essas regras foram adicionadas como template de PR em cada projeto.

Arquitetura Geral da Aplicação

TBD

Deploy

Recipes API

TBD

Diagrama de Deploy

TBD

Backend

Definições de Tecnologias

• Java
• Spring Boot
• PostgreSQL

Módulos do Sistema

TBD

Diagrama de Fluxo

TBD

Frontend

Definições de Tecnologias

• Angular
• TypeScript

Módulos do Sistema

TBD

Diagramas de Componentes

TBD

Diagrama do Sistema

TBD