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

TBD

Code Review

TBD

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