Skip to content

Latest commit

 

History

History
306 lines (214 loc) · 12.1 KB

CONTRIBUTING.md

File metadata and controls

306 lines (214 loc) · 12.1 KB

◀ Voltar

contributing

Diretrizes para o processo de contribuição

Seja bem-vindo e obrigado por considerar contribuir com este projeto! Ler e seguir nossas diretrizes vai te ajudar a entrar com mais rapidez em nosso fluxo de trabalho, além tornar o processo de contribuição mais fácil e eficaz. Contamos com seu apoio!

Summary

(back to top)

Práticas

Geral

  • Se você não conseguir continuar uma tarefa, informe imediatamente sua equipe. A comunicação rápida evita atrasos e permite que outras pessoas te ajudem a resolver os problemas com mais rapidez.
  • Não reinvente a roda. Se você pesquisou e viu que já existe uma solução bem estabelecida para o seu problema, use-a. Isso economiza tempo e recurso.

Comunicação

  • Minimize o uso de IA na comunicação diária com a equipe. Valorizamos interações reais e genuínas.
  • Seja objetivo na sua comunição quando precisa de ajuda (isso não significa ser rude rsrs).
  • A comunicação assíncrona é uma grande aliada para equipes remotas. Para mais detalhes, clique aqui.

(back to top)

Setup

Para você começar a contribuir, é essencial configurar seu ambiente de trabalho local:

  • Instalar ferramentas: Certifique-se de ter instalado todas as ferramentas de linha de comando que o projeto requer.
  • Configurar variáveis de ambiente: Ajuste as variáveis de ambiente para garantir que seu sistema esteja preparado para rodar o projeto.
  • Executar scripts de automação: Rode os scripts fornecidos para configurar dependências, inicializar bancos de dados e outras tarefas automatizadas.

Note

Lembre-se: cada projeto tem seu próprio contexto e necessidades!

Pensando nisso, elaboramos as etapas abaixo para te guiar.

DevBox

O DevBox é uma ferramenta CLI que cria ambientes de desenvolvimento isolados e reproduzíveis, sem precisar usar containers Docker ou a linguagem Nix de forma nativa.

Note

Use essa opção se você não quiser instalar muitas ferramentas CLI diretamente em seu ambiente de trabalho.

Siga essas etapas para configurar seu ambiente:

curl -fsSL <https://get.jetpack.io/devbox> | bash
  • Inicialize seu projeto:
devbox init
  • Adicione os pacotes que deseja (vai mudar de projeto para projeto). Ex:
{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.10.7/.schema/devbox.schema.json",
  "packages": [
    "awscli2@latest",
    "[email protected]",
    "[email protected]"
  ],
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!' > /dev/null"
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}
  • Execute o seguinte comando para inicializar o shell temporário:
devbox shell

Com isso, podemos garantir que todos no projeto tenham as mesmas ferramentas nas mesmas versões, necessárias para o processo de desenvolvimento.

Note

Se você precisar de mais detalhes sobre essa configuração, verifique o arquivo devbox.json do seu projeto. Caso não exista, crie ele seguindo o passo a passo descrito acima.

Direnv

Para você automatizar certas ações em seu terminal sempre que você for trabalhar nesse projeto, configure o Direnv. Essa ferramenta vai ajustar o seu shell conforme o seu diretório atual. Assim, sempre que você entrar na pasta do projeto, o Direnv fará algo, como: carregará as variáveis definidas no .env ou disparar o shell do DevBox.

Siga essas etapas para configurar seu ambiente:

  • Acesse a documentação do direnv e siga as instruções para instalá-lo.

  • Após a instalação, crie um arquivo .env na raiz do seu projeto para armazenar as variáveis de ambiente utilizadas.

  • Crie o arquivo .envrc com o seguinte conteúdo:

# Dotenv Support
[[ ! -f .env ]] || dotenv .env

# Devbox Support
has devbox && eval "$(devbox generate direnv --print-envrc)" && exit 0
  • A primeira vez que você criar ou modificar um arquivo .envrc, você precisará autorizá-lo com o comando:
direnv allow

Seguindo essas etapas, quando você navegar para a pasta do seu projeto, as variáveis de ambiente serão carregadas automaticamente e o DevBox será inicializado.

Note

Se você precisar de mais detalhes sobre esse configuração, verifique o arquivo .envrc do seu projeto.

Task

A ferramenta task oferece uma maneira conveniente de definir e gerenciar tarefas específicas do projeto, facilitando a automatização de scripts comuns e simplificando os fluxos de trabalho de desenvolvimento.

Note

É semelhante à ferramenta make, que é utilizada principalmente para automatizar tarefas.

Siga essas etapas para configurar seu ambiente:

  • Certifique-se de que você instalou o comando task seguindo as etapas de configuração do DevBox.
    • Caso não tenha seguido, acesse a documentação do task e siga as instruções para instalá-lo.
  • Execute o comando task no diretório raiz do projeto para ver todos os comandos disponíveis.

Note

Se você precisar de mais detalhes sobre cada tarefa definida, verifique o arquivo Taskfile.yaml do seu projeto. Caso não exista, crie ele seguindo o passo a passo descrito acima.

(back to top)

Commit Messages

Nesse projeto, exigimos que todos os commits sigam um formato específico de mensagem, o Conventional Commits. Com isso, conseguimos:

  • Clareza e Consistência: As mensagens de commit seguem um formato padrão, facilitando a leitura e a compreensão das mudanças.
  • Automatização: Permite a automação de processos, como geração de changelogs, versionamento semântico e lançamentos automáticos.
  • Rastreamento de Alterações: Facilita o rastreamento de mudanças ao longo do tempo, tornando mais fácil identificar o que foi modificado e por quê.
  • Melhoria na Revisão de Código: Proporciona uma melhor experiência de revisão de código, já que as mudanças são descritas de forma clara e padronizada.
  • Comunicação Eficaz: Ajuda a todos os membros da equipe a entenderem rapidamente o contexto e o propósito de cada alteração no código.

Veja como é organizado esse formato de commits:

<type>(optional scope): <description>

[optional body]

Type

Descreve o tipo de alteração do commit. Temos as seguintes opções:

Tipo Descrição
feat Um novo recurso (adição de um novo componente, fornecimento de novas variantes para um componente existente, etc.).
fix Uma correção de bug (correção de um problema de estilo, resolução de um bug na API de um componente etc.). Ao atualizar dependências que não sejam de desenvolvimento, marque suas alterações como fix.
docs Alterações somente na documentação.
style Alterações que não afetam o significado do código (espaços em branco, formatação, falta de ponto e vírgula etc.). Não deve ser usado para alterações na interface do usuário, pois essas são alterações significativas; em vez disso, considere usar feat ou fix.
refactor Uma alteração de código que não corrige um bug nem adiciona um recurso.
perf Uma alteração de código que melhora o desempenho.
test Adição de testes ausentes ou correção de testes existentes.
build Alterações que afetam o sistema de build.
ci Alterações em arquivos e scripts de configuração de CI/CD.
chore Outras alterações que não modificam arquivos de origem ou de teste. Use esse tipo ao adicionar ou atualizar dependências de desenvolvimento.
revert Reverte um commit anterior.

Scope

É qualquer coisa que forneça informações adicionais ou que especifique o local de alteração do seu código. Por exemplo events, kafka, dockerfile, authorization e etc. Cada tipo (type) de commit pode ter um escopo (scope) opcional, cabendo a você adicionar ou omitir essa informação. Por exemplo:

feat(login): add route

Note

Use a convenção PascalCase na hora de definir seu escopo (scope).

Description

É o campo onde você diz o que foi feito no commit, porém de forma breve. Para isso, recomendamos que:

  • Priorize descrições em inglês.
  • Use o imperativo, tempo presente: "change", não "changed" ou "changed".
  • Não coloque a primeira letra em maiúscula.
  • Não coloque ponto (.) no final.

Note

Cada tipo de commit tem um efeito sobre a próxima release que você for lançar.

(back to top)

MR Process

Ao criar um MR (merge request), é uma boa ideia definir o seu título seguindo a mesma convenção utilizada nas mensagens de commit. Dessa forma, se seu MR for sofrer um squash após a mesclagem, o maintainer poderá usar o título como a mensagem final do commit, criando um histórico formato, enxuto e linear.

Steps

  • Crie uma branch a partir da branch main:
git checkout main
git pull origin main
git checkout -b sua-nova-branch
  • Trabalhe na branch criada:
    • Realize as alterações necessárias e faça os commits das mudanças.
    • Certifique-se de que seu código atenda os padrões de qualidade estabelecidos.
    • Garanta que seus commits sigam a convenção de commits definida acima.
git add .
git commit -m "fix: change the commit"
  • Faça o push da sua branch:
git push origin sua-nova-branch

  • Abra uma solicitação de MR:

    • No GitLab, navegue até o repositório e abra uma nova Merge Request da sua branch para a branch de produção main.
    • Adicione uma descrição clara do que foi feito e qualquer informação relevante para a revisão.
    • Defina o título usando commits convencionais.
    • Marque a opção de remover a branch de origem após a mesclagem.
    • Marque a opção para squash dos commits.

  • Revisão e Aprovação:

    • Um mantenedor revisará seu código.
    • Se o código atender aos requisitos e padrões, ele será aprovado.
    • Após a aprovação, seu código será mesclado na branch main.

  • Finalização:

    • Após a mesclagem, sua branch pode ser deletada se não for mais necessária.
    • Certifique-se de executar o git pull na branch main.

Seguir este processo garante que as alterações sejam revisadas adequadamente e que o código de produção permaneça estável e com qualidade.

Note

Se você tiver vários commits em seu PR que resolvem o mesmo problema, squash os commits.

Reviewing

Durante o processo de revisão do MR, siga essas políticas:

  • Seja respeitoso e construtivo.
  • Sempre realize a revisão em pares.
  • Sugira alterações em vez de simplesmente comentar os problemas encontrados.
  • Exigimos pelo menos um aprovador no MR, que não seja o autor.
  • Se não tiver certeza sobre algo, pergunte ao autor do MR.
  • Se você estiver satisfeito com as alterações, aprove o MR.

(back to top)

Versioning Process

Este projeto segue a especificação SemVer. Consulte a documentação para obter mais detalhes.

(back to top)