O InfoQ Brasil fez uma entrevista exclusiva com Jez Humble, autor do popular livro Continuous Delivery (Addison Wesley, 2010). Jez apresentou detalhes sobre a prática de Continuous Delivery e como adotá-la dentro de diversos cenários. Falou ainda sobre o movimento DevOps, que visa diminuir a distância entre a equipe de desenvolvimento e a de infraestrutura e operações. Jez Humble é diretor na ThoughtWorks Studios e tem trabalhado com uma variedade de plataformas e tecnologias, dando consultoria para organizações sem fins lucrativos, empresas financeiras e de telecom, e companhias de varejo online. Seu foco é em ajudar as empresas a entregar software de qualidade de forma frequente e previsível, através da implementação de práticas de engenharia.
Wagner Santos: Poderia nos falar um pouco sobre do que trata o seu livro Continuous Delivery?
Jez Humble: O livro trata de assuntos normalmente considerados periféricos ao desenvolvimento de software, como gerência de configuração, gerência de builds e gerência de deployment; fala ainda de testes automatizados, integração contínua, infraestrutura e gerência de bancos de dados. Ao trabalhar em grandes projetos ágeis, descobrimos que essas atividades são essenciais, se quisermos produzir software de alta qualidade de maneira confiável e de forma repetível.
Muitas ideias do livro não são novas. O livro busca, na verdade, chamar a atenção para práticas de engenharia que sempre estiveram presentes no coração das metodologias ágeis, mas que de alguma maneira tornaram-se secundárias ao longo dos últimos dez anos. Nesse período, é claro, surgiram diversas ferramentas, como Puppet, Chef, Git e DbDeploy, que não existiam dez anos atrás, tornando tudo muito mais fácil de controlar.
As práticas de engenharia, particularmente as que tratam da automação de builds, testes e deployment, e também as de gerência de infraestrutura e a colaboração entre equipes de desenvolvimento, testes e operações – todas essas práticas são fundamentais para que seja possível entregar software de qualidade com rapidez. Isso, por sua vez, é essencial para garantir a capacidade das empresas de inovar e fornecer novas funcionalidades de maneira eficiente e confiável.
WS: Quais dentre essas práticas você considera as mais importantes?
JH: Para os desenvolvedores, a Integração Contínua. Mas realizar a Integração Contínua não significa simplesmente instalar um servidor de CI e apontá-lo para os branches do seu código fonte, mas sim garantir de que todos os desenvolvedores façam merges regularmente na mainline do código (isso se aplica também ao Git). Para que a integração contínua tenha utilidade real, é necessário realizar testes automatizados, em particular os unitários e de aceitação – e é quase impossível ter um conjunto de testes abrangente e fácil de manter, sem fazer TDD. Criar testes de aceitação de qualidade exige a colaboração estreita entre desenvolvedores e profissionais de testes.
É preciso assegurar que todo build esteja pronto para produção: garantir que se possa colocar no ar, rapidamente e sob demanda, ambientes de testes similares ao de produção – e também que seja possível executar cargas realistas sobre o sistema. Isso requer o provisionamento automático de ambientes de infraestrutura e o deployment automatizado do sistema, incluindo a realização de quaisquer mudanças necessárias no banco de dados. E tudo precisa ser implementado dentro do contexto de um fluxo de implantação (deployment pipeline).
Mudanças como estas precisam ser feitas de maneira incremental, procurando-se as restrições de cada processo de produção e as removendo uma a uma. Isso, mais uma vez, exige uma colaboração próxima entre os desenvolvedores e as equipes de testes e de operações.
WS: Nota-se que há certa confusão com o termo Continuous Delivery e Continuous Deployment. Você poderia esclarecer as diferenças?
JH: Realizar o Continuous Delivery (Entrega Contínua) significa possuir a capacidade de liberar versões do sistema sob demanda, de gerar um release do último build bem-sucedido simplesmente apertando um botão, sem precisar se preocupar se funcionará ou não. Mas o momento de fazer o release é uma decisão de negócio.
Já no Continuous Deployment (Implantação Contínua) são gerados releases e implantados todos os builds bem-sucedidos. A implantação contínua, é claro, só é aplicável para websites ou aplicações SaaS (software como serviço). Se não for possível fazer isso para cada build por alguma razão, por exemplo, por se estar trabalhando em um produto fechado instalado pelo usuário, deve-se pelo menos colocar o build num ambiente similar ao de produção e executar testes de aceitação e de desempenho realistas, para que não se tenha surpresas ao colocar o sistema em produção. É possível fazer isso em sistemas embarcados, produtos – qualquer coisa que envolva software.
Recomendo que empresas que tenham a possibilidade de aplicar a implantação contínua tentem fazê-lo. Um dos principais benefícios é o organizacional. Ela torna os desenvolvedores mais preocupados com a qualidade e a confiabilidade do que está sendo produzido. A partir do momento em que um desenvolvedor pode colocar suas modificações em produção clicando em um botão, fica muito mais interessado no que acontece naquele ambiente.
A aplicação da implantação contínua também muda o foco do negócio. Esta área, ao invés de incluir o maior número possível de funcionalidades em um release, passa a enxergar o valor de se criar pequenas funcionalidades e tê-las em produção em questão de dias. Passam a se preocupar em receber feedback realista sobre as novas funcionalidades, verificando se têm valor para o cliente e se é necessário trabalhar mais nelas.
É uma mudança total de paradigma na forma de trabalho das empresas, que passam a reagir muito mais rapidamente às demandas de seus clientes. Eric Ries fala mais sobre este assunto em seu próximo livro, a ser publicado, The Lean Startup.
WS: Como participante ativo do movimento DevOps, você poderia nos falar mais sobre esta iniciativa?
Jez Humble: O DevOps é uma espécie de "anti-movimento" , que resiste à categorização. Fundamentalmente, trata-se do foco na colaboração entre todos os envolvidos na entrega do software – particularmente as equipes de desenvolvimento, de testes e de operações – e o compartilhamento conhecimento e técnicas entre elas. A infraestrutura-como-código é um exemplo de conhecimento compartilhado. Trata-se da aplicação de técnicas ágeis, como refatoração e desenvolvimento orientado a testes, para evoluir sua infraestrutura. O DevOps é essencial para se chegar ao Continuous Delivery.
As pessoas envolvidas no DevOps têm resistido em criar um manifesto para o movimento, por exemplo para prevenir que fornecedores (em particular os de ferramentas) se apropriem da ideia. Geralmente, pessoas são culpadas por tentar alcançar o Continuous Deployment por meio de ferramentas – mesmo as pessoas dentro do movimento, incluindo eu mesmo – enquanto que, na verdade, é a atitude e a mentalidade das pessoas envolvidas que tornam o processo bem-sucedido. Não estou dizendo que ferramentas não são importantes, elas são. Mas ferramentas que não podem ser gerenciadas de maneira automática, através de uma API, são especialmente impopulares dentro da comunidade.
WS: Como você recomenda que seja implementado o DevOps?
JH: Uma boa maneira de iniciar é ter representantes de todas áreas da empresa envolvidos nas entregas, incluindo as equipes de desenvolvimento, testes, infraestrutura, operações e gestão do produto. Todos devem reunir-se regularmente e realizar retrospectivas para refletir sobre como, de maneira incremental, as coisas podem ser melhoradas. É muito raro vermos pessoas de todos os departamentos juntos em uma reunião.
Outra boa maneira de começar é fazer com que todos os envolvidos na entrega do software comemorem juntos os releases bem-sucedidos. Implementar o DevOps consiste em realizar mudanças que partem das pessoas diretamente envolvidas no trabalho. É difícil comandar essas mudanças de cima, e é por isso que a alta gerência ainda tem dificuldades de lidar com o DevOps. As mudanças incrementais, de baixo para cima, são o ingrediente secreto – e são geralmente as mais eficazes e duradouras.
WS: Quais as habilidades relacionadas a infraestrutura um desenvolvedor deve ter? E por que isto é importante? Faz sentido empresas empresas que não estão usando o cloud computing investirem nesta área?
JH: Acho que o principal elemento é automatizar o gerenciamento e o provisionamento de infraestrutura. Deve ser possível conectar um novo servidor ou estação de trabalho na rede e colocá-lo no estado correto: preparar o ambiente e fazer o deploy de maneira totalmente automática. Isso deve ser possível independentemente de se estar ou não num ambiente de nuvem. Por baixo dos panos, a "nuvem" obviamente roda em um hardware real, portanto, os mesmo princípios se aplicam.
WS: Para grandes empresas, que já possuem um Departamento de Operações, o que um desenvolvedor pode fazer para diminuir o espaço existente entre o "Ops" e o "Dev"?
JH: Recomendo, antes de qualquer coisa, conhecer melhor o departamento de operações, aproximar-se da equipe e convidá-la para suas retrospectivas e demonstrações. É importante também aprender as ferramentas que utilizam e ajudá-los a construir novas ferramentas. Leia livros como "Release It!" que tratam da criação de software pronto para produção. Examine os painéis da equipe de operações expondo as métricas de produção; coloque as mesmas telas nas salas dos desenvolvedores. Ofereça ajuda quando novos releases acontecerem. Envolva-se!
Jez Humble está realizando atualmente uma sequência de viagens para participação em conferências e apresentação de treinamentos. Neste mês, virá para o Brasil para ministrar, pela ThoughtWorks, o treinamento "Continuous Delivery for DevOps". Os cursos acontecerão no Rio (16/08), em São Paulo (17/08) e em Porto Alegre (20/08).
Sobre o autor
Wagner Roberto dos Santos (@wrsantos) é Agile Coach e Arquiteto de Software pela empresa francesa OCTO Technology. Palestrante em diversos eventos nacionais e vencedor de prêmios de desenvolvimento, possui seis certificações Java, além de ser CSM e ACP. É instrutor da Globalcode nas Academias Agile e Java. Nas horas vagas, mantém o blog http://netfeijao.blogspot.com.