Problemas do staging
- o pre-live não é igual à produção
- surge uma fila de releases
- os releases ficam grandes demais
- falta ownership sobre as mudanças
- deixa-se o processo assumir o lugar da responsabilidade
Como a Squeaky faz deploy
- fazer merge apenas do que já pode ir para produção: as mudanças passam por testes suficientes no ambiente local de desenvolvimento
- usar uma estratégia de branching plana: quando uma feature está pronta para merge, faz-se rebase e testes. Se surgir problema, faz-se roll-forward
- features de alto risco sempre usam feature flags
- deploy manual: monitoramento contínuo após as mudanças. Monitoramento/logging/alertas aplicados de forma ampla. Deploy blue/green
Conclusão
- ao abrir mão de um ambiente de staging para ter CI/CD de verdade, é possível criar uma forma diferente de pensar sobre o shipping de software
- se não houver buffer antes de as mudanças entrarem em produção, é preciso ter certeza de que elas estão prontas para produção
- é preciso ter ownership e atenção sobre todas as mudanças que você faz
- os custos e a complexidade da infraestrutura diminuem, e o ciclo de vida de desenvolvimento pode ser simplificado e acelerado
3 comentários
Pensando na sensação de segurança que tive ao montar um ambiente de staging dentro da organização, é difícil concordar muito.
Ainda assim, concordo com as desvantagens de os deploys atrasarem ou de o volume de mudanças aumentar.
Acho que o simples fato de existir um ambiente de staging já tem valor, porque permite verificar se é possível fazer deploy em outro ambiente e se atende à essência? de um software que pode ser replicado.
Bem, não sei se faz sentido depender de pessoas com
ownership/atençãoincompletos. No mínimo, não é justamente o trabalho de um programador de computadores contar com a ajuda de um computador, que funciona perfeitamente conforme foi instruído?E, ampliando o conceito, staging = para aprovação final (verificar se está igual à spec de que falamos no fim, ou se ao colocar dados reais do produto ele fica mais feio do que o esperado, esse tipo de checagem) dev = para discussão sobre pessoas como desenvolvedores e features (para demo)
é assim que estamos usando.
Hum... acho que esse tipo de problema depende do tipo de serviço que está sendo desenvolvido.
Por mais que se teste, problemas podem acontecer, e é preciso avaliar se os usuários conseguem aceitar isso.
Para um software como o Facebook, em que mesmo se algo der errado as pessoas tendem a relevar, esse tipo de abordagem pode funcionar,
mas, se for uma infraestrutura de missão crítica ou um serviço pago, acho que é preciso fazer todo o possível para que não surjam problemas.