qd-srv-boillerplate v2.13.2

Introdução

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

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:pass@qdprod-gpsnb.mongodb.net/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.