Integração contínua, entrega contínua e implantação contínua: conheça melhor essas 3 disciplinas

A entrega contínua e a implantação contínua são elementos que ajudam a compor as disciplinas básicas do DevOps. No artigo de hoje vamos falar um pouco delas e da entrega contínua. Em artigos anteriores nós já falamos o que é integração contínua e o que é implantação contínua, se você não viu, confere lá!

A integração contínua é a entrega contínua que passo a seguinte, e a implantação contínua é a possibilidade de oferecer soluções em uma velocidade muito alta. Elas são as três disciplinas básicas que compõe talvez um fundo do que seria DevOps.

Por que estamos falando isso? Estamos falando isso, pois elas vem a partir das práticas da entrega contínua um livro do JEZ HUMBLE que foi publicado no ano de 2009, que visa a trazer justamente uma série de técnicas, inclusive ferramental, para suportar esse tal de contínuo. DevOps se sustenta a partir de uma das vertentes que é esse corpo de conhecimento que o Jez Humble coloca a mais de 10 anos atrás, através deste livro que inclusive se chama Entrega contínua.

É uma definição um pouco nebulosa se pararmos para pensar. Ela foi mudando durante o passar do tempo e é muito dependente das técnicas e abordagens específicas a partir das tecnologias que a solução pede. A entrega contínua visa a ter soluções implantáveis a qualquer momento com uma frequência muita alta.

Se pensarmos qual é a diferença de uma entrega contínua entre a versão 1 e 2, é uma pequena diferença na hora de construir o software. E essa diferença veio de onde? Da integração contínua!

A integração contínua nos nutre com uma série de versões vindas de diferentes desenvolvedores. Se os diferentes desenvolvedores conseguem contribuir, fazer commit, com uma maior frequência, eu tenho a disposição a possibilidade de avaliar também com maior frequência os testes de aceitação. Os testes de aceitação são na verdade a possibilidade de implantar em um ambiente intermediário e submeter essas soluções a uma bateria de testes, sejam eles funcionais ou não funcionais. Com isso consigo homologar essa versão pronta para ser implantada.

Então a entrega contínua leva em consideração todo o processo de disponibilizar uma versão que poderia ser implantada a qualquer momento.

Para conseguir trabalhar estes conceitos mencionados acima, eu necessito automatizar os testes de aceitação. Ou seja, eu não consigo fazer entrega contínua com um exército de gente testando a aplicação de uma tal maneira a tentar encurtar o prazo.

Eu dependo dos testes de aceitação, dependo de uma infraestrutura como código, ou da virtualização, ou de cloud que me permita rapidamente disponibilizar um ambiente similar ao de produção para submeter essa nova versão que está sendo disponibilizada. Um ponto fundamental a ser atendido é que essa versão não necessariamente será uma release.

Uma release, do ponto de vista clássico, é uma solução que encapsula dentro dela uma série de funcionalidades prontas, ou seja, eu submeto inclusive ela ao gerenciamento da mudança. Gerenciamento da mudança que vai avaliar o porquê está sendo colocada essa funcionalidade e se ela passou por todo um script de testes que permita adquirir a confiança de que uma vez implantada em produção, ela tenha um impacto mínimo, pelo menos um risco controlado.

Claramente para ter funcionalidades prontas, eu demoro mais tempo para desenvolver. Quando falamos em DevOps, neste conceito de entrega contínua, eu não estou entregando soluções ou funcionalidades prontas, eu estou na verdade evoluindo essas funcionalidades através de várias versões. Ou seja, eu não estou disponibilizando uma release.

E aí vêm uma outra quebra de paradoxo em relação a como entender essa versão e como vou conseguir avaliar ela. Nós precisamos justamente para conseguir tratar esse trânsito da entrega contínua como implantação contínua, que seria o passo seguinte, uma vez que está homologada agora eu posso implantar.

Para isso se pode discutir várias técnicas de implantação em paralelo, ambientes em paralelo, para conseguir trabalhar altas disponibilidades sem criar janelas de indisponibilidade. Mas essa versão que está sendo disponibilizada nessa entrega contínua, precisa ser avaliada de tal maneira a conseguir esse trânsito contínuo.

Aí vêm a importância de trabalhar a governança, que visa controlar o processo de evitar impactos negativos em produção. Através de testes efetivos, a partir da disponibilização de ambientes de maneira controlada, eu posso provisionar respostas a tentar trazer essa estabilidade nesse processo todo. Ou seja, um dos pontos fundamentais é que se a release concentra bastante código a partir de um trabalho de vários dias, de várias semanas ou eventualmente de vários meses de trabalho, na realidade tenho uma bomba relógio dentro dela, pois tenho muita atividade concentrada e uma fragilidade grande na hora de implantar.

Quanto mais demora, quanto mais demoro acúmulo código mais risco tenho dentro dele. O risco consegue ser diminuído na medida que consigo implantar com maior frequência. E aí vem o conceito que sustenta isso que é a integração contínua que foi visto em um artigo anterior.

Conclusão

Então o que estamos fazendo agora? Estamos trabalhando a expansão, ou a seguinte etapa da integração contínua, que é conseguir validar das diferentes formas que temos com teste funcionais, testes não funcionais, performance, capacidades, resiliência, recuperação etc.

Tudo o que faz parte da própria validação desta solução que me permite claramente ter um certo grau de precisão ou de risco controlado a partir da sua implantação. Um adendo, quando vou transitar para a produção, executar o que se chama de implantação contínua, eu estou inclusive entrando com ambientes paralelos, para que se ocorra algum problema eu tenho o meu ambiente backup pronto para absorver essa recuperação de forma rápida.

Veja que esses elementos são os básicos que sustentam essa primeira maneira que é proposta pelo gene kim no livro projeto fênix e manual devops que sustenta as boas práticas do devops.

Você quer saber mais sobre o assunto? Conheça nosso treinamento internacional EXIN DevOps Professional! Nele o aluno conhecerá as três maneiras devops e todas as suas práticas.

Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!