E Esse Negócio de Entrega Contínua?

O problema de entregar software

No dia-a-dia de uma equipe que desenvolve software, novas funcionalidades são adicionadas ao sistema atual, ou as já existentes são melhoradas. Assim, entregar uma nova versão é, basicamente, melhorar o sistema.

Quem faz a entrega do sistema geralmente (e idealmente) é o grupo de desenvolvedores. E frequentemente o processo de entrega é dominado pela equipe de desenvolvimento. Vamos citar um exemplo:

A implantação é manual e arriscada, então apenas um certo grupo de pessoas mais experientes fica responsável por colocar a nova versão no ar.

Nesse caso, mesmo que a equipe de Negócios da empresa decida uma data para entregar a nova versão, não seria uma decisão dela, mas sim da equipe de desenvolvimento, se eles poderiam realizar a implantação.

Se as entregas não são muito frequentes, ou não tem frequência nenhuma, fica mais difícil ainda decidir quando implantar.

É bem comum congelar a versão atual em momentos de riscos – durante uma grande promoção de vendas. Não existe previsibilidade e confiança no que vai acontecer quando uma nova versão for entregue.

Realizar entregas frequentes é ainda mais crucial para startups, pois novas ideias precisam ser testadas e avaliadas rapidamente.

Então tá, precisamos melhorar o processo de entrega para que a equipe de negócios tome as decisões sem depender da equipe de desenvolvimento. Como fazemos isso?

Voltando no tempo

Alguns anos atrás começamos a adotar testes automatizados, deixando a máquina fazer o que ela é boa, repetição, e deixando os humanos fazerem o que eles são bons, explorar.

Automatizar o processo de testes manual foi algo tão bom que inclusive evoluiu para o TDD, técnica onde os testes automatizados são feitos antes da implementação do código.

E não parou por ai. Depois de automatizar os testes, decidimos também por automatizar a execução deles. Assim, cada possível mudança do sistema passa por toda a suite de testes e a equipe recebe um feedback bem mais rápido.

Seguindo essa linha de raciocínio, a automação surge como uma resposta para esse problema. Automatizar a maneira como o software é entregue dá maior previsibilidade e confiança para o processo, fazendo com que a equipe de desenvolvimento não seja mais uma dependência.

De volta para o futuro

Nesse outro artigo, Automação Como Pontapé Inicial para Entrega Contínua, eu falo um pouco sobre como a equipe que faço parte conseguiu melhorar o processo de entrega utilizando automação.

Mas automatizar um script não é o suficiente! É preciso garantir que aquilo que será entregue tenha qualidade.

O servidor de Integração Contínua executa somente os testes locais, mas como saber se os serviços externos (software/hardware) estão funcionando? Como saber se esse código vai funcionar como esperado fora do ambiente de desenvolvimento?

Extrapolando a ideia de Integração Contínua, podemos pensar em uma Pipeline de Implementação (Build Pipeline):

A ideia é que cada pedaço de código, além de ser testado pelos testes automatizados, seja também implementado em um servidor de homologação. Dessa forma, não apenas o código é testado, mas também a infra estrutura e o banco de dados.

Ferramentas que controlam e versionam a configuração das máquinas e do banco de dados são muito importantes nesse ponto, pois elas facilitam voltar atrás e verificar onde estão os problemas.

Resumindo: cada commit gerado vai passar por toda a suite de testes, em seguida será implementado em um ambiente de homologação e testes de integração serão feitos lá, garantindo que tudo funcione direitinho.

Quer colocar a mais nova versão do sistema no ar hoje? Basta utilizar o último commit que passou por toda a Pipeline!

Dessa mesma forma fica fácil voltar a versão em caso de problemas graves em produção. Basta utilizar o último commit funcional e realizar uma nova implantação.

Entrega Contínua e Implantação Contínua

A diferença entre Entrega (Delivery) e Implantação (Deploy) Contínua é bem sutil, considere o exemplo a seguir:

Cada commit passa pelo Pipeline de Implantação e testes exploratórios são realizados, mas só no final da iteração é que a nova versão vai ao ar.

Nesse caso a Entrega do sistema é contínua, mas a Implantação não! Cada commit gera uma nova versão do sistema que passará por testes exploratórios, então teremos uma nova versão do sistema para entregar. Mas a decisão de implantá-la fica para o final da iteração.

A Implantação Contínua em ambientes pré-produção pode ser o primeiro passo para conquistar a confiança da equipe de negócios e convencê-los a adotar a Implantação Contínua em produção. Com um processo automatizado e confiável, fica mais fácil prever o que vai acontecer quando uma nova versão do sistema for ao ar.

É comum falar sobre Entrega Contínua como a técnica global que envolve todo o processo de entrega e implantação. Então a técnica da Entrega Contínua se diferencia da maioria das outras técnicas (como TDD, Programação em Par, etc.), pois requer que a equipe de Negócios aceite mudar e que seja parte da mudança.

O planejamento não será mais feito baseando-se no final da iteração ou quando a implementação puder ser realizada, mas sim em quando faz mais sentido que a nova versão seja entregue.

Empresas como Github fazem milhares de implantações por dia (Deploying at GitHub), o que não quer dizer que você deva fazer também. Implantar uma nova versão é uma decisão da equipe de Negócios e a Entrega Contínua faz com que isso seja realidade.

Qual é o truque?

Obviamente falar é bem mais fácil do que fazer. Existem vários problemas para se chegar em um estado onde é possível colocar uma nova versão do sistema no ar sem preocupações.

Como garantir que o testes são suficientes? Como migrar o banco de dados sem derrubar o sistema? E as dependências externas?

Nos próximos posts eu pretendo falar um pouco sobre as pedras que estamos encontrando no caminho da Entrega Contínua. Fique ligado para saber mais!