Boas práticas que fazem a diferença #2 📝

#braziliandevs #beginners #programming #productivity

Esse é o segundo post de uma série sobre boas práticas que eu aprendi durante a minha jornada, tanto no trabalho e processos seletivos, quanto na faculdade e projetos pessoais ou de comunidades.

Sumário

1. Git Flow
2. Segredos
3. Organização de um projeto

1. Git Flow

Esse é um assunto um tanto extenso, portanto, vamos tentar resumir os seus principais pontos, mas recomendo fortemente buscar se aprofundar neste tópico posteriormente, assim como todos os outros tópicos dos quais eu lhes apresentei.

Git Flow é um modelo de fluxo de trabalho para repositórios Git¹, sendo um grande aliado em projetos de médio ou grande porte, ou mesmo em projetos menores com mais de uma pessoa trabalhando, pois nos ajuda a organizar e padronizar a estrutura do nosso repositório/projeto Git.

Para se adotar o Git Flow, você deve possuir ao menos duas das primeiras branches principais abaixo:

main²: branch principal contendo todas as alterações estáveis e previamente aprovadas em outras branches.
develop²: branch intermediária onde as alterações são realizadas (normalmente apenas em projetos de pequeno porte) ou mescladas (merge) de outras branches temporárias;
hom: branch intermediária com fins de homologação das alterações, antes de enviá-las para a main;
stage: branch intermediária menos comum, também com fins de homologação, porém, conectada a algum ambiente com configurações similares as do ambiente de produção, por exemplo, em casos de grandes aplicações webs comerciais.

E por fim, as branches temporárias, onde as alterações são normalmente desenvolvidas:

feature/nome-da-feature: branches onde são desenvolvidas determinadas features para então serem mescladas a branch develop.
fix/nome-da-correção: branches onde são desenvolvidas correções para bugs encontrados ou reportados pelas pessoas usuárias.
hotfix/nome-da-correção: branches onde são desenvolvidas correções urgentes, das quais normalmente não é possível aguardar todo o fluxo de entrega de uma nova versão.
release/nome-ou-versão-da-release: branches onde mesclamos todas as alterações planejadas para uma determinada versão do projeto, normalmente utilizada em conjunto com alguma automação de integração contínua.

Para concluir, no Git Flow nós realizamos os trabalhos nas branches temporárias e depois mesclamos tudo na branch develop, opcionalmente mesclando para fins de testes e aprovações nas branches stage, hom, ou mesmo na própria branch develop, e por fim, mesclando na branch main, disponibilizando as alterações em produção.

Outro ponto interessante do Git Flow, é que ele nos ajuda a melhor estruturar também nossas ferramentas de integração contínua (CI), porém, não é recomendado para casos de entrega contínua (CD), pois iria gerar a necessidade de branches de longa duração ou mesmo permanente (além das 2 ou 3 principais).

2. Segredos

Secrets em inglês, são todos os dados sigilosos utilizados nas aplicações que não devem ser publicamente acessíveis, como por exemplo, senhas, chaves de APIs, tokens, etc.

Mas como escondê-los em nossos projetos? Normalmente fazemos uso de variáveis de ambiente (environment variables, ou apenas env vars) e ferramentas especializadas em gestão e hospedagem segura de segredos como a AWS Secrets Manager.

Os próprios sistemas operacionais possuem gerenciadores de variáveis de ambiente, mas é comum vermos também a utilização de arquivos como o .env³ para facilitar a utilização de segredos específicos de projetos:

DB_HOST=172.0.0.1
DB_PORT=5432
DB_USER=admin
DB_PASSWORD=123

Muitas tecnologias possuem nativamente funções ou métodos para a leitura e manipulação de variáveis de ambiente, porém, em alguns casos é necessário o uso bibliotecas de terceiros, como era o caso do Node.js, mas hoje a partir da versão 20.6.0, tendo suporte nativo à leitura de arquivos .env. Por exemplo, dados o arquivo .env acima e o código abaixo:

const DB_HOST = process.env.DB_HOST,
      DB_PORT = process.env.DB_PORT,
      DB_USER = process.env.DB_USER,
      DB_PASSWORD = process.env.DB_PASSWORD;

...

Bastaria iniciar o nosso projeto com os seguintes argumentos no terminal, para que a aplicação Node.js, executasse carregando os segredos contidos no arquivo .env:

node --env-file=.env nome_do_arquivo.js

3. Organização de um projeto

Como já vimos no primeiro post, cada pessoa, tecnologia, time, ou empresa podem possuir padrões/convenções de organização de projetos, pastas, arquivos, etc.

É importante conhecer bem os padrões mais utilizadas na área ou da tecnologia da qual você utiliza, sendo eles normalmente descritos em artigos ou mesmo nas próprias documentações, como por exemplo nas seguintes documentações para projetos Next.js ou FastAPI.

Por hoje é isso, espero que gostem e para qualquer feedback ou discussão construtiva, nos vemos nas redes sociais e aqui nos comentários! 🎉

É muito comum vermos uma confusão com relação ao Git, GitHub, GitLab, etc. Mas é importante lembrar, que o Git é a ferramenta de versionamento, enquanto o GitHub e afins, são plataformas de hospedagem e gerenciamento seguro em nuvem desses repositórios/projetos Git. ↩
Hoje em dia não se utiliza mais do padrão de nomenclaturas master, slave, entre outras, por conta da sua conotação racista e em apoio ao movimento "Black Lives Matter", começando com o GitHub, e por fim outras empresas adotando o novo padrão pelos mesmos motivos. ↩
Arquivos que contenham segredos como o .env, por sua natureza devem ser incluídos no arquivo .gitignore em caso de envio para repositórios remotos, do contrário qualquer pessoa com acesso a esses repositórios teriam acesso a eles, mesmo casos elas não possuíssem autorização para os utilizá-los. ↩