Skip to content

Instantly share code, notes, and snippets.

@tgmarinho
Last active May 7, 2024 14:21
Show Gist options
  • Save tgmarinho/7d45fc32b8b673986275eddbc944b03a to your computer and use it in GitHub Desktop.
Save tgmarinho/7d45fc32b8b673986275eddbc944b03a to your computer and use it in GitHub Desktop.

VIVA LA MAIN

A proposta é manter apenas uma branch: main.

Dev abre PR, e o CI roda testes, verifica se build passa, é feito code review e o merge é feito para main.

Todo código novo na main vai gerar uma nova CI e CD, uma release para ambiente de staging, onde é feito o QA pelas partes interessadas (Dev, QA, Product).

O controle do que pode ser exibido por ambiente é feito por feature flags, basicamente um if no código que verifica se no ambiente X (staging | production) a feature pode ser ativada ou desativada.

Feature flags, serve tanto para bug fix e features novas, ou seja qualquer alteração no código, ela serve para evitar breaking changes.

Uma nova release em produção é gerada por tags e a feature é habilitada em produção através das features flags, acessando o backoffice: env files, tb feature_flags no banco de dados, ou ainda um front-end onde você tem um CRUD básico das feature flags.

Diagrama que demonstra os processos descritos.

main

Pré-requisitos para esse fluxo de trabalho:

  • Ter uma única branch (main)
  • Ter features flags, pode iniciar com ENVs e o céu é o limite como ter um backoffice
  • Pull requests menores
  • Tests automatizados para ter mais segurança de enviar código para produção, já que a entrega vai ser mais rápida
  • Escrever código melhor e ter revisão de códigos, inclusive esse workflow faz com que e o time de desenvolvimento escreva melhor e teste melhor por si mesmo, pois vai tentar evitar entregar algo não muito funcional, e por isso dos testes.
  • Execução de migrations de banco de dados precisam estar automatizadas

Trade Offs

Desvantagens

  • A codebase vai ter uns if espalhados para ativar e desativar as flags-features
  • Mais banco, branches para manter

Vantagens

  • Paridade das branches uma vez que tem apenas uma, sempre movendo para frente evitando break-changes
  • Evitar multiplos ambientes tornando mais caro recursos na cloud
  • Qualidade de código
  • Responsabilidade por parte dos times ...

Um problema a resolver

Abordagem descrita acima, resolve um problema de um fluxo onde é feito cherry-pick de códigos das branches, por exemplo, uma task foi aprovada pelo QA que testou no ambiente de develop, para staging. É feito cherry-pick do hash do commit dessa task e enviado para branch de de develop passando para branch staging, e depois enviado para produção assim que é feito os testes pelo tiem de produto em staging. Você acaba tendo que manter 3 branches, 3 banco de dados, fazendo isso provavelmente vai ter muitos conflitos e o dev vai gastar horas lidando com git ao invés de manter ou codar novas features, além da péssima developer experience que essa abordagem trás.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment