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
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
Download
Faça o download e instale o Git a partir deste link, selecionando seu sistema operacional: aqui.
Ao final da instalação, abra o Git Bash (caso esteja usando Windows) ou um terminal e digite git –version
. Ao retornar a versão do Git, significa que a instalação foi bem sucedida.
Nota: Usuários de Linux e Mac já possuem o Git nativamente. Para verificar, abra um terminal e digite git –version
. Caso retorne a versão do Git, significa que o mesmo está devidamente instalado em sua máquina.
Configuração Git e GitLab
Abaixo será ensinado algumas configurações iniciais do Git, bem como o vínculo do seu ambiente local com o GitLab via SSH.
Configurações Iniciais
Caso esteja utilizando o Git pela primeira vez, rode os comandos abaixo para configurar, respectivamente, seu nome e seu email. Substitua os valores entre aspas pelos seus dados.
- git config --global user.name "${YOUR_FULL_NAME}"
- git config --global user.email "${YOUR_EMAIL}"
Configurando uma chave SSH
Passo 1: Gerando a chave SSH
Abra um terminal e digite o comando abaixo:
ssh-keygen -t rsa -b 2048
Nota: Para seguir este tutorial com êxito, procure manter as sugestões padrão do comando.
Passo 2: Encontrando a chave SSH
Caso você esteja no Windows, sua chave SSH estará localizada no caminho abaixo:
/c/Users/${YOUR_USER_NAME}/.ssh/id_rsa
Para Linux e Mac, a localização da chave é:
/home/${YOUR_USER_NAME}/.ssh/id_rsa
Passo 3: Vinculando a chave com sua conta no GitLab
Abra o arquivo id_rsa.pub com um editor de texto e copie seu conteúdo; Entre na sua conta do GitLab e navegue em Preferences > SSH Keys; Cole o conteúdo copiado do arquivo id_rsa.pub e atribua um título a chave; Clique em Add Key para salvá-la.
Nota: Não é obrigatório atribuir uma data de expiração para a chave.
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 dedevelop/*
, 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
oufeature/t05-dropdown-list-login
); - quando uma feature é finalizada, um PR da branch
feature/
relacionada é aberto com destino à branchdevelop
.
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:
- antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch
develop
e pegar as últimas atualizações (pull
); - criar uma branch para a task com o ID da task (
feature/tXX-YYYYY
); - "enviar" a branch para o remoto (
git push -u origin feature/tXX-YYYYY
); - desenvolver, commitar mudanças e atualizar o remoto (
push
); - voltar para o item 4 até finalizar a task;
- abrir um PR com destino à branch
develop
; - 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;
- 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
Módulos do Sistema
TBD
Diagrama de Fluxo
TBD
Frontend
Definições de Tecnologias
Módulos do Sistema
TBD
Diagramas de Componentes
TBD
Diagrama do Sistema
TBD