Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Automação como Pontapé Inicial para Entrega Contínua

Muito se fala hoje em dia sobre Entrega Contínua, e existe uma boa razão para tal. Da mesma maneira que desenvolver código guiado por testes foi uma grande mudança nos últimos anos, a prática de implantar novas versões de um sistema continuamente está se tornando o próximo grande passo.

No entanto, mesmo com várias ferramentas que ajudam a implementar a Entrega Contínua, isto não é uma tarefa fácil. Nesse post vou mostrar como o time que faço parte está implementando Entrega Contínua, usando a automação como o primeiro passo para o nosso objetivo.

O Problema

Inicialmente, o processo de implantação utilizado no projeto era basicamente manual. Mesmo com um documento detalhando as tarefas, quase sempre que ocorria uma falha, era necessário que alguém com mais experiência identificasse e resolvesse os problemas. Além disso, o documento era alterado a cada iteração, contendo scripts que precisariam ser executados para resolver problemas locais. Isto tornava o processo ainda mais caótico.

Outro grande problema era que por ser muito frágil, o processo tomava muito tempo e as implantações precisavam ocorrer em um período de baixa utilização do sistema. O que significa que a equipe precisava atualizar o sistema durante a noite. Hora de mudar! O time decidiu investir em melhorar esse processo. E quando eu digo "o time" realmente me refiro a todos os papéis do projeto, não apenas ao grupo de desenvolvedores. Coletivamente nós fizemos pesquisas sobre o que poderia ser melhorado e como. Trabalhar junto com os gerentes e o cliente foi crítico para prover visibilidade aos gerentes seniores. O problema então deixou de ser do time e se tornou algo que a companhia toda se preocupou.

Para dar um pouco mais de contexto sobre o projeto, a base de código tem por volta de 6 a 7 anos e iniciou com uma das primeiras versões do framework Rails. Atualmente utilizamos Ruby 1.8 e Rails 2.3. O ambiente de produção é localizado em um data center privado e tem mais de 20 máquinas com tarefas dedicadas, como executar o servidor web, armazenar o banco de dados, etc. Todas as configurações são gerenciadas utilizando Puppet, que é executado a cada implantação. O time possui iterações de 3 semanas e realiza uma implantação ao final de cada uma delas.

Solução: parte 1

O primeiro passo de melhorias foi automatizar o processo de deploy. Depender de um processo manual e que sofre mudanças constantemente era um grande problema. Nós começamos a fazer com que a implantação do sistema fosse tão fácil quanto executar um script de uma linha. A automação iniciou desde pegar a Git tag da versão do código a ser implantado, até executar os scripts específicos de cada iteração de maneira transparente. Ao final da primeira fase de melhorias nós tivemos um script de implantação que com um simples comando validava o estado atual do sistema, atualizava código e banco de dados e verificava que o sistema estava em um estado consistente. Entretanto, mesmo com um deploy automatizado, o processo ainda era não confiável. Geralmente era necessário terminá-lo manualmente devido a falhas no meio da execução.

Solução: parte 2

Então começamos a segunda fase de melhorias - mudando todo o script de implantação, dividindo-o em passos, onde cada passo seria atômico. Assim, em caso de falhas nós não precisaríamos reiniciar todo o processo, apenas do ponto de falha em diante. Esta mudança ajudou a reduzir a complexidade do script e tornou-o bem mais rápido. Nós também investigamos os problemas mais comuns durante uma implantação e os consertamos de vez.

Resultado?

Um deploy que geralmente ia de 5 a 6 horas, com um máximo de 10 horas, foi para 2 horas ao final da segunda fase de melhorias. A gerência do projeto e da empresa ficaram muito contentes e isto aumentou a confiança do time.

O próximo passo para chegar à Entrega Contínua será dividir mudanças de código, dados e infraestrutura, para que seja possível entregar novas versões do sistema sem tirá-lo do ar. Existem várias técnicas para resolver esse problema, e atualmente estamos avaliando o contexto da equipe para escolher a solução que se encaixe melhor. Fique ligado para saber mais.

Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.

Atualize-se com nossos insights mais recentes