Resumo

  • 3 minutos

Neste módulo, você definiu um padrão de implantação como uma maneira automatizada de implementar sem problemas 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ê implemente 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 da implantação e dos recursos. Você tem testadores de canário no lugar? Você vai empregar um lançamento escuro e escolher testadores que não sabem que são testadores? Se você tiver um conjunto confiável de testadores que aumente progressivamente de um conjunto pequeno para um conjunto maior, poderá escolher uma implantação de exposição progressiva. Ou, se você quiser saber se uma versão tem um desempenho melhor do que outra, você pode escolher o teste A / B.

A equipe do 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 ativos que têm seus próprios nomes de host. A equipe pode trocar dois slots de implantação. Ao trocar, eles podem promover mudanças na produção instantaneamente. Embora a equipe não esteja pronta para lançar seu site para o público, eles provaram que podem obter novos recursos para seus usuários sem incorrer em tempo de inatividade.

Como bônus, neste módulo você também aprendeu como reverter uma alteração não intencional revertendo uma confirmação do Git e, em seguida, empurrando a alteração revertida através do pipeline.

Como se está a sair a equipa?

No módulo Avaliar seu processo de desenvolvimento de software existente, Mara 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 de processo dividido pelo tempo de entrega total:

$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$

A equipe da web do Tailspin inicialmente usou essa métrica para determinar que eles eram 23% eficientes.

A equipe primeiro reduziu algumas ineficiências quando implementou a integração contínua (CI). Ao aplicar a entrega contínua (CD), eles reduziram ainda mais as ineficiências.

Em percursos de aprendizagem anteriores, a equipa reduziu:

  • O tempo necessário para configurar o controle do código-fonte para novos recursos. O tempo necessário passou de três dias para zero dias.

    A equipe conseguiu essa melhoria mudando do controle centralizado do código-fonte para o Git, uma forma de controle do código-fonte distribuído. Usando o controle de código-fonte distribuído, eles não precisam esperar que os arquivos sejam desbloqueados.

  • O tempo que leva para entregar o código para Amita, o testador. O tempo necessário passou de dois dias para zero dias.

    A equipe conseguiu essa melhoria movendo seu processo de compilação para o Azure Pipelines. O Azure Pipelines notifica automaticamente a Amita quando uma compilação está disponível. Os desenvolvedores não precisam mais atualizar a planilha de Amita para notificá-la.

  • O tempo que o Amita leva para testar novos recursos. O tempo necessário passou de três dias para um dia.

    A equipe conseguiu essa melhoria testando seu código em unidade. Eles executam testes de unidade cada vez que uma alteração se move através do pipeline de compilação, para que menos bugs e regressões cheguem ao Amita. A carga de trabalho reduzida significa que a Amita pode concluir cada teste manual mais rapidamente.

O pipeline de lançamento que você e a equipe construíram nesse caminho de aprendizado reduziu:

  • O tempo necessário para colocar a compilação no estágio de teste . O tempo necessário passou de três dias para um dia.

    A equipe conseguiu isso usando um gatilho programado para implantar no teste todos os dias às 3:00 da manhã.

  • O tempo necessário para obter a compilação testada no preparo. O tempo necessário passou de dois dias para zero dias.

    A equipe conseguiu essa melhoria adicionando testes Selenium UI, uma forma de teste funcional, ao estágio de teste . Estes testes automatizados são muito mais rápidos do que as versões manuais.

  • O tempo que leva para obter a compilação aprovada do Staging para viver. O tempo necessário passou de um dia para menos de um dia.

    A equipe conseguiu essa melhoria adicionando verificações manuais de aprovação ao pipeline. Quando a gerência assina, Tim pode liberar as mudanças de Preparação para ao vivo.

Essas alterações reduzem o prazo total de entrega de 22 dias para 10 dias. Quando substituímos estes números na equação:

$${Atividade\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0.50}$$

Multiplique o resultado por 100% e obtemos uma redução de 50%.

Embora haja sempre margem para melhorias, esta mudança é uma vitória para a equipa. Não só os clientes obtêm valor mais rapidamente, como a equipa da Tailspin passa agora menos tempo à espera e mais tempo a fazer o que mais gostam: fornecer funcionalidades que sabem que os seus clientes vão adorar.

Mais informações

Use estes recursos adicionais para saber mais sobre o Serviço de Aplicativo, slots de implantação e reversão de alterações: