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. Slots de implantação são aplicações ativas que têm os 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 está o desempenho da equipa?

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

$${Rácio\ de\ atividade\ =\ }{\dfrac{Tempo\ de\ processo}{Tempo\ total\ de\ lead}}$$

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 requerido 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 a 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 em de teste todos os dias às 3:00 da manhã.

  • O tempo que leva para colocar a compilação testada em Staging. O tempo necessário passou de dois dias para zero dias.

    A equipa 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 de de preparação 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 aprova, Tim pode liberar as alterações do ambiente de testes para o ambiente de produção.

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

$${Razão\ de\ atividade\ =\ }{\dfrac{5\ dias}{10\ dias}}{ = 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.

Saiba mais

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