A falta de um processo de release simplificado e confiável aumenta o risco de falhas durante a implantação de novas versões.

[eduardohyodozup]

Summary

Desenvolvedores executam deploy de aplicações e tem como opção algumas estrategias de deploy, como Blue/Green e Rolling. Contudo essa estrategias exigem tempo de rollout dentro do parque dos usuarios que usa aquela aplicação. Assim, colocar pacotes de software em producao leva muitos passos e tempo do time para lidar com isso. Além disso o rollout passa muitas vezes da janela de gmud do deploy, caso aconteça um incidente o dev tem que pedir gmud emergencial e executar o processo de Breaking Glass para ajustar a situação. Contudo, esse processo poderia utilizar estrategias mais automatizadas/simplificadas de rollback.

Goal

Mais velocidade para um desenvolvedor para lidar com gestaod de release

Possible Features

Metrics

Frequency

Média:

Coverage

Alta:

[edwardmonteiro]

Aqui sao duas dores ?

[eduardohyodozup]

Aqui sao duas dores ?

troquei o titulo, por favor de uma olhada se ficou mais claro. Queria sim focar em uma dor somente

[cadupereira-zup]

@eduardohyodozup a descrição está extremamente simples. Não são trazidas evidências da dor e tão pouco resultados esperados ao lidar com ela. Melhorar a velocidade de rollback não me parece algo que sequer seja medido atualmente. Talvez algo como MTTR faça mais sentido.

[marceloamaralzup]

@eduardohyodozup isso passa pela possibilidade de o breaking glass ser adotado como uma estratégia para realizar mudanças na release? outra dúvida: se o processo prejudica o dev, como você apontou, quais são esses riscos, em qual dimensão e com que frequência? recordo que em uma reunião sobre ALM, há um tempo, essa bola foi levantada.