Frequentemente, deploys precisam ser “desfeitos” em função de instabilidades causadas por features com problemas. Essas instabilidades são causadas, muitas vezes, por erros de implementação. Outras vezes, por condições inesperadas no ambiente produtivo que está, por alguma razão, incompatível com os ambientes de desenvolvimento e de homologação.
Quando um problema acontece em produção, é comum que seja realizado um rollback para restaurar a aplicação a um estado válido. Infelizmente, muitas vezes, features sem problema algum, exceto terem sido colocadas em ambiente produtivo no mesmo deploy de uma feature ofensora, acabam sendo afetadas. Em função disso, ocorre aumento do lead time e comprometimento do Velocity.
[tweet]Boa parte dos rollbacks que observamos em nossos clientes poderia ser evitada com a prática disciplinada de desacoplar os processos de deploy e release.[/tweet] No deploy ocorre a distribuição de artefatos necessários para o funcionamento de um sistema no ambiente produtivo. Já o release implica na disponibilização de features, direta ou indiretamente, para os usuários do sistema.
Feature Toggle
Feature toggles are essentially variables that are used inside conditional statements. Therefore, the blocks inside these conditional statements can be toggled ‘on or off’ depending on the value of the feature toggles. A block of code which has been toggled ‘off’ is similar to it being commented out. This allows developers to control the flow of their software and bypass features that are not ready for deployment.
The main usage of feature toggles is to avoid conflict that can arise when merging changes in software at the last moment before release. Although this can lead to toggle debt. Toggle debt arises due to the dead code present in software after a feature has been toggled on permanently and produces overhead. This portion of the code has to be removed carefully as to not disturb other parts of the code.
A desvinculação de release e deploy autoriza a distribuição de artefatos mais cedo e de forma contínua, permitindo antecipar, inclusive, dificuldades para a operação, mitigando riscos. Quando uma feature está pronta, pode ser facilmente habilitada pela sua feature toggle. Se algo der errado em produção, no lugar de um rollback, bastará desabilitar o toggle para retornar o sistema ao estado anterior, com prejuízos mínimos.
Em ambientes operacionais mais complexos, como ecommerce, a adoção disciplinada de feature toggles facilita a realização de testes A/B. Dessa forma, além de problemas operacionais, podemos testar aspectos do negócio e verificar se as features tem recepção favorável dos usuários.
Teste A/B
A/B testing (also known as bucket testing or split-run testing) A/B Testing is a user experience research methodology. [1] A/B tests consist of a randomized experiment with two variants, A and B.[2][3] It includes application of statistical hypothesis testing or “two-sample hypothesis testing” as used in the field of statistics. A/B testing is a way to compare two versions of a single variable, typically by testing a subject’s response to variant A against variant B, and determining which of the two variants is more effective.
A separação dos processos de deploy e release com feature toggles, reduz a complexidade do controle de versão do código permitindo que código seja integrado a branch principal com frequências maiores. Sempre que uma feature for considerada estável, poderá ter sua feature toggle removida e, artefatos alternativos podem ser finalmente removidos do ambiente produtivo.
O desacoplamento das atividades de deploy e release podem ter impacto gigantesco sobre a produtividade. Além disso, são fundamentais em processos de modernização de aplicações, sobretudo para estilos arquiteturais mais leves.
Ótimo artigo, como sempre, Elemar.
Só uma dúvida na frase:
“No deploy ocorre a distribuição de artefatos necessários para o funcionamento de um sistema no ambiente produtivo. Já o release implica na disponibilização de features, direta ou indiretamente, para os usuários do sistema.”
Na primeira vez que li gerou certa confusão, já que eu tinha em mente uma seperação entre os processos, mas entendia “release” como a liberação da versão em si, com geração de artefatos ou o que for necessário, enquanto o “deploy” seria a aplicação desses artefatos gerados no ambiente produtivo, como comentado no artigo também.
Na abordagem do artigo, então, é desconsiderado esse passo antes do “deploy” e apenas considerando o “feature toggle” como determinante da “liberação” da versão para o usuário final, seria este o entendimento?