main.md

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.

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.