Skip to main content
Todo repositório do ecossistema usa Trunk Based Development: branches curtas (no máximo dois dias de vida), PRs pequenos e merge frequente na branch principal. Ninguém fica com uma mudança grande acumulada por semanas esperando revisão. Um plugin compartilhado automatiza as partes repetitivas desse fluxo, para que a disciplina não dependa de lembrar cada passo manualmente.

​
As etapas

Uma tarefa passa por até cinco etapas, na ordem:
  1. Escopo (opcional, recomendado quando o pedido é vago): traduz um pedido em escopo concreto, checando primeiro se algo parecido já existe em algum dos repositórios ou já foi decidido em algum documento, em vez de assumir que é trabalho novo.
  2. Início: cria a issue no GitHub, decide em qual dos dois quadros ela é acompanhada (veja abaixo) e já cria a branch de trabalho a partir da branch principal atualizada.
  3. Implementação: quantos commits forem necessários.
  4. Commit: cada commit segue o padrão Conventional Commits, gerado a partir do que está de fato staged, nunca adicionado automaticamente.
  5. Abertura de PR: o título do PR é o título da issue, e o corpo é gerado a partir dos commits e do diff. A mesma etapa, rodada de novo depois que o PR é aceito, limpa a branch local e fecha o ciclo.
Antes de abrir o PR é recomendado (não obrigatório) passar o diff por uma revisão de qualidade e por uma checagem de conformidade com o padrão de arquitetura do repositório em questão.

​
Onde uma tarefa é acompanhada

Existem dois quadros de acompanhamento, e a issue entra em um ou outro dependendo do repositório onde nasce:
  • Automation Hub: para os seis repositórios *.hub.dommed descritos em Ecossistema, tudo que é sobre a plataforma em si.
  • Automations: para os repositórios dommed-*, tudo que é sobre um processo automatizado específico.
Há uma exceção deliberada: uma issue em workers.hub.dommed vai para o quadro de automações quando é sobre a infraestrutura ou o código de uma automação específica rodando ali dentro, por exemplo ajustar a máquina dedicada de uma automação ou corrigir o executor dela. Continua no quadro da plataforma quando é sobre o worker como um todo, como o contrato que toda automação implementa ou o toolkit de integrações compartilhadas. A distinção é se o assunto é sobre uma automação ou sobre a plataforma, não o nome do repositório onde o código mora.

​
Papéis consultivos

Ao longo dessas etapas, três papéis do time podem ser consultados quando o assunto exige: um foca em conformidade com o padrão de arquitetura de cada tipo de repositório, um em infraestrutura e custo, e um em postura de segurança. Nenhum deles implementa: eles dão parecer para quem está com a tarefa decidir com mais contexto, e questões de infraestrutura e de segurança são sempre consultadas juntas, nunca uma no lugar da outra.