O modelo de implementação de entrega contínua

Aprendeu sobre as muitas desvantagens do "epic deployment" como modelo de entrega de software, mas saber o que não funciona bem é apenas metade da batalha. Nesta unidade, aprende sobre a alternativa a esse método monolítico e como este pode promover o seu objetivo de maior fiabilidade.

Também vale a pena distinguir dois termos relacionados que por vezes são usados de forma intercambiável:

• Entrega contínua: todas as alterações que passam nos testes automatizados estão prontas para serem implementadas em produção, mas o lançamento em produção é bloqueado por uma aprovação manual.
• Implementação contínua: todas as alterações que passam nos testes automatizados são automaticamente lançadas para produção, sem barreira manual.

Ambos dependem das mesmas bases (integração frequente, testes automatizados, pipelines repetíveis). Este módulo foca-se nessas fundações partilhadas.

O que é a entrega contínua?

A entrega contínua é um método pelo qual cada alteração na sua base de código é mantida libertável de forma mais rápida, menos stressante, menos arriscada e mais reproduzível. Em vez de transformar cada implementação ou atualização de software num evento épico, a entrega contínua transforma-a numa experiência rápida, rotineira e previsível que acontece a pedido.

• Frequência de implantação: com um modelo de entrega contínua, as implantações acontecem com frequência. A cadência pode ser mensal, semanal, diária ou até horária. Essencialmente, são implementadas alterações mais pequenas e concentradas, com mais frequência.

• Desencadeado por commit de código: Em vez de esperar por uma janela de lançamento agendada com muita antecedência, o pipeline de entrega começa quando o código é confirmado. Este código pode ser software, infraestruturas ou mesmo algo como as configurações de software. Cada alteração é então construída, testada e mantida pronta para lançamento. Dependendo dos controlos da sua organização, a promoção para produção pode ainda acontecer mais tarde, após uma aprovação.

• Teste automatizado: Você pode usar o teste automatizado integrado não apenas para testar o código, mas também para fornecer feedback rápido sobre os resultados desses testes. É esse feedback rápido que permite que você itere e se recupere de testes com falha rapidamente.

  Depois que seu código tiver sido testado, você poderá testar a implantação de ponta a ponta em uma série de ambientes em estágios, como teste, controle de qualidade e assim por diante. Implementar progressivamente as suas implementações através destes ambientes torna-se parte integrante da experiência de implementação.

• Registros históricos: você não só deseja um registro histórico das atividades de implantação, mas também pode reconciliar seu ambiente de produção a qualquer momento. Quer entender qual implementação criou o seu ambiente de produção atual. Com esse conhecimento, você pode rastrear coisas como configurações, resultados de teste e o próprio código até a solicitação pull individual que disparou a implantação.

Objetivos de implementação

Agora que sabe como funciona a entrega contínua, considere os objetivos que a entrega contínua e outras práticas DevOps o ajudam a alcançar ao implementar soluções de software.

Objetivo 1: Reduzir o estresse envolvido com a implantação de serviços e, ao mesmo tempo, aumentar a confiabilidade desses serviços

Reduzir o stress das implementações de software e infraestrutura melhora a experiência diária dos engenheiros que as gerem. O consequente aumento da fiabilidade também beneficia os utilizadores finais, que registam menos falhas e perturbações.

Objetivo 2: Reduzir o tempo entre quando você sabe que uma alteração é necessária e quando essa alteração é implantada na produção

Por exemplo, suponha que identificou um defeito de código com impacto nas receitas e sabe exatamente como o corrigir. Com práticas DevOps maduras, o caminho do commit à produção é curto e previsível. A alteração é construída, testada automaticamente nos ambientes relevantes e preparada para lançamento em poucos minutos. Uma vez dada a aprovação necessária, pode ser promovido para produção em vez de ser retido para uma janela de lançamento futura.

Objetivo 3: Reduzir o tempo entre ter uma ideia e entregar software utilizável

Este objetivo é semelhante ao anterior, mas foca-se na inovação em vez de correções. Quanto tempo demora a concretizar uma nova ideia? Com este modelo de implementação, pode integrar um novo conceito num sistema de produção com a confiança de que a adição não irá quebrar nem prejudicar o sistema atual. Essa confiança permite-lhe entregar novas funcionalidades rapidamente.

Resultados da implementação

Os objetivos discutidos nesta unidade não são apenas aspirações teóricas, são mensuráveis. Desde 2014, a equipa de Investigação e Avaliação DevOps (DORA) tem publicado anualmente investigação sobre o Estado do DevOps sobre o desempenho na entrega de software. Nos últimos anos, este trabalho foi publicado como o Relatório Accelerate State of DevOps. O modelo atual da DORA acompanha cinco métricas de entrega:

• Frequência de implantação
• Mudança no prazo de entrega
• Taxa de falha na mudança
• Tempo de recuperação de falha de implementação
• Taxa de reformulação do desdobramento

Ano após ano, a investigação mostra que equipas com melhor desempenho realizam alterações com mais frequência, passam do commit para a produção mais rapidamente, recuperam de implementações falhadas mais cedo e passam menos tempo a corrigir problemas relacionados com a implementação. Para a investigação mais recente e definições de métricas, consulte as métricas de entrega de software do DORA.

Estes resultados validam a ideia de que as práticas de implementação são importantes.