Ano passado, vi o seguinte e-mail agradecendo muito justamente a um grupo de desenvolvedores por seus esforços gigantescos no gerenciamento, apesar de todas as dificuldades, para o lançamento de um aplicativo web a tempo para uma feira da indústria. Foi algo mais ou menos assim:

“Planejamos noites e noites os planos A – E, e AAARRRGGGHHH: últimos minutos, as chamadas frenéticas para a empresa do servidor, servidores web caindo no dia do lançamento, férias canceladas, tensão e fase inicial da Síndrome de Estocolmo. No entanto, de alguma forma, nós conseguimos e ainda continuamos conversando uns com os outros. As seguintes pessoas devem se levantar e receber os aplausos que eles merecem, justamente porque foi um esforço verdadeiramente surpreendente:. Laura, Mo, Sir Chris, Jason, Alistair, Andy, Jess, Victoria, Greg, Ben e Bradley (1)”.

…e é aí que está o problema. E-mails como esse deveriam ser a exceção e não a regra, assim como liberar o código no ambiente de produção deve ser um não-evento. Na minha maneira de pensar, se você precisa trabalhar continuamente nos fins de semana, até tarde da noite, sofrer de estresse e ter feriados cancelados, para que você possa dolorosa e manualmente disponibilizar o seu aplicativo para o ambiente de produção, então tem algo muito errado com o seu processo de desenvolvimento. Uma vez eu li em algum lugar que você deve “trabalhar de forma inteligente e não difícil”, o que parece ecoar os sentimentos de @jezhumble, que recentemente deu uma palestra inspiradora em Berlim sobre entrega contínua. Durante a conversa, Jez passou pelos fundamentos da entrega contínua e pelo ponto crucial do que parecia ser:

• Ao entregar, entregue pequenas partes do trabalho.
• Entregue frequentemente.
• Seja capaz de reverter entregas de forma rápida e simples.
• Faça o descrito acima, automatizando tudo.
• As pessoas são a chave – fale com outras equipes/departamentos e trabalhe com eles.

Ao realizar esses pontos particularmente parafraseados, Jez fez tudo parecer incrivelmente fácil, mas é tão fácil como ele faz parecer? Eu acho que a resposta é sim e não… Na execução de entrega contínua, o que você vai realmente realizar uma é série de mudanças de processos dentro de um ambiente corporativo e ver que gerenciar a mudança pode ser incrivelmente difícil, muitas vezes intensamente frustrante, e extremamente político. Eu acho que é um daqueles momentos em que “o tamanho importa”.

John Allspaw, oficialmente do flickr e agora da Etsy, relata suas experiências sobre a entrega contínua no flickr e como a empresa era tão pequena que os desenvolvedores não tinham escolha a não ser fazer tudo sozinhos, do código a operações de controle de qualidade. Isso levou os desenvolvedores a realizarem pequenas alterações incrementais no código para o ambiente de produção. Esse processo ainda pode ser visto se você der uma olhada mais a fundo em http://code.flickr.com, onde você vai encontrar algo assim:

 

…o que é muito legal. Se o e-mail no início deste artigo fosse enviado por um gerente do Flickr, então, na época, ele teria enviado 84 e-mails!

Mas eu discordo. O objetivo do exemplo de John Allspaw/flickr é que é relativamente fácil implementar procedimentos em uma nova empresa ou alterar os procedimentos existentes em uma empresa muito pequena. Grandes empresas, por outro lado, são um dilema diferente, nas quais a implementação de carga é mais difícil. Além da logística de gestão de mais pessoas, muitas vezes, em vários sites ao redor do mundo, existem também procedimentos enraizados, estabelecidos e queridos, que às vezes resultam em uma resistência à mudança e um a comportamento de “empregos valem a pena”.

Eu estive em vários projetos nos quais a equipe de desenvolvimento organizou seus procedimentos internos para incluir testes de escrita, commits frequentes, execução de compilações contínuas, adição de automação e liberação com frequência para a equipe de testes. Isso é conduzido, geralmente, por membros da equipe que odeiam o incômodo de lançamentos manuais estressantes e pouco frequentes, e que querem tornar a vida deles mais fácil e estão entusiasmados o suficiente para querer abraçar as ideias mais recentes e assumir a responsabilidade por aquilo que fazem. Na gestão, falar isso seria instigação de mudança de “baixo para cima”.

Embora essa ideia de mudança de “baixo para cima”funcione bem em pequenas empresas pequenas e em nível de equipe, a minha experiência é que é muito ineficiente quando se trata de lidar com grandes organizações. Em empresas maiores, parece normal ter várias equipes de desenvolvimento trabalhando em uma infinidade de aplicativos diferentes, enquanto muitas vezes há apenas uma equipe de banco de dados e uma de operações, que são responsáveis ​​pela gestão das bases de dados e implementação de todas as aplicações. É aqui que o desenvolvimento dirigido à entrega contínua falha. É fácil mudar a forma como sua equipe trabalha, mas então você tem que mudar a forma como trabalham outras equipes de desenvolvimento. Se você conseguir isso, então vai ter que começar a mudar a forma como os caras do banco de dados trabalham e também a equipe de operações. Isso torna a implementação de mudanças interdepartamental e, claro, a essa altura alguém vai, geralmente, sugerir a formação de uma comissão que irá avaliar a situação atual, aparecer com uma lista de alternativas e, na plenitude do tempo, no momento oportuno, recomendar que outra comissão seja necessária. Minha experiência é que quando se trata de fornecimento de software, você, como desenvolvedor, deve seguir os procedimentos e as diretrizes da equipe de operações, no entanto eles podem ser antiquados, e muitas vezes porque “essa é a maneira como sempre foi feito”.

Eu sei que isso parece extremamente negativo, mas acho que o progresso está sendo feito. Anos atrás, em empresas de grande porte, a gente tinha o desenvolvimento muito separado, QA, banco de dados e equipes de operações, passando o seu trabalho “concluído” para o outro bem de qualquer jeito. No entanto, “Times They Are A-changin’^“(2) e, mais recentemente, as equipes de projeto dentro de grandes organizações com que trabalhei têm geralmente incluído desenvolvedores e testadores trabalhando juntos na mesma equipe; às vezes, você ainda vê um guru do banco de dados da equipe. Talvez um dia as equipes de projetos em grandes empresas irão incluir pessoas de todas as disciplinas exigidas para disponibilizar seu aplicativo. Eu vivo na esperança.

Então, a questão é como você realiza a mudança corporativa? Essa não é uma questão trivial. Jez Humble afirma que “as pessoas são a chave”, o que é bem verdade. Ele recomenda que um bom começo seria desenvolvedores falarem com os caras de operações e construir um relacionamento com eles, por exemplo, convidando-os para as suas festas de lançamento.

No entanto, como eles dizem “não é o que você sabe, mas quem você conhece”(3), por isso é uma boa ideia falar com as pessoas certas ou a pessoa. Não é bom ter a equipe de operações júnior do lado, você tem que chamar o gerente, o diretor e o chefão geral para o lado. Se, como um desenvolvedor júnior, você acha que sugerir uma nova abordagem para o chefão é uma tarefa difícil, então, como um homem sábio uma vez disse (4), imagine-os no vaso sanitário antes de iniciar sua conversa.

Quando o chefão muda as coisas, então na gestão de falar isso é conhecido como mudança de gestão de ‘cima para baixo’.

Eu quis saber por que @jezhumble fez implementação de entrega contínua parecer tão simples e pensei que talvez seja porque ele trabalhe para a ThoughtWorks, que de acordo com o seu site são ou “a construção de um novo sistema personalizado para um cliente, o conserto de um projeto que está amarrado em nós, ou ajuda para tornar uma organização de desenvolvimento de software mais produtiva” (5). ThoughtWorks são consultores e não há nada de errado com a empresa ou com os consultores; no entanto, as empresas pagam muito dinheiro para os consultores e, pelo fato de a gestão de uma empresa já ter pago um monte de dinheiro, elas muitas vezes ouvem e implementam o conselho do consultor de bom grado, mesmo que seja errado ou que reitere o que os fiéis empregados da própria empresa vêm dizendo o tempo todo. Eu já ouvi isso ser chamado de Síndrome de Consultoria.

É inegável que há uma necessidade por entrega contínua. Para alguns, isso pode ser simples em termos de custos – a dedução sendo que entrega contínua é barato, enquanto que releases manuais monolíticos são muito caros. Para desenvolvedores, é geralmente uma questão de equilíbrio entre a vida e o trabalho: ser capaz de ver seu parceiro e sua família. Estar lá para levar seus filhos para passear, ler histórias para eles antes de dormir ou se encontrar com os amigos para um drink ou um cinema, enquanto não sofre de fadiga por causa do desenvolvimento. Como todo mundo sabe, ninguém em seu leito de morte pensa: “eu deveria ter passado mais tempo no trabalho”.

Finalmente, eu falei sobre a implementação de mudanças em pequena escala em nível da equipe e em uma escala maior em nível corporativo. Os caras mencionados no e-mail acima realmente passaram por eisso. Eles fizeram o desenvolvimento e alguns testes, o cliente fez a gestão do projeto e forneceu as operações e a infraestrutura, uma terceira empresa forneceu o banco de dados, enquanto uma quinta empresa forneceu o conteúdo e ainda mais testes. Implementar a mudança em um nível multicorporativo, agora que é difícil…

1 Não são seus nomes reais.

2 Veja Bob Dylan de 1964, para a gravadora Columbia.

3 Provérbio

4 Billy Connolly

5 Ver Sobre a ThoughtWorks

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.captaindebug.com/2012/10/implementing-continuous-delivery-is.html#.UV41VqKG3Np