Com a Entrega Contínua o software é construído de maneira que pode ser colocado em produção a qualquer momento. Estamos fazendo Entrega Contínua quando:
- É possível mandar o software para produção em qualquer momento do seu ciclo de vida;
- Manter essa capacidade de entrega para produção é prioridade sobre ao trabalho relacionado a novas funcionalidades;
- Qualquer pessoa pode ter feedback rápido e automatizado sobre o quanto seus sistemas estão prontos para produção, sempre que uma mudança acontece;
- Pode-se enviar qualquer versão do seu software para produção através do simples acionamento de um botão.
Na ThoughtWorks usamos uma definição desenvolvida pelo grupo de Entrega Contínua que pode parecer menos assustadora que a muitas ideias que você já viu por aí. Ela não determina que toda mudança que consegue passar por verificações automatizadas irá realmente para produção. Apenas diz que o software está sempre em um estado e que pode ser mandado para produção se você quiser.
Mas onde estão os medos? Vamos examinar alguns deles.
Medos de cronogramas e andamentos
Pode ser difícil para o pessoal de negócios entender parte do trabalho inicial em "entregabilidade", mas esse esforço gera uma métrica de negócio bem diferente e fácil de entender - a verdadeira completude de funcionalidades.
A Entrega Contínua tem uma definição precisa de pronto: "uma funcionalidade está pronta apenas no momento em que está entregando valor para seus usuários". Para que uma funcionalidade entregue valor, precisa ser lançada. Em produção, ela não precisa apenas funcionar; é preciso oferecer desempenho suficiente, além de segurança e confiabilidade para servir a seus usuários. Se não forem tratados adequadamente cada um desses requisitos, em algum momento uma funcionalidade já presente precisará ser jogada fora e reescrita. Por isso falamos que "mudanças não lançadas em produção são um risco; mudanças lançadas entregam valor."
Se seu projeto não está sendo avaliado através dessa definição de pronto, então em algum lugar entre pronto e "realmente pronto", será preciso cruzar a "reta final". O problema com a reta final é que raramente sabemos quanto tempo levará para ser cruzada. Se foram entregues 100 funcionalidades até agora, pode-se ter uma boa ideia da velocidade de desenvolvimento. Mas isso não lhe diz 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 desempenho. Já se está sendo feita a Entrega Contínua, essa reta final é cruzada frequentemente (e com mudanças pequenas e mais seguras). Assim há uma estimativa muito melhor de quanto tempo será necessário e também de como o processo pode ser melhorado.
Esse exercício é uma aplicação do princípio "se dói faça mais vezes; leve a dor adiante." Isso pode parecer não-intuitivo, mas é bem parecido com exercícios físicos. É doloroso no momento em que se começa, mas assim que a atividade se torna corriqueira, estamos prontos para o próximo nível. Quais "músculos" de Entrega Contínua são necessários desenvolver? Ritmo e consistência.
Um ritmo forte significa a reta final sendo concluída com mais frequência, e a consistência garante resultado parecido para cada tentativa de se cruzar a reta final. A melhor forma de se conseguir consistência é através de automação. Testes de integração, deployment e auditoria automatizados, assim como o rastreamento de mudanças, são todos importantes aspectos para a Entrega Contínua. Implementar essas práticas, incluindo um mecanismo de feedback para desenvolvedores, bem como relatórios com o objetivo de manter os envolvidos informados, irá resultar em reduções significativas de erros humanos, de falhas de comunicação e de tempo gasto esperando por uma pessoa específica. O resultado será uma "reta final" confiável e eficiente.
Pode-se escolher manter as mudanças fora de produção por razões de negócio, mas aqui vai um detalhe importante: você pode dizer que está assumindo o risco de atrasar o feedback recebido dos usuários por razões do negócio, ao invés de ser forçado a assumir esse risco puramente por motivos técnicos.
Medos de feedback incompleto
Empresas podem acreditar que não podem fazer Entrega Contínua a menos que sejam substituídos todos os testes manuais por uma suíte de testes totalmente automatizada. Isso não é verdade. A Entrega Contínua requer feedback rápido e automatizado sobre quanto está pronto um sistema para produção, e que se possa enviar para produção ao simples acionamento de um botão. Isso significa que o objetivo é automatizar "quase tudo", de forma que se tenha feedback mais rápido e mais proteção contra erros humanos. Mas esse objetivo pode ser sim alcançado de forma incremental.
Além dos benefícios óbvios relacionados a confiabilidade e rapidez, a automação gera outro efeito colateral muito positivo - a padronização. Isso porque é impossível automatizar um processo ad hoc. De início, a única coisa que realmente precisa ser automatizada é um sistema para rastrear e reportar progresso através das fases do processo de entrega.
Um estágio intermediário válido na jornada da Entrega Contínua é um processo que ainda contém muitos passos manuais, mas tais passos precisam estar padronizados e visíveis para todo o time. A ausência do líder de QA ou do administrador de sistemas não deve quebrar o processo. Uma vez nesse estágio, pode-se 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. Por fim, temos os mecanismos para fornecer aos desenvolvedores feedback adicional em problemas não tão frequentes.
Padronizar e automatizar esses processos gera um elegante sistema de freios e contrapesos para o desenvolvimento ágil. Métodos ágeis são adaptáveis e orientados a pessoas, para maximizar a habilidade em responder às mudanças de negócio. A Entrega Contínua cria uma validação preditiva e orientada a processos para tais mudanças. Dessa forma pode-se saber consistentemente quais verificações de qualidade foram feitas antes de uma mudança ir para produção, e quase sempre ter uma boa ideia de quanto tempo levará para algo chegar lá (tanto por ter feito a mesma mudança da mesma forma em outros ambientes, como pela experiência acumulada de tudo que já enviado para produção anteriormente).
Medos da agenda da equipe de operações
Operar uma aplicação pode ser um trabalho implacável. Outros papéis podem trazer a sensação ruim de "correria" quando precisam trabalhar horas extras para fazer algo cruzar a reta final, mas a equipe 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 o horário comercial.
Porém, isso também acontece porque a equipe fica de plantão e é acionada quando a aplicação cai por motivos não previstos. Quando falamos "se dói, faça mais vezes" para o time de operações, eles não têm razão para penalizar a si mesmos ainda mais, a não ser que estejam convencidos que isso aumentará a estabilidade. A ideia é diminuir a possibilidade de grandes dores pontuais (ex.: dois dias sem dormir por um problema crítico), por dores pequenas e frequentes dores, acontecendo no expediente normal.
Mas há existem razões para o time de operações ficar esperançoso. "Levar a dor adiante" pode também ser interpretado como "compartilhar a dor". Como o time priorizou a entregabilidade e a prontidão para produção, ao invés de novas funcionalidades, os desenvolvedores e analistas de qualidade estarão disponíveis para ajudar a equipe de operações a resolver problemas difíceis.
É por isso que a Entrega Contínua é associada tão firmemente à cultura de DevOps, que promove a colaboração mais próxima entre todos os papéis envolvidos na entrega de uma mudança (especialmente desenvolvedores, QAs, e operações).
Algumas vezes isso significa desenvolvedores sendo escalados para ficar de plantão em empresas, onde isso anteriormente 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 simplificar a vida da equipe de operações, como monitoramento mais efetivo e deployments mais rápidos.
Estudos têm mostrado que essa dinâmica de colaboração está causando grandes mudanças nas operações. Os benefícios também têm efeito acumulativo, porque essas melhorias estão liberando o tempo da equipe de operações, que está conseguindo fazer mudanças benéficas mais profundas. Com isso, saímos de uma perspectiva reativa de manutenção para estratégias de prevenção.
Estudos indicam que a cultura de DevOps, necessária para que entrega contínua aconteça, resulta em:
- Deployments mais frequentes;
- Mudanças que levam menos tempo entre a concepção e a produção;
- Menor quantidade de falhas na implementação de mudanças;
- Menos tempo gasto na recuperação de falhas;
- Mais tempo gasto em atividades relacionadas a melhorias de produtividade, como automação de tarefas repetitivas, melhorias de infraestrutura e formação da equipe;
- Menos tempo "apagando incêndios" em suporte, comunicação (reuniões, emails e planejamento de releases), gestão de infraestrutura 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 dos lançamentos e processos de deployment?
O planejamento de releases, na verdade, é simples em times que fazem Entrega Contínua. A Entrega Contínua objetiva garantir que o produto é sempre "lançável", o que significa que enviar para produção é sempre uma decisão de negócio.
Um ritmo regular (uma vez por dia, por exemplo) e técnicas que permitem decidir sobre o lançamento de cada funcionalidade independentemente, como as "feature toggles" (que permitem ativar uma funcionalidade para apenas uma parcela de usuários ou mesmo desativá-la em caso de defeitos), torna tudo ainda mais fácil. A reunião de lançamento trata-se, dessa forma, de apenas de responder à questão "Quais dessas funcionalidades queremos em produção hoje?".
Conclusões
A Entrega Contínua abre opções que podem melhorar drasticamente a qualidade, reduzir falhas em produção e evitar deployments na madrugada, além de permitir que a área de negócios se adapte rapidamente para atingir seus objetivos.
Mesmo sem ter discutido aqui várias as técnicas avançadas, esperamos ao menos ter conseguido mostrar que implementar a Entrega Contínua não deve ser uma proposta assustadora. A Entrega Contínua não é programação "orientada a gambiarras"; não se deve ter medo pois se trata de um processo disciplinado e benéfico.
Sobre os autores
Jefferson Girão, Max Lincoln e Rafael Magrin são desenvolvedores na ThoughtWorks Brasil.