Diretrizes Gerais de Contribuição

Este documento descreve as diretrizes gerais para contribuir com o Modern Gitops Stack.

O Modern Gitops Stack é uma coleção de módulos, cada um deles com seu próprio ciclo de lançamento, para facilitar o desenvolvimento e manutenção de cada módulo.

DICA: Um projeto GitHub privado de propriedade da equipe @GersonRS/is-modern-gitops-stack está disponível https: //github.com/orgs/GersonRS/projects/3/[aqui]. É uma forma útil de acompanhar o andamento dos PRs e Issues de todos os repositórios. Para obter mais informações sobre como ele é implementado, verifique a página Project Board.

Fluxo de trabalho de desenvolvimento

Quando um novo recurso ou correção é necessário, o fluxo de trabalho típico é o seguinte:

Você deve criar um novo branch a partir do branch main do módulo que deseja trabalhar;
Trabalhe e teste em sua filial;
Quando você achar que seu recurso/correção está pronto, crie um Pull Request para mesclar seu branch no branch main.

As subseções a seguir descrevem algumas das melhores práticas a serem seguidas ao trabalhar no Modern Gitops Stack.

Ramos

Mantenha o branch main limpo e apenas mescle Pull Requests nele.
Crie um novo branch para cada Pull Request. O nome da filial deve ser o número do ticket do Jira, seguido de uma breve descrição do trabalho realizado na filial, por exemplo ISMODERN-GITOPS-185-v1-docs. Isso permitirá que o ticket Jira seja automaticamente vinculado à filial e ao Pull Request.

Confirmar mensagens

Ao se comprometer com sua filial, você deve seguir a especificação Conventional Commits. Isso também permitirá que a geração automatizada do changelog funcione corretamente.
Usamos os seguintes tipos de commit:
- feat - um novo recurso
- fix - uma correção de bug
- docs - apenas a documentação muda
- style - alterações que não afetam o significado do código (espaço em branco, formatação, falta de ponto e vírgula, etc)
- refactor - uma alteração de código que não corrige um bug nem adiciona um recurso
- ci - alterações nos arquivos e scripts de configuração do CI
- chore - outras alterações que realmente não modificam o código (pode ser um commit de mesclagem, por exemplo, `chore: rebase 'main' into 'ISMODERN-GITOPS-184-v1-docs' antes de mesclar PR `)
Se o seu commit adiciona uma alteração significativa, você deve adicionar um ! após o tipo de commit, por exemplo feat!: add uma alteração significativa.

Adicionar uma alteração significativa acionará automaticamente um aumento na versão principal quando o módulo for lançado.
O escopo do commit é opcional, mas recomendado:
- Pelo menos, para os módulos que possuem variantes, recomenda-se incluir a variante no escopo (eks, aks ou kind). Você pode simplesmente usar a variante ou até mesmo usar a variante como prefixo (por exemplo, docs(eks-variables): add descriptions).
- Se estiver modificando algo no gráfico, você deve adicionar chart como escopo.
- Caso contrário, os escopos recomendados poderiam ser apenas o tipo de código alterado, por exemplo, variáveis, saídas, principal, etc.
A especificação de commits convencional também permite adicionar um corpo e um rodapé à mensagem de commit. Você poderia usar o corpo para adicionar mais detalhes e contexto ao commit, mas seja curto. O rodapé pode ser usado para adicionar uma referência a um ticket do Jira, por exemplo.

Solicitações pull

Você pode criar Pull Requests a partir de seu branch a qualquer momento durante o desenvolvimento, mas se ele não estiver pronto para ser mesclado, você deve marcá-lo como Draft Pull Request. Isso evitará que ele seja mesclado por engano, ao mesmo tempo que permitirá que você obtenha feedback de outros desenvolvedores, bem como verificações automatizadas e geração de documentação feitas pelo GitHub Actions.
Para que um PR seja mesclado, você precisa ter pelo menos uma revisão de outro desenvolvedor e todas as verificações automatizadas devem ser aprovadas. Comentários sobre o PR são bem-vindos e nos permitem acompanhar as discussões que acontecem no PR.

Preferimos usar a opção Rebase and Merge ao mesclar um PR. Isso permite que o processo de liberação automática adicione múltiplas entradas no changelog, uma para cada commit no PR. Isto é particularmente útil quando o PR contém múltiplas alterações, por exemplo, ao adicionar um novo recurso e corrigir um bug ao mesmo tempo.

A desvantagem desta abordagem é que o histórico de commits precisa ser cuidado. Por exemplo, ter vários commits que dizem docs: fix typo não é apropriado. Neste caso, você deve compactar manualmente os commits em um único commit com uma mensagem de commit adequada. O mesmo vale para vários commits que foram usados iterativamente para corrigir um bug ou desenvolver um recurso. Nesse caso, você deve compactar os commits em um único commit, um para cada correção ou recurso.

Tome cuidado para intitular e descrever adequadamente sua solicitação pull. O título deve ser suficientemente descritivo e seguir as especificações convencionais dos commits. Quanto à descrição, siga o modelo fornecido.

Se você fizer um Squash and Merge em um Pull Request, a mensagem de commit será o título do Pull Request. Portanto, certifique-se de que o título seja descritivo o suficiente e siga a especificação convencional dos commits, caso contrário teremos que corrigir manualmente a mensagem do commit no branch main, o que é no mínimo inconveniente.

Problemas

Se você encontrar algum problema no Modern Gitops Stack, poderá criar um problema no repositório em que o encontrou. Um problema pode ser um bug ou uma solicitação/proposta de recurso.
Se for um bug, descreva o problema adequadamente e forneça o máximo de contexto possível.
Se for uma solicitação/proposta de recurso, descreva por que o recurso é necessário e qual problema ele resolverá para você.
As questões são mais úteis para usuários externos do Modern Gitops Stack, se possível podemos discutir o assunto em nossa reunião semanal e então decidir se é algo que queremos implementar ou não. Nesse caso, podemos então criar um ticket Jira, para acompanhar o trabalho que precisa ser feito.