Skip to content

GitLab

Last edited by Bianca Camargo Machado
Page history
This is an old version of this page. You can view the most recent version or browse the history.

arquitetura

Home Arquitetura Banco de Dados Configuração Gerenciamento do Projeto Instalação Materiais de Estudo Mockups Requisitos Reuniões Sprints

Arquitetura do Sistema

Fluxograma de funcionamento do aplicativo

Este fluxograma é referente à aplicação mobile que tem como principal função a coleta do tempo das atividades.

Perceba que num primeiro momento estamos abstraindo o fluxo de inserção de dados, considere que estes já estarão disponíveis na API. Nossa prioridade é o desenvolvimento do App (Android e IOS) para coleta de tempos, para que posteriormente possamos dedicar tempo para as tarefas administrativas (Cadastrar Hospitais, Cadastrar Processos - que contém atividades -).

É possível notar que não é necessário login para o uso de funcionários e bolsistas, estes só precisam identificar o respectivo hospital, para que sejam vinculados os processos e atividades referentes à sua função. A identificação do paciente é apenas para identificar e diferenciar possíveis processos parecidos sendo realizados ao mesmo tempo. Esta identificação deve ser feita de forma que facilite o máximo possível o atendimento. Possíveis identificações: Iniciais do paciente, Código do atendimento do paciente no hospital ou outro. (Esta identificação deve ser informada no momento no fluxo apresentado).

Git Branching Model

O modelo de gestão das branches do Git é baseado no Git Flow "trandicional" 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 app e api deve 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! 😃

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:

#48: Fix patient name field placeholder

The placeholder was clipped smartphones with small screens; reduced placeholder
length for better UX on those devices.

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:

    • funciona obrigatoriamente em Android, preferencialmente em iOS;
    • interface funciona nos tamanhos de tela suportados;
    • interface segue especificação no Figma;
    • conforme critérios de aceitação para a tarefa;
    • passa nos testes funcionais definidos para a tarefa/story;
    • documentação atualizada;
    • código dentro dos padrões;
    • código sem warnings ou erros de linter.

  • api:

    • funciona conforme especificação no Postman;
    • possui testes de unidade associados;
    • mantém cobertura de pelo menos 50%;
    • dependências externas adicionadas aprovadas pelos AGES III;
    • documentação atualizada;
    • código dentro dos padrões;
    • código sem warnings ou erros de linter.

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

Guia de desenvolvimento

Foi criado um guia de desenvolvimento para o backend, com o intuito de auxiliar no processo de entendimento da arquitetura de camadas usada no backend, organização física do repositório e acesso à documentação das rotas.

🔗 Acesse o guia de desenvolvimento.

Deploy em produção

Nessa seção, você terá instruções sobre como fazer o deploy do backend para o ambiente de produção, e como gerar uma APK do aplicativo Android para distribuição pela Play Store.

Deploy da API em produção

Para disponibilizarmos nossa API em produção, o seguinte blog foi utilizado como referência: https://medium.com/@nishankjaintdk/setting-up-a-node-js-app-on-a-linux-ami-on-an-aws-ec2-instance-with-nginx-59cbc1bcc68c

A abordagem final é a que segue:

  1. Criar conta na Amazon AWS

Acesse o blog referência e realize os passos da seção "Create an AWS account".

  1. Criar instância EC2

Acesse a documentação da Amazon AWS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html

  1. Acessar através de conexão ssh a instância EC2

Acesse a documentação da Amazon AWS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

  1. Instalar na instância Git, NodeJS, Docker, Docker-Compose e PM2
  • Comandos:
$ sudo yum update
$ sudo yum install -y docker
$ sudo usermod -a -G docker ec2-user
$ sudo service docker start
$ sudo chkconfig docker on
$ sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-`uname -s`-`uname -m` | sudo tee /usr/local/bin/docker-compose > /dev/null
$ sudo chmod +x /usr/local/bin/docker-compose
$ ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
$ sudo yum install git
$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh | bash
$
  • Desconecte da instância e conecte novamente, então:
$ nvm install v13.12.0
$ npm install pm2 -g

  1. Realizar o deploy do PostgreSQL usando Docker e Docker-Compose

  2. Configurar o banco de dados conforme documentação da API usando pgAdmin4

  3. Clonar repositório do backend do projeto

  4. Inicializar backend com PM2

Gerar APK para envio à Google Play Store

Antes de continuar, certifique-se de que o ambiente de desenvolvimento está configurado e funcionando corretamente.

1 - Gerar chaves

Se você já mandou o app para a Play Store e tem um arquivo com a keystore e chave de upload, pule essa etapa.

Antes da primeira submissão do APK à Play Store, é preciso gerar uma chave privada para assinar o APK da aplicação. Essa chave deve ser guardada em um local seguro, pois será necessária sempre que for preciso disponibilizar uma atualização da aplicação na Play Store.

É preciso gerar uma keystore (capaz de armazenar várias keys) e uma key. Abra uma janela do terminal e execute o seguinte comando:

$ keytool -genkeypair -v -keystore upload.keystore -alias upload -keyalg RSA -keysize 2048 -validity 10000

Você deverá informar duas senhas: uma para a keystore e outra para a chave. Também será preciso informar alguns dados de identificação, como nome, organização, cidade, estado e país.

O resultado da execução é um arquivo upload.keystore (com uma key upload) presente na mesma pasta onde o comando foi executado. Guarde este arquivo e as senhas informadas em um local seguro, e não os armazene no repositório da aplicação. Sem ele, não será possível atualizar o aplicativo na Play Store (apenas enviar outro APK como se fosse um novo app).

2 - Configurações no projeto

Considerando que você tem um arquivo keystore com uma chave para upload.

  1. Copie o arquivo da keystore para a pasta android/app/;
  2. Edite o arquivo android/gradle.properties, conforme exemplo abaixo:
DTOOL_UPLOAD_STORE_FILE=upload.keystore # nome do arquivo com a keystore
DTOOL_UPLOAD_KEY_ALIAS=upload           # nome da key presente na keystore
DTOOL_UPLOAD_STORE_PASSWORD=dtool2020   # senha da keystore
DTOOL_UPLOAD_KEY_PASSWORD=dtoolupload   # senha da key

Não adicione essas mudanças ao repositório (não commite isso). Realize essas mudanças sempre que for preciso gerar uma APK para distribuição.

3 - Gerando o APK

Abra uma janela do terminal, vá até a pasta android/ e execute o comando ./gradlew assembleRelease. O comando deve demorar um pouco para completar, uma vez que o processo de build para distribuição é mais demorado.

Quando o comando finalizar, o APK final estará na pasta android/app/build/outputs/apk/release/.

4 - Enviando à Play Store

Confira os tutoriais oficiais da Google para ver como fazer o upload da aplicação para a Play Store.

🔗 Fazer upload de um app - Ajuda do Play Console.

Mais informações

Para mais informações, consulte as documentações oficiais:

Próximos possíveis artefatos:

  • Segurança
  • Rotas de Backend (Arquitetura funcional)
  • Objects – Backend API
  • Methods – Backend API
  • Arquitetura - Não Funcional
  • Diagrama de Pacotes / Componentes (Arquitetura de software)
  • Diagrama de Deploy
  • Documentação sobre aplicação de Design do Projeto
  • Análise dos principios SOLID

Devem ser apresentados das seguintes formas:

  • Imagens ou Gifs
  • Diagramas ou Sistemas
  • Descrições ou textos explicativos