Resumo
Nesse módulo, você definiu um padrão de implantação como uma forma automatizada de distribuir facilmente novos recursos de aplicativos para seus usuários. Um bom padrão de implantação pode ajudá-lo a minimizar o tempo de inatividade. Ele também pode permitir que você distribua novos recursos progressivamente para seus usuários.
Você pode escolher entre vários padrões de implantação. O padrão de implantação escolhido depende dos motivos para a implantação e dos recursos. Você tem testadores canário no local? Você empregará um lançamento às escuras e escolherá testadores que não sabem que são testadores? Se você tiver um conjunto confiável de testadores que aumenta progressivamente de um pequeno conjunto para um conjunto maior, poderá escolher uma implantação de exposição progressiva. Ou, se você quiser saber se uma versão funciona melhor do que outra, escolha um teste A/B.
A equipe da Tailspin optou por implementar o padrão de implantação azul-verde, usando slots de implantação no Serviço de Aplicativo do Azure. Os slots de implantação são aplicativos dinâmicos com nomes de host próprios. A equipe pode trocar dois slots de implantação. Ao trocar, ela pode promover alterações para a produção instantaneamente. Embora a equipe ainda não esteja pronta para lançar o site para o público, ela comprovou que pode lançar novos recursos para os usuários sem gerar tempo de inatividade.
Como um bônus, nesse módulo você também aprendeu a efetuar roll forward de uma alteração não intencional ao reverter um commit do Git e efetuar push da alteração revertida pelo pipeline.
Como a equipe está se saindo?
No módulo Avalie seu processo de desenvolvimento de software, Clara fez um exercício de mapeamento de fluxo de valor. O exercício ajudou a equipe a analisar seu processo atual de ciclo de lançamento.
Lembre-se de que a taxa de atividade (ou eficiência) é o tempo do processo dividido pelo prazo de entrega total:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
A equipe da Web da Tailspin inicialmente usou essa métrica para determinar que tinha uma eficiência de 23%.
Primeiro, a equipe reduziu algumas ineficiências ao implementar a CI (integração contínua). Ao aplicar a CD (entrega contínua), agora ela reduziu ainda mais as ineficiências.
Nos roteiros de aprendizado anteriores, a equipe reduziu:
O tempo necessário para configurar o controle do código-fonte para os novos recursos. O tempo necessário passou de três dias para zero dia.
A equipe conseguiu esse aprimoramento movendo o controle do código-fonte centralizado para o Git, uma forma de controle do código-fonte distribuído. Ao usar o controle do código-fonte distribuído, ela não precisa aguardar que os arquivos sejam desbloqueados.
O tempo necessário para entregar o código para Marina, a testadora. O tempo necessário passou de dois dias para zero dia.
A equipe conseguiu esse aprimoramento movendo o processo de build para o Azure Pipelines. O Azure Pipelines notifica automaticamente a Marina quando um build está disponível. Os desenvolvedores não precisam mais atualizar a planilha da Marina para notificá-la.
O tempo que leva para Marina testar os novos recursos. O tempo necessário passou de três dias para um dia.
A equipe conseguiu esse aprimoramento pelo teste de unidade do código. Eles executam testes de unidade sempre que uma mudança percorre o pipeline de build, de maneira que menos bugs e regressões cheguem até a Marina. A carga de trabalho reduzida significa que Marina pode concluir cada teste manual mais rapidamente.
O pipeline de lançamento que você e a equipe criaram nesse roteiro de aprendizagem reduziu:
O tempo necessário para levar o build para a fase de teste. O tempo necessário passou de três dias para um dia.
A equipe conseguiu isso usando um gatilho de agendamento para fazer a implantação em Teste todos os dias às 3h.
O tempo necessário para levar o build testado para a fase de preparo. O tempo necessário passou de dois dias para zero dia.
A equipe conseguiu esse aprimoramento adicionando testes de interface do usuário do Selenium, uma forma de teste de funcionalidade, à fase Teste. Esses testes automatizados são muito mais rápidos do que as versões manuais.
O tempo necessário para que o build aprovado passe do Preparo para o estado ativo. O tempo necessário passou de um dia para menos de um dia.
A equipe conseguiu esse aprimoramento adicionando verificações manuais de aprovação ao pipeline. Quando a gerência aprova, Pedro pode liberar as alterações do Preparo para o estado ativo.
Essas alterações reduzem o prazo de entrega total de 22 dias para 10 dias. Quando substituímos esses números na equação:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0.50}$$
Multiplique o resultado por 100% e obtemos uma redução de 50%.
Embora sempre haja espaço para aprimoramento, essa mudança é uma vitória para a equipe. Não apenas os clientes obtêm valor mais rapidamente, a equipe da Tailspin agora gasta menos tempo aguardando e mais tempo fazendo o que mais gosta: entregando recursos que sabem que seus clientes vão adorar.
Saiba mais
Use estes recursos adicionais para saber mais sobre o Serviço de Aplicativo, os slots de implantação e a reversão das alterações: