“A maioria das pessoas quando me escutam falar sobre deployment contínuo pela primeira vez, pensam que estou incentivando código de baixa qualidade ou um processo indisciplinado no desenvolvimento baseado em programação "cowboy". Muito pelo contrário, eu acredito que deployment contínuo requer uma enorme disciplina e pode melhorar a qualidade de software de forma grandiosa, através da aplicação de um rigoroso conjunto de padrões para toda e qualquer mudança feita, prevenindo regressões, indisponibilidades, ou que pontos chaves do negócio sejam afetados."
- Eric Ries, autor do bestseller A Startup Enxuta
O que é Entrega Contínua?
Entrega Contínua é uma disciplina de desenvolvimento na qual software é construído de tal maneira que o mesmo pode ser colocado em produção a qualquer momento.
Você está fazendo Entrega Contínua quando:
- É possível mandar o software para produção em qualquer momento de seu ciclo de vida.
- Manter tal capacidade de entrega para produção é prioridade sobre ao trabalho relacionado a novas funcionalidades.
- Qualquer pessoa pode ter feedback rápido e automatizado sobre quão pronto para produção seus sistemas estão sempre que uma mudança acontece.
- Você pode enviar qualquer versão de seu software para produção através do simples acionamento de um botão.
Definição desenvolvida pelo grupo de Entrega Contínua da Thoughtworks
Esta definição provavelmente parece menos "amedrontadora" que a maioria das ideias que você deve ter sobre Entrega Contínua. Ela não fala que toda mudança que consegue passar por verificações automatizadas irão realmente para produção. Ela apenas diz que o software está sempre em um estado no qual você pode mandá-lo para produção se quiser. Então onde está o medo? Vamos examinar alguns deles…
Medos de Agenda e Estado
Pode ser difícil para o pessoal de negócios entender parte do trabalho inicial em "entregabilidade" mas tal esforço gera uma métrica de negócio bem diferente e fácil de entender - verdadeira completude de funcionalidade.
Entrega Contínua tem uma definição inequívoca de pronto: "uma funcionalidade está pronta apenas no momento em que ela está entregando valor para seus usuários". Para que uma funcionalidade entregue valor, ela precisa ser lançada. Em produção ela não precisa apenas funcionar, é preciso prover performance suficiente, segurança e confiabilidade para servir seus usuários. Se você não endereçar adequadamente cada uma desses requisitos, em algum momento uma funcionalidade que já está lá precisará ser jogada fora e reescrita. Por isso nós falamos, "mudanças não lançadas em produção são um risco; mudanças lançadas entregam valor."
Se você não está avaliando seu projeto através desta inequívoca definição de pronto, então em algum lugar entre pronto e "pronto pronto" você precisa cruzar a "reta final":
O problema com a reta final é que raramente sabemos quanto tempo levará para ela ser cruzada. Se você entregou 100 funcionalidades até agora, você pode até ter uma boa idéia de sua velocidade de desenvolvimento. Isto não lhe diz absolutamente nada a respeito do tempo que tomará o processo final de análise de qualidade, as verificações de segurança e os testes de performance. Se você está fazendo Entrega Contínua então você cruza essa reta final freqüentemente (e com mudanças pequenas, mais seguras), desta forma você tem uma estimativa muito melhor de quanto tempo irá precisar, e também em como esse processo pode ser melhorado.
Esse exercício é uma aplicação do princípio "se dói, faça mais freqüentemente, leve a dor adiante." Isso pode parecer contra-intuitivo, mas é bem parecido com um exercício físico. É doloroso no momento em que se começa, mas assim que uma atividade antes dolorosa se torna algo mundano, corriqueiro, você estará pronto então para o próximo nível. Quais "músculos" de Entrega Contínua são necessários desenvolver? Ritmo e consistência. Um ritmo rápido significa que a reta final será completada com mais frequência, e consistência garante resultado parecido para cada tentativa de se cruzar a reta final. Sempre que possível a melhor forma de se conseguir consistência é através de automação. Testes de integração automatizados, deployments automatizados, auditoria automatizada e rastreamento de mudanças são todos importantes aspectos para a Entrega Contínua. Implementar isso, incluindo mecanismo de feedback para desenvolvedores e relatórios com o objetivo de manter os envolvidos informados, irá resultar em reduções significantes de erros humanos, falhas de comunicação e tempo gasto esperando por uma pessoa específica. O resultado será uma confiável e eficiente reta final.
Você pode escolher manter as mudanças fora de produção por razões de negócio, mas aqui vai um detalhe importante, você poderá dizer que está assumindo tal risco de atrasar o feedback recebido dos usuários por razões de negócio ao invés de ser forçado a assumir tal risco puramente por razões técnicas.
Medos de Feedback Incompleto
Organizações podem acreditar que não podem fazer Entrega Contínua a menos que sejam substituídos todos os testes manuais por uma confiável suíte totalmente automatizada. Isso não é verdade. Entrega Contínua requer "feedback rápido e automatizado sobre quão pronto um sistema está pronto para produção", e que você possa "enviar para produção ao simples acionamento de um botão". Isso significa que o objetivo é automatizar "quase tudo" de forma que você tenha feedback mais rápido e mais proteção contra erros humanos, mas esse objetivo pode ser sim, alcançado de forma incremental.
Sendo impossível automatizar um processo ad-hoc, automação tem um efeito colateral muito bom além de tornar os processos mais rápidos e confiáveis - padronização. De fato, a única coisa que realmente precisa ser automatizada inicialmente é um sistema para rastrear e reportar progresso através das fases do processo de entrega. Um passo intermediário válido no caminho para entrega contínua é um processo de entrega que ainda contém muitos passos manuais, mas que são padronizados e visíveis para o time, o analista de qualidade líder ou o administrador de sistemas em férias é algo que não muda o processo. Uma vez que isso acontece, você pode incrementalmente automatizar as partes que garantem o maior benefício. Uma boa recomendação é automatizar aquilo que gera feedback mais rápido para os desenvolvedores na ocorrência dos problemas mais comuns, depois disso vêm as atividades com as maiores chances de erros humanos, e finalmente, mecanismos para dar aos desenvolvedores feedback adicional em problemas não tão frequentes.
Padronizar e automatizar esses processos irá prover um elegante sistema de freios e contrapesos para o desenvolvimento ágil. Métodos ágeis são adaptáveis e orientado a pessoas para maximizar a habilidade em responder às mudanças de negócio. Entrega contínua provê um validação preditiva e orientada a processos para tais mudanças de forma que você pode consistentemente saber quais verificações de qualidade foram feitas antes de uma mudança ir para produção, e quase sempre ter uma boa idéia de quanto tempo irá levar para algo chegar lá (tanto por ter feito a mesma mudança, da mesma forma em outros ambientes como também pela experiência acumulada de tudo aquilo já enviado para produção anteriormente).
Medos da Agenda de Operações
Operar uma aplicação pode ser um trabalho extremamente implacável. Outros papéis podem experimentar a sensação ruim de "correria" quando precisam trabalhar horas extras para fazer algo cruzar a reta final, mas o pessoal de operações pode vivenciar esses momentos desconfortáveis a qualquer momento em que uma instabilidade acontece. Deles é esperado trabalhar noites e finais de semana já que agendamentos são planejados para minimizar o tempo fora do ar durante horário comercial, mas isso também acontece por que eles ficam de plantão e são acionados quando a aplicação cai por algum motivo não previsto. Então quando nós falamos "se dói, faça mais" o time de operações não tem nenhuma razão para penalizar a si mesmos ainda mais, a menos que eles acreditem que a estabilidade aumentará após conseguirmos passar por tais dores.
Por sorte existem algumas poucas razões para o time de operações ficar esperançoso. "Levar a dor adiante" pode também ser interpretado como "compartilhe a dor". Já que o time priorizou entregabilidade e prontidão para produção ao invés de novas funcionalidades, desenvolvedores e analistas de qualidade estarão lá para ajudar operações a resolver problemas difíceis. É por isso que Entrega Contínua é associada tão firmemente à cultura DevOps, que promove colaboração mais próxima entre todos os papéis envolvidos na entrega de uma mudança (primeiramente desenvolvedores, QAs, e operações). Algumas vezes isso significa desenvolvedores compartilhando cronogramas de plantão em empresas onde isso anteriomente acontecia somente para o pessoal de operações. No mínimo, isso significa que desenvolvedores e analistas de qualidade podem colaborar em coisas que irão fazer a vida do pessoal de operações mais fácil, como monitoramento mais efetivo e deployments mais rápidos.
Estudos1,2,3 têm mostrado que essa assistência está causando uma grande virada para operações. Os benefícios também tem um efeito composto, porque essas melhorias estão liberando o tempo de operações, eles estão conseguindo fazer mudanças benéficas mais profundas. Estão saindo de uma perspectiva reativa de manutenção para estratégias de prevenção.
Estudos1,2,3 comprovam que a cultura DevOps (necessária para que entrega contínua aconteça) resulta em:
- Deployments mais frequentes
- Mudanças levam menos tempo entre a concepção até produção (Changes Lead Time)
- Menos falhas na implementação de mudanças
- Menos tempo gasto na recuperação de falhas
- Mais tempo sendo gasto em atividades relacionadas a melhorias de produtividade como automação de tarefas repetitivas, melhorias de infraestrutura e formação do time.
- Menos tempos gasto "apagando incêndio", em suporte, comunicação (reuniões, e-mails e planejamento de release), gestão de infra-estrutura e deployment de mudanças.
Esses resultados podem parecer inacreditáveis inicialmente. Como pode um time lançar um produto em produção mais frequentemente e ainda assim gastar menos tempo em planejamento de tais lançamentos e processos de deployment? Planejamento de release é atualmente algo muito simples em times que fazem Entrega Contínua. Entega Contínua objetiva garantir que o produto é sempre "lançável", o que significa que enviar pra produção é sempre uma decisão de negócio. Uma cadência regular (uma vez por dia por exemplo) e técnicas que permite você decidir sobre o lançamento de cada funcionalidade independentemente (como feature toggles) torna isso tudo ainda mais fácil. A reunião de lançamento trata-se apenas de responder a questão "Quais dessas funcionalidades você quer em produção hoje?"
Conclusão
Nós apenas começamos a discutir as possibilidades de Entrega Contínua. O assunto abre muitas opções que podem melhorar drasticamente a qualidade, reduzir falhas em produção, evitar deployments de madrugada, e permitir que negócios rapidamente se adaptem para atingir seus objetivos. Mesmo sem o tempo necessário para discutir todas as técnicas avançadas, nós esperamos ao menos ter conseguido mostrar que implementar Entrega Contínua não deve ser uma proposta amedrontadora. Entrega Contínua não é programação "gambiarra', você não deve ter medo pois se trata de um processo disciplinado e benéfico tal como Eric Ries descreveu.
1 https://puppetlabs.com/2013-state-of-devops-infographic
3 http://www.zdnet.com/devops-really-does-speed-things-up-study-shows-7000020783/
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.