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.
- 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
- A codebase vai ter uns
ifespalhados para ativar e desativar as flags-features - Mais banco, branches para manter
- 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 ...
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.