Uma das decisões mais importantes que tomamos como empresa foi a de lançar menos software, mas com mais frequência. Antes disso, tentávamos entregar atualizações trimestralmente, porque, até então, seguíamos o modelo de ciclos de vida por versões de lançamento (staged delivery) para fazermos nosso sistema – com análises e arquitetura primeiro, e design, desenvolvimento e testes realizados em um período de 3 meses.

Mas essa abordagem não funcionou quando o sistema começou a funcionar. As prioridades continuavam a mudar e recebíamos mais feedback dos clientes. Coisas demais precisavam de ajuste e conserto imediato, e tínhamos que lidar com situações operacionais de urgência. Sempre interrompíamos o desenvolvimento para distribuir versões temporárias e patches e em seguida replanejávamos e replanejávamos tudo novamente, desperdiçando o tempo de todos e tornando mais difícil manter o registro do que precisava ser feito. Os desenvolvedores e o pessoal de operações estavam ocupados com os clientes e “apagando fogo”, o que significa que não conseguíamos colocar as mudanças em produção quando precisávamos. Então decidimos encurtar os ciclo de 3 meses para 1 mês, depois para 3 semanas e novamente para 2 semanas, tornando os lançamentos menores, mais focados e mais fáceis de gerenciar.

Lançamentos menores e mudanças mais frequentes: é como o desenvolvimento é feito

Entregar menos, mas mais vezes: quer você faça isso em uma startup para reduzir o tempo até o mercado e conseguir feedbacks mais rápidos, ou por contenção de risco e administração de mudanças em uma grande empresa, o modelo faz você pensar e reconsiderar a maneira como desenvolve software. Ele muda a forma como se executam planejamentos, criam-se estimativas, como você enxerga os riscos e como os administra. Ele muda a forma como se criam os projetos e o quanto de planejamento se faz necessário. Muda também a forma como você realiza testes. Mudam-se as ferramentas que as pessoas necessitam e o quanto elas necessitam das ferramentas.

Mudam as suas prioridades. Muda a forma com que as pessoas trabalham em equipe e a maneira como lidam com o cliente, criando mais oportunidades e mais razões para conversar uns com os outros e aprender com isso. Muda a forma de as pessoas pensarem e agirem – porque elas precisam pensar e agir diferente de forma a conseguirem manter o ritmo e ainda assim fazer um bom trabalho.

Lançamentos menores e mudanças mais frequentes: é como desenvolvimento e operações trabalham juntos

Alterar a frequência com a qual você faz lançamentos e deploy irá mudar também como o time de operações trabalha e como os desenvolvedores interagem com eles. Não há tempo suficiente para o gerenciamento de lançamentos de grande porte e controles de mudanças com muitas reuniões e papelada. Você precisa de uma abordagem que é mais fácil e mais rápida. Mas alterar as coisas com mais frequência também significa uma chance maior de cometer mais erros. Portanto, você precisa de uma abordagem que irá reduzir os riscos e consiga encontrá-los logo no início.

Times de desenvolvimento que lançam software uma vez ou outra por ano não perdem muito tempo pensando em lançamentos, deployment e coisas operacionais em geral, simplesmente porque não precisam disso. Mas se estiverem realizando deploys a cada poucas semanas, se precisarem “soltar” software constantemente, fará todo sentido para eles entender como está a produção e fazer com que o deployment (e o roll-back) tornem-se mais fáceis tanto para eles quanto para o time de operações.

Você não precisa automatizar tudo para começar – e talvez não deva, até entender suficientemente os problemas. Nós começamos com check lists, scripts, configuração manual e sistemas de testes manuais. Colocamos tudo debaixo do controle de versão (não apenas o código) e começamos a padronizar e automatizar os deployments, a configuração e os roll-backs, trocando trabalho manual e check lists por comandos de auditoria e checagens automatizadas. Saímos da configuração manual de servidores e patches para a administração de infraestrutura com o Puppet. Ainda estamos alinhando testes e produção de forma que possamos testar melhor os passos do deployment com mais frequência e com menos mudanças específicas de produção. Ainda não temos um “deploy com um botão” e talvez nunca tenhamos, mas lançamentos e deploy são hoje muito mais simples, padronizados, seguros e menos dispendiosos do que costumavam ser.

Deployment é só o começo

Melhorar o deployment é apenas o começo de um diálogo que pode se estender para o restante das operações. Por estarem trabalhando juntos com mais frequência, desenvolvedores e operações irão aprender mais sobre o outro e começar a falar a língua um do outro e a entender os problemas e as prioridades que cada um tem.

Para começar, incentivamos as pessoas a lerem o livro Visible Ops e mandamos o time de operações, de testes, alguns desenvolvedores e até mesmo gerentes para um treinamento da ITIL Foundation para que todos pudéssemos entender as diferenças entre o gerenciamento de um incidente e a resolução do problema e sobre como fazer RCA – foi provavelmente um exagero, mas fez com que todos pensássemos sobre a operacionalização e a levássemos a sério. Nós reunimos o pessoal de desenvolvimento, testes e operações para planejar e rever os lançamentos e para dar suporte à produção em RCA sempre que temos problemas sérios – e para trabalharmos juntos para descobrirmos porque uma coisa deu errado e o que podemos fazer para evitar que ela aconteça novamente. Desenvolvedores e operações “pareiam” para investigar e resolver problemas operacionais, para melhorar os projetos e novas arquiteturas, como tornar nosso sistema mais seguro e sobre como gerenciar e desenvolver ambientes de teste e desenvolvimento.

Parece fácil, mas não foi. Levou um tempo e houve desentendimentos e retrocessos, como em qualquer momento em que se muda radicalmente a forma como as pessoas trabalham. Mas, se fizer isso corretamente, as pessoas começarão a criar conexões e a construir relações que irão inevitavelmente confiar e transparecer entre os grupos – isso é o que Devops realmente significa.

Você não precisa mudar a estrutura ou revisar toda a cultura da sua empresa – na maioria dos casos, você não terá poderes para fazer isso de qualquer maneira. Você não tem que comprar a ideia de deployment contínuo ou mesmo entrega contínua, ou infraestrutura como código, nem usar o Chef ou o Puppet ou qualquer outra ferramenta de Devops – apesar de as ferramentas realmente ajudarem.

Uma vez que as mudanças começarem a acelerar, de deploys uma vez por ano para alguns meses e para apenas um mês, e o ritmo de sua empresa aumentar, as pessoas irão mudar a forma de trabalhar simplesmente porque elas precisarão fazer isso.

Hoje, a forma como pensamos e trabalhamos o desenvolvimento e as operações é algo muito diferente e certamente muito mais saudável do que era antes. Podemos responder aos problemas e às mudanças nos negócios com muito mais agilidade e, ao mesmo tempo, nosso índice de confiabilidade aumentou dramaticamente. Não nos programamos para sermos “Ágeis” – não aconteceu até que estivéssemos a caminho de ciclos de lançamentos mais curtos e déssemos uma olhada melhor no Scrum e no XP – e mais tarde no Kanban – para enxergarmos como esses métodos poderiam nos ajudar a desenvolver software. Também não estávamos tentando fazer “Devops” – já estávamos a caminho de uma melhor colaboração entre desenvolvimento e operações quando alguém começou a falar sobre essas ideias na Velocity Conf e tantas outras. Tudo que fizemos foi concordar, enquanto empresa, a mudar a frequência com a qual colocaríamos software em produção. E isso fez toda a diferença.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/02/releasing-more-often-drives-better-dev.html