Eu posso até ser pedante, mas estou aqui para te dizer que a implementação contínua é um equívoco total. É discreta. Um verdadeiro processo contínuo teria o código fluindo naturalmente de seu cérebro, através de seus dedos, de teclas por teclas, para a produção, por meio de algum fluxo bizarro de consciência.

Agora que tenho que sair do caminho, eu vou te dar a definição comum, que é que você envia mudanças em uma base commit-por-commit, ou, alternativamente, com a frequência que você desejar. O que a maioria das pessoas pensa é em push-per-change, o que muitas vezes não é realmente o caso.

Na prática, a maioria das configurações de implementação contínua é automatizada, não automática. Isso significa que, embora cada passo desde o commit do código até o ready-to-push possa ser automatizado, no final do dia, há algum tipo de botão grande e vermelho ou uma linha de script ou bot de IRC que você ativa para implementar.

Por que eu deveria querer fazer uma implementação contínua?

O objetivo é minimizar a quantidade de trabalho necessária entre terminar uma ideia e torná-la real. Esse sim é um objetivo digno.

Outro benefício é que a construção das ferramentas, processos e habilidades necessárias para a implementação contínua vai tornar o seu trabalho melhor.

Boas práticas para implementação contínua

Eu fiz uma lista de práticas em uma palestra e as chamei de “requisitos”. Laura Beth Denker me ligou sobre isso e disse que essas coisas não são verdadeiros requisitos para fazer implementação contínua, porque as pessoas fazem isso com nenhum desses requisitos atendidos. Ela está certa. Deixa eu sugerir que seria uma boa ideia atender a alguns, se não todos, antes de adotar implementação contínua. A maioria dessas práticas é uma boa ideia em qualquer caso.

As práticas nas seções seguintes não são todas abrangentes, e tenho certeza de que existem práticas ótimas que desconheço.

Integração contínua (CI)

Esta é a prática de manter o terreno de mudanças do desenvolvedor em um sistema de controle de versão compartilhado à medida que são concluídas. (A versão original, em Extreme Programming, diz “várias vezes ao dia”, mas a velocidade é irrelevante em minha opinião). CI presume que você está usando uma VCS. Você está, né? Uma vez que o GitHub fez do controle de versão uma commodity, não há desculpas para não ter um repositório fonte.

Build-on-commit

“Mas estou escrevendo código em PHP/Python/Ruby, e eu não preciso construir nada. Isso é para linguagens compiladas”. Pode ser verdade que, em seu ambiente, a parte de construção do processo seja um NOOP, no entanto, pode envolver medidas como:

• Redução de CSS e JS
• Execução de um script de localização para combinar templates com arquivos de string
• Converter seu código dinâmico a algum tipo de formato intermediário

O resultado líquido de um processo de construção como esse é cuspir na outra extremidade de um artefato de construção que será implementado.

Teste-on-commit

É aqui que você adota aquele “construir e executar” nos testes. Testes. Sim, eu disse isso. Eu espero, sinceramente, que esta parte do seu processo não seja uma NOOP. Existem ótimas ferramentas para isso agora. Minha equipe usa Jenkins, e várias pessoas gostam de Travis CI.

Recentemente, temos executado testes automaticamente sobre requisições pull usando Leeroy. Travis CI faz isso também. É tão bom evitar uma revisão do código, porque eu posso ver que a sua requisição pull não passa nos testes!

Boa cobertura de teste

Ter 100% de cobertura de teste unitário é bom, mas pode tornar os desenvolvedores confiantes além da conta. Cobertura de teste completa não abrange o teste de integração, ou testes de desempenho e, em um mundo ideal, sua automação faria as duas coisas. A coisa mais importante é saber o que seus testes abrangem e ter uma avaliação realista do que são as falhas e do nível de risco.

Um ambiente de teste que reflete a produção

A própria máquina do desenvolvedor é um ambiente de preparo horrível. Obtenha uma de verdade. Traga-a o mais perto possível da produção. O maior problema que vejo na realização de ambientes de teste é o que eu chamo de “caixa única de falha.” No teste, você tem uma máquina. Em produção, você tem, digamos, dez web heads, uma DB master, três DB slaves, algumas máquinas Redis ou Memcache, e uma queue, todos rodando em servidores diferentes. Nesse ambiente, você terá falhas.

Eu fui atingida por isso centenas de vezes, e ainda sou. Na verdade, isso aconteceu comigo recentemente, quando nossos manifestos puppets PostgreSQL eram sempre um pouco diferente em teste e em produção. Não seja eu. Faça dos seus erros o seu próprio romance.

Configuração gerenciada

Falando de Puppet você deve usar algo para gerenciar a configuração de suas máquinas. Puppet, Chef, CFEngine – escolha um.

Single-button deployment

Você deverá ter feito um single-button deployment para todas as máquinas em sua infraestrutura. (Você também deve ser capaz de implementar para indivíduos ou grupos.) Novamente, existe uma tonelada de ferramentas que vai fazer isso por você. Escolha uma, ou construa a sua própria.

Plano de falha

Você precisa de um plano para o que vai fazer se as coisas derem muito errado. Na prática, existem duas abordagens básicas:

• Plano de reversão: Isso pode ser tão simples como ser capaz de implementar uma compilação anterior. Lembre-se: você precisa de migrações reversas de dados.
• Recurso de sinalização: Construa o seu código para que você possa ativar e desativar as características, ou ligá-las para os subgrupos de usuários (testadores beta, ou empregados, ou 10% aleatórios da população de usuários). Isso exige mais premeditação, mas é como testes de escrita – um investimento.

Rastrear, tendências e monitorar

Medir é fundamental para a melhoria do processo. Dos tempos de carregamento da página às conversões, a sockets TCP, cada medida fornece uma visão sobre algo. E, lembre-se, se você não tem boas ferramentas de visualização para sua informação, você tem apenas dados.

Excelente gerenciamento de código

Conheça as suas ferramentas, artesão. Pelo menos uma pessoa em sua equipe deve conhecer sua ferramenta de SCM por completo.

Altos níveis de confiança

Se você tem o desenvolvimento e as equipes de operações separados, ou mesmo se você tiver uma equipe de devs incrível, você não vai longe sem confiança. Não importa quando as coisas estão indo bem, e sim quando tudo se transforma em lixo e você está apagando incêndios. Então, comece a partir da premissa de que as pessoas são confiáveis. Confie nelas para fazer seus trabalhos. (E, se elas não conseguirem, oriente-as ou demita-as. É simples assim.) Não importa qual é o seu cargo. Vocês estão todos no mesmo time. Todos vocês querem a mesma coisa.

Avaliação de risco e de tolerância

Saiba quais são os seus riscos e tenha um nível adequado de tolerância. Se você está tentando construir algo com alta disponibilidade em tempo de atividade, você vai querer mais segurança antes da implementação, e pode ser que a integração contínua. Saiba quais partes do seu site são aceitáveis ​​para quebrar, e quais peças precisam estar bem, e aja em conformidade. Os requisitos de disponibilidade não são os mesmos em todos os componentes de um sistema. Administrar isso é a chave para sistemas resilientes.

Excelente revisão de código

A revisão de código tem o seu lugar. Em muitos projetos em que trabalho, cada linha de código é revisada. Em coisas que são menos missões críticas ou têm equipes muito experientes, isso acontece menos. A revisão de código é útil tanto como de desenvolvimento (“Eu sei  uma maneira melhor de fazer isso”) e cópia de edição (“Você cometeu um erro de digitação crítico aqui”).

Por fim

Se depois de ler esse artigo você só se lembrar de duas coisas, eu gostaria que fossem estas:

1. Você deve desenvolver a capacidade para a implementação contínua, mesmo se você nunca pretende fazê-la.
2. Assim como em tudo na vida, a única forma de ficar bom em implementação é implementar muito.

***

Artigo de Laura Thomson, traduzido pela Redação iMasters. Publicado originalmente em http://webadvent.org/2012/continuous-deployment-practices-by-laura-thomson