| ... | ... | @@ -107,6 +107,17 @@ Sendo assim um o modelo de padrão a ser seguindo seria: |
|
|
|
## 🔍 Revisão de código
|
|
|
|
Todo código desenvolvido deve ser submetido a code review. Para que o merge request seja aprovado, ele precisa passar por uma análise, garantindo qualidade, consistência e conformidade com as diretrizes do projeto.
|
|
|
|
|
|
|
|
O projeto utiliza uma pipeline automatizada de CI/CD configurada no GitLab CI/CD, responsável por testar, construir, implantar e sincronizar o backend da aplicação.
|
|
|
|
A pipeline garante a qualidade do código, a entrega contínua na AWS e a sincronização do código com o GitHub.
|
|
|
|
|
|
|
|
A pipeline é dividida em seis estágios principais:
|
|
|
|
1) `test`: Execução dos testes automatizados e verificação de lint
|
|
|
|
2) `migrate`: Execução das migrações de banco de dados (Prisma)
|
|
|
|
3) `seed`: População inicial do banco de dados (opcional/manual)
|
|
|
|
4) `build_and_push`: Construção da imagem Docker e envio para o ECR da AWS
|
|
|
|
5) `deploy_lambda`: Atualização da função AWS Lambda com a nova imagem
|
|
|
|
6) `sync_github`: Sincronização automática do código com o repositório do GitHub
|
|
|
|
|
|
|
|
## 📏 Padrões de código
|
|
|
|
O projeto utiliza a ferramenta **ESLint** (https://eslint.org/) para identificar rapidamente erros, padrões inconsistentes ou más práticas no código. Seu principal objetivo é garantir a padronização do código, promovendo legibilidade, manutenibilidade e qualidade técnica em equipes de desenvolvimento.
|
|
|
|
|
| ... | ... | |
