Quando se trata de entrega de scrum, as pessoas geralmente esperam uma execução de liberação após o final de um sprint. Isso significa diretamente após uma apresentação de demonstração bem-sucedida ao cliente.
Mas sempre me perguntei como isso poderia ser uma expectativa tão automática. Especialmente se você considerar as possíveis atividades abaixo que devem acontecer antes ou ao lado.
- Desenvolva e conclua todas as histórias dentro do sprint. Algumas podem ser concluídas antes, mas na maioria das vezes, as histórias são concluídas pouco antes do final do sprint. Talvez até depois da apresentação da demo, seja aberta aqui.
- Execute todos os testes agendados sobre o conteúdo do sprint para garantir que o código a ser lançado esteja pronto para produção.
- Acompanhe os bugs descobertos e corrija-os a tempo antes que o lançamento aconteça.
- Certifique-se de que o pipeline de implantação seja atualizado com o conteúdo mais recente e que o próprio pipeline seja confiável para executar.
- Execute o pipeline em todos os ambientes relevantes para colocá-los no estado mais recente do código e da perspectiva dos dados.
- Prepare notas de lançamento e comunique com o cliente o impacto do lançamento e o que exatamente mudará depois.
- Se relevante, sincronize com outras equipes scrum paralelas para garantir que o conteúdo dependente seja lançado simultaneamente. Nada deve faltar para garantir que seu conteúdo de lançamento funcione conforme o esperado.
- Além de tudo isso, passe por todas as cerimônias do scrum. Não apenas relacionados ao sprint atual, mas também aqueles direcionados para o próximo sprint (por exemplo, sessões de refinamento de histórias).
Agora imagine que o sprint tem duas semanas.
As atividades de liberação por si só levam tempo e pessoas para serem concluídas. Mas não pode demorar muito. Logo após o último dia do sprint, chega diretamente o primeiro dia do próximo sprint, e o círculo deve começar novamente.
A expectativa de liberação após cada sprint ainda parece tão automática?
últimas postagens
Liberar processamento de conteúdo
Se todos os processos dentro do sprint forem automatizados, existe a possibilidade de apenas “puxar o gatilho” e instalar a última versão do código em produção ao final de cada sprint. O problema é que nunca experimentei um estado tão perfeito da equipe scrum.
Se é realmente o caso de algumas empresas privadas de pequena escala, eu realmente as invejo. Mas a realidade no mundo corporativo é que uma equipe scrum não atingirá esse nível de maturidade. Pelo contrário, os processos de lançamento geralmente estão conectados com atividades demoradas que atingem a maior parte do sprint seguinte, afetando esse sprint do conteúdo e de todas as perspectivas de métricas. A liberação é apenas um ato estressante que ninguém na equipe está feliz em passar.
Então, eu estava atrás de descobrir o próximo melhor cenário para lidar com liberações.
A conclusão foi fazer de cada segundo sprint o Release Sprint. Aqui está o que isso significa.
Versão de código separada para o próximo lançamento
Trata-se de lidar com ramificações separadas no repositório GIT. Existem muitas maneiras de abordar o mesmo problema e todas elas podem ser bem-sucedidas. Mas para o propósito deste artigo, vou manter as coisas simples para demonstrar a abordagem e seu impacto.
Para causar o menor impacto possível nas atividades de desenvolvimento em andamento, é importante separar o conteúdo do próximo lançamento em uma ramificação separada. Vamos chamá-lo de Release Branch. Com isso, será resolvido:
- A equipe de desenvolvimento pode continuar em atividades e se fundir nas novas histórias da ramificação principal sem interrupção.
- Não há risco de que o conteúdo da versão seja afetado por modificações de código inesperadas da equipe scrum.
- As atividades de teste podem ser executadas em um espaço isolado. Aqui, serão introduzidas apenas as alterações necessárias para a resolução do teste.
- Como o pipeline de lançamento implantará na produção apenas o conteúdo do Ramo de lançamento, temos um processo claro e controle total sobre o conteúdo a ser lançado. Não pode acontecer que algum commit inesperado no branch Git quebre o código já testado.
Portanto, mantenha o conteúdo do próximo lançamento de lado e deixe-o concluir em um estado estável, pronto para o lançamento.
Cronometre os lançamentos para que funcionem repetidamente
Desisti da ambição de fazer o lançamento após a conclusão de cada sprint. Ficou super claro que isso não teria chance de funcionar. Pelo menos não com efeitos colaterais como:
- impactando o próximo conteúdo de desenvolvimento do sprint,
- sendo incapaz de estabilizar o conteúdo do lançamento,
- atualizando todas as atividades de teste necessárias, etc.
Portanto, o objetivo era executar o lançamento ao final de cada segundo sprint. Isso implicaria o seguinte:
- Um release sempre conterá histórias dos dois últimos sprints já concluídos. Como o release é realizado dentro do atual (sprint ativo), o conteúdo desse sprint ainda não está incluído no release.
- Há todo um tempo de sprint para as atividades de teste necessárias e correções de bugs serem concluídas.
- O proprietário da versão tem tempo suficiente para coletar informações relevantes sobre a versão (casos de teste, notas sobre a versão, etc.) com o sprint sem liberação. Dessa forma, eles podem operar basicamente autônomos e manter o restante da equipe de desenvolvimento trabalhando em novas histórias.
- Em caso de descoberta de bug, o proprietário da versão pode se conectar rapidamente com o desenvolvedor concreto para corrigir o problema e retornar ao conteúdo atual do sprint. Portanto, sempre deve haver algum tempo percentual alocado da capacidade da equipe para suportar essa correção de bug. Quanto exatamente pode ser descoberto ao longo do tempo.
Está claro que os usuários não obterão o conteúdo do sprint mais recente dentro da versão mais recente. Mas com o tempo, isso se tornará irrelevante. De qualquer forma, eles receberão dois sprints de conteúdo a cada próximo lançamento, após cada segundo sprint.
Isso parece um bom compromisso entre a satisfação da entrega rápida e o acompanhamento das atividades do Scrum sem perturbações significativas.
Executar a implantação de lançamento
Quando as atividades de teste, correção de bugs e prontidão do pipeline são concluídas com êxito, é um processo bastante direto executar o pipeline de produção e concluir o lançamento para produção.
Como é implantado a partir de uma ramificação autônoma, isso pode ser basicamente uma atividade despercebida e invisível. Ninguém precisa saber. Se for esse o caso, é a melhor implementação possível da implantação de lançamento.
Um pré-requisito para isso é ter criado um pipeline sólido de DevOps automatizado. Usado não apenas para implantar no ambiente de produção, mas também em todos os outros ambientes de nível inferior. Isso pode incluir desenvolvimento, sandbox, teste, garantia de qualidade, ambiente de desempenho, etc. Deve ser um clique para implantar todas as soluções para cada ambiente.
A liberação não deve ser um ponto de dor ou estresse. Ou um pesadelo que todos temem e ficam se preparando para esse dia durante uma semana. Não – em vez disso, se ninguém perceber isso, este é o melhor sinal de um lançamento bem-sucedido.
Mesclar novamente a ramificação de lançamento na ramificação de desenvolvimento
O Release Branch agora contém algum conteúdo especial que não existe no ramo regular de desenvolvimento contínuo. Está relacionado a todas as correções que foram implementadas durante o período de teste. Esse conteúdo precisa ser mesclado novamente no ramo de desenvolvimento para garantir que as correções permaneçam lá mesmo após o próximo lançamento.
Nesse ponto, o Release Branch mais recente serve como um código de produção pronto para reimplantação de emergência. Se um problema urgente de alta prioridade precisar ser resolvido logo após a implantação da produção, ele poderá usar essa ramificação. É simples pegar esse código e implementar a correção dentro dele. Esta ainda é a cópia exata do código de produção atual sem nenhum novo conteúdo inédito.
Por fim, assim que o novo período de teste começar, a ramificação da versão anterior poderá ser excluída e substituída por uma nova. O novo é criado novamente como uma cópia do ramo de desenvolvimento atual.
Estabeleça lançamentos regulares
E agora temos 😀 – um processo sólido para abordar o lançamento. A única coisa que falta é assumir o compromisso de mantê-lo regular. Neste caso, após cada segundo sprint.
Ao mantê-lo regular, na verdade preparamos o terreno para torná-lo mais fácil de realizar, principalmente porque:
- Se o lançamento ocorrer depois de um tempo não muito longo, não há muito conteúdo novo para instalar na produção. O incremento é pequeno e considerado estável.
- Agora, tanto conteúdo novo não significa muitas atividades de teste e criação de casos de teste. Menos comunicações, chamadas de acordo e colaboração com as partes interessadas sobre o que tudo precisa ser revalidado. Eles também concordarão que não faz muito tempo desde o último lançamento. Assim, menos importância é colocada nesta ação.
- A equipe vai se acostumar com esse ciclo; com o tempo, será uma parte natural da equipe.
- Como efeito colateral, os ambientes de desenvolvimento e teste geralmente atualizam os dados. De qualquer forma, isso é necessário para cada novo ciclo de teste. Portanto, não será apenas mais uma atividade programada para fazer. Ao contrário, uma ação que já faz parte do processo estabelecido. Essa mudança de perspectiva tem muita influência na atmosfera da equipe. Ninguém acreditaria nisso.
Conclusão
Este capítulo conclui minhas postagens anteriores sobre o tópico do ciclo de vida do Scrum. Além disso, é sobre o que provou estar funcionando na vida real.
Muitas vezes, as equipes começam de maneira ágil e fazem muitas coisas de maneira errada. Então eles evoluem, eventualmente, e começam a fazer as coisas de maneira diferente. Esta série pode ajudar alguns deles a fazer essa mudança mais rapidamente.
Essa abordagem de lançamento também não é a única viável, nem é sem problemas. Esses ainda existirão e as equipes terão que lidar com eles. Então melhore o que for possível e esqueça o que não tem sentido.
Mas pelo que sei, essa abordagem, embora simples, provou que a mudança é possível. De sprints caóticos e imprevisíveis a entregas mais estáveis com lançamentos regulares nos quais se pode confiar e planejar. E não requer uma metodologia especial e altamente complicada – apenas regras simples e vontade de seguir o plano.