idvogados/idvogados-api

Configuração do ambiente de desenvolvimento

rodrigondec opened this issue · 10 comments

Precisamos ter o seguinte heading no arquivo CONTRIBUTIND.md:

# Configurando o ambiente de desenvolvimento
bla bla bla

Aguardando decições dos tech leads e criação do boilerplate do projeto

@rodrigondec acho que esse pode esperar o tech lead do projeto, acredito que seja a pessoa mais indicada para escrever esse documento.

@rodrigondec acho que esse pode esperar o tech lead do projeto, acredito que seja a pessoa mais indicada para escrever esse documento.

Sim, o intuito é justamente esse.

Está com os Status Bloqueado e Precisa De Mais Informações e mencionei explicitamente que está esperando decisão de tech leads

Oi pessoal, acredito que posso ajudar nesse ponto.

Muitas decisões precisam ser tomadas, porém alguns passos são comuns entre projetos Node e podem ser descritos. Além disso já gostaria de deixar algumas sugestões de ferramental para utilizarmos no backend.

As etapas que imagino seriam:

1. Instalar nvm

  • Instale o nvm
  • Na pasta do projeto, rode os comandos
    • nvm install
    • nvm use
    • Então, verifique qual versão do Node seu terminal está utilizando, com o comando nvm current. Essa versão deve ser a mesma que está contida no arquivo .nvmrc do projeto.
  • Instale as dependências do projeto com o comando npm install

Motivação:

O nvm é um gerenciador de versões do Node, que permite o desenvolvedor ter várias versões instaladas na sua máquina tanto do Node quanto do npm. Devemos ter na raiz do projeto um arquivo .nvmrc contendo a versão suportada pelo projeto, ex: v12.0.1. Dessa forma, estaremos garantindo que o desenvolvedor irá utilizar a versão que o projeto suporta.

2. Instalar o docker e docker-compose

  • Instale o Docker
  • Instale o Docker Compose
  • Inicialize as dependências utilizando o comando npm run deps

Motivação:

Imagino que caso o projeto tenha uma dependência de algum serviço (MySQL, Redis, RabbitMQ, etc), precisaremos comunicar com esses serviços, seja nos testes automatizados ou em um teste local, subindo a API. Então precisamos fornecer os serviços e suas configurações utilizando o arquivo docker-compose.yaml, para que o dev contribuidor não precisar se preocupar com isso e foque apenas na funcionalidade que está desenvolvendo.

A ideia de usar um comando personalizado (Ex: npm run deps), é para deixar no package.json do projeto, o modo como queremos inicializar essas dependências. Imagino que será algo parecido com isso:

"deps": "docker-compose up --force-recreate --build --renew-anon-volumes"

O que acham desse roteiro de preparação do ambiente ?

Toda sugestão é muito bem vinda 🚀

Concordo, acho muito importante utilizar o docker.

Eu inclusive gosto de deixar o próprio node em um container docker também (não sou desenvolvedor node, então geralmente nem tenho o nvm nem o npm instalado na minha máquina).

Gostaria que tivesse essa possibilidade também. Em algum momento pessoas que não queiram ter node podem querer rodar o projeto.

Faço a mesma coisa com os meus projetos Python. Tenho o python dockerizado e utilizo também o python direto na máquina (pois o debugger não rola tão fácil em um container).

O visual Studio code tem a opção de desenvolvimento dentro de containers, inclusive podendo subir toda uma stack de uma vez (node, banco, etc). Isso é um arquivo de configuração que podemos versionar, e fica a mesma coisa para todo mundo, independente do SO. Mas acho importante também ter a parte de config da máquina física.

@rodrigondec bom ponto 👏

Eu inclusive gosto de deixar o próprio node em um container docker também (não sou desenvolvedor node, então geralmente nem tenho o nvm nem o npm instalado na minha máquina).

Penso que os dois cenários podem ser abordados, sendo possível subir a API no Docker e também localmente, apontando para os serviços no Docker (banco, fila, cache, etc).

A estrutura que imagino:

  • npm start sobe a API local em localhost:3000
  • npm run deps sobe a API no Docker em localhost:3001

O que acham @idvogados/backend, faz sentido ?

O visual Studio code tem a opção de desenvolvimento dentro de containers, inclusive podendo subir toda uma stack de uma vez (node, banco, etc). Isso é um arquivo de configuração que podemos versionar, e fica a mesma coisa para todo mundo, independente do SO. Mas acho importante também ter a parte de config da máquina física.

@Netaum essa configuração fica atrelada ao VSCode ? Consegue nos mostrar um exemplo ?

Imagino que vários devs já usam outras IDEs para desenvolver e caso seja algo ligado ao VSCode exclusivamente, pode não envolver todos os cenários.

Talvez o próprio arquivo docker-compose.yaml já faça esse trabalho, pois ele agrega todas as definições de serviços que a API precisa.

O que acha ?

@pabrrs essa é uma função do vscode, mas no final é um docker compose que o vscode consegue se injetar dentro. Eu recomendo fortemente usarmos o code como IDE, mas deixando um compose versionado já vai ajudar bastante. Vou fazer um exemplo em node e colo aqui.

@pabrrs esse é um exemplo usando o devcontainer.
vscode_exemple.zip

@rodrigondec bom ponto clap

Eu inclusive gosto de deixar o próprio node em um container docker também (não sou desenvolvedor node, então geralmente nem tenho o nvm nem o npm instalado na minha máquina).

Penso que os dois cenários podem ser abordados, sendo possível subir a API no Docker e também localmente, apontando para os serviços no Docker (banco, fila, cache, etc).

A estrutura que imagino:

* `npm start` sobe a API local em `localhost:3000`

* `npm run deps` sobe a API no Docker em `localhost:3001`

O que acham @idvogados/backend, faz sentido ?

Nos meus projetos eu utilizo make para organizar meus comandos.

O próprio node tem esse suporte para adicionar os comandos, porém isso significa que a pessoa precisa ter o npm instalado. Devemos ter os comandos no npm para rodar o projeto (é um padrão node).

Porém pra subir sem ter o npm instalado é um comando docker mesmo a ser rodado.

Por isso sugiro ter um Makefile também.