qd-srv-boillerplate

Introdução

Este repositório é um boillerplate e serve de template para criação de novos serviços.

Para começar uma migração de um serviço existente para esta arquitetura, recomenda-se iniciar pela versão 2.3

Requisitos para um serviço novo existir:

• [ ]: crie o repositório ECR com o seguinte padrão: ${{env.SERVICE_NAME}}_${{env.ENV_TYPE}}_repo

• [ ]: crie as variaveis de ambiente no parameter store seguindo o padrão: /${{env.ENV_TYPE}}/${{env.SERVICE_NAME}}/VARIABLE_NAME

  Nota: ${{env.SERVICE_NAME}} deve ser o nome do serviço que está no package.json ${{env.ENV_TYPE}} deve ser prod ou stg.

  Criar a infraestrutura inicial

Para criar a infraestrutura inicial, será necessário acesso à AWS e AWS CLI instalado na sua máquina. Importante configurar suas credenciais para o profile querodelivery

Dentro do diretório setup existem dois scripts que faz o trabalho pesado para você.

• [ ] : read_dotenv_and_create_parameter_store_on_aws.sh que irá criar todas as variáveis necessárias para do serviço dentro do parameter-store da AWS.
• [ ] : setup.sh que irá criar os repositórios de produção e de stage já com a política de apagar imagens antigas. Atualmente só armazena 3 ultimas imagens.

Exemplo de nome de repositório:

Nome do serviço no package.json qd-srv-boillerplate Tipo de ambiente prod ou stage

Em produção seria:

• qd-srv-boillerplate_prod_repo

Em stage/dev seria:

• qd-srv-boillerplate_stage_repo

Exemplo variável dentro do Parameter Store:

Nome da variável: /prod/qd-srv-boillerplate/MONGO_HOST Valor da Variável: mongodb+srv://user:[e-mail]/qdprod

Para executar a etapa de setup:

• [ ]: Entre no diretorio setup e execute: ./setup.sh
• [ ]: Após criar seu .env execute o omando read_dotenv_and_create_parameter_store_on_aws.sh

Feito esses dois passos, deverá existir o repositório ECR nna AWS e também todas as variáveis para o serviço cadastradas no parameter-store da AWS

Algumas expliccações sobre o padrão adotado:

• [ ]: O repositório ECR deve seguir o padrão: ${{env.SERVICE_NAME}}_${{env.ENV_TYPE}}_repo

• [ ]: As variáveis de ambiente no parameter store devem seguir o padrão : /${{env.ENV_TYPE}}/${{env.SERVICE_NAME}}/VARIABLE_NAME

  Nota: ${{env.SERVICE_NAME}} deve ser o nome do serviço que está no package.json ${{env.ENV_TYPE}} deve ser prod ou stage.

qd-srv-boillerplate

Configurações iniciais par um serviço novo

• [ ]: copie o .env.example para .env

cp ./environments/.env.example .env

• [ ]: Baixe e instale o terraform: https://releases.hashicorp.com/terraform/0.12.28/terraform_0.12.28_linux_amd64.zip
• [ ]: Crie o bucket s3 na aws, tfstates-terraform-quero, este bucket será usado para armazenar o estado da infra.
• [ ]: Configure o arquivo containers_definitions.json com variáveis EXISTENTES no parameter store da AWS.

  Para facilitar, você pode configurar o .env com todas as variáveis e rodar o comando: ./read_dotennv_annd_create_parameter_store_on_aws.sh. Esse comando irá verificar se é NODE_ENV=DEV ou NODE_ENV=PROD e irá criar todas as variáveeis no Parameter Store da AWS.

- Instalação

Nota: é necessária a utilização da versão Node >= 14.0.0

Primeiramente é necessário instalar as dependências do projeto, executando:

yarn install

Página de instalação do Yarn.

---

- Como executar

Para executar a build do projeto:

yarn build

Para iniciar o projeto utilizando a build:

yarn start

para iniciar o projeto com hot-reload:

yarn watch

---

- Testando

Para executar todos os testes (unitários, integração e componentes):

yarn test

Para executar os testes unitários:

yarn test:unit

Para executar os testes de integração:

yarn test:int

Para executar os testes de componente:

yarn test:component

---

- Regras de commit

O projeto utiliza hooks de pré-commit, executando lint e prettier em todo o código. Além disso, é necessário seguir algumas regras na escrita do título do commit.

Exemplos:

Commit de feature

feat: Adicionada função de cronograma

Commit de bugfix

fix: Correção de problema no cronograma

Commit de feature com breaking change

Para mais exemplos, consulte a documentação.

---

- Estrutura do projeto

O projeto segue a seguinte estrutura:

- src
  - application
  - configurations
  - contracts
  - domain
  - infrastructure

- application

Contém casos de uso da aplicação. Conhece o domínio e pode usá-lo.

- configurations

Contém arquivos de configuração do serviço. Podem ser utilizados em todas as camadas do projeto.

- contracts

Contém arquivos .yaml com especificação da API.

- domain

Contém regra de negócio. Não conhece camadas externas.

- infrastructure

Camada mais externa da aplicação. Conhece frameworks, databases, requisições http entre outras.

---

- Infraestrutura

• CI

  O arquivo sonar-project.properties, define algumas configurações usadas na etapa de quality-gate da pipeline, definindo, local de coverage, testes, exclusão de partes do projeto no cálculo do coverage de testes, entre outros.