Fazendo deploys sem dificuldade

O objetivo de cada equipe de software é entregar o produto acabado ao cliente final. Contudo, fazer isso é surpreendentemente difícil para muitas equipes.

Em um mundo perfeito, o ato do deploy de software para produção é sem dificuldade e confiável. Para saber se você vive de fato em tal mundo, tente responder à seguinte pergunta: alguém na equipe pode executar um único comando e implementar o aplicativo inteiro para a produção?

Se você pode dizer “sim” honestamente, parabéns e obrigado por ter vindo. Para o resto de nós, vamos considerar sobre como fazer seu deploy da produção sem dificuldade e confiável.

Faça o deploy, e faça de novo e frequentemente

Como em muitas coisas na vida, quanto mais você faz alguma coisa, mais fácil fica. Não é só isso: você também confia mais nos resultados.

Se quiser deploys de produção sem dificuldade e confiáveis, você precisa implementar seu aplicativo de produção o mais frequentemente possível. Na verdade, os fãs do Continuous Delivery defendem a implantação de cada mudança que você faz para o seu aplicativo imediatamente para o cliente final. Embora isso possa ser um pouco demais para algumas organizações (a maioria?), a capacidade de fazê-lo é bastante atraente.

A prática frequente é importante, mas não é suficiente. Com o risco de afirmar o óbvio, os passos que você tomar para implementar não devem mudar de acordo com o ambiente que você está implantando. Em outras palavras, o deploy no seu CI, teste, plataforma, regressão e, o mais importante, na produção deve ser a mesma. Os mesmos scripts devem rodar, os mesmos passos devem ser tomados etc. Profissionais Agile chamam isso de um caminho de implantação repetível.

Você pode estar pensando: “Bem, é claro que eu deveria fazer a mesma coisa em produção como em qualquer outro lugar”, “Por que não faria?”. Bem, o fato é que a produção é única. Ao contrário de todos os outros ambientes, você provavelmente vai querer minimizar ou eliminar o tempo de inatividade. Isso significa que você não pode simplesmente destruir tudo e reconstruir a partir do zero. A não ser que queira clientes irritados.

“Hit me baby one more time”

Uma maneira de lidar com esse problema é o deploy de um servidor existente. Em outras palavras, você pode apenas pegar o seu script de deploy automatizado, apontá-lo para um servidor de produção existente  e comece os trabalhos! O script, presumivelmente, passaria e atualizaria, removeria ou adicionaria todos os componentes necessários para o seu aplicativo.

Essa estratégia pode funcionar, mas só se você fizer exatamente a mesma coisa em ambientes de não produção. Se, por outro lado, você está implementando a partir do zero em qualquer outro lugar, essa estratégia não é boa, porque você está fazendo as coisas de maneira diferente em ambientes distintos.

O bom e velho troca-troca

Outra forma de fazer o deploy da produção é por meio de implementações A-B (Jez Humble e Dave Farley chamam isso de implementações azul-verdes). A ideia é que você levanta um ambiente idêntico ao de produção e simplesmente troca para ele. Essa abordagem é interessante, porque você não tem que se preocupar em derrubar servidores.

Essa abordagem faz com que você se aproxime muito do objetivo de ter um caminho de deploy que pode ser repetido, pois você pode literalmente fazer a mesma coisa em todos os ambientes.

Conclusão

Deploys de produção sem dificuldade são possíveis. Não só isso, elas valem o investimento. A receita é simples e requer apenas dois ingredientes: automação e consistência. Boa sorte.

?

Texto original disponível em http://tatiyants.com/painless-production-deployments/