Na conferência GOTO Amsterdam 2014, Dan North compartilhou sua experiência como membro de uma equipe de desenvolvimento em um projeto no ano de 2005. Neste projeto, a equipe introduziu diversas práticas (técnicas e culturais) que deram origem aos princípios do livro Continuous Delivery (Entrega Contínua) e do movimento de DevOps. Como exemplo destas práticas criadas, nesta experiência é que foi apontado como fator para o sucesso de um projeto a aproximação entre as equipes de desenvolvimento e de operações.
(InfoQ entrevistou os membros da equipe para comentar sobre aquele período, desta forma as citações nesta história são provenientes desta entrevista)
Encarregado de reduzir o gargalo de testes que a organização enfrentava (testadores esperando muito tempo pelos releases, seguido por etapas frenéticas de testes com prazos reduzidos), a equipe de Dan North percebeu que o problema central era o lento e imprevisível provisionamento da máquinas e a necessidade implantação da aplicação em um grande número de ambientes controlados (atualmente classificados como ambientes snowflake ).
Estava tentando configurar nossas máquinas de QA nos Estados Unidos quando elas desapareceram no meio de uma sessão de shell. Alguns telefonemas depois e descobri que elas estavam em um caminhão sendo transferidas para um novo datacenter do outro lado do país.
Uma das primeiras medidas que a equipe tomou foi realizar controle de versão de todos os artefatos e configurações envolvidas na implantação, incluindo o container do servidor de aplicações WebLogic, bem como o próprio código fonte de implantação. Numa época em que as etapas manuais eram muitas vezes a única forma de se instalar ou implantar os componentes do aplicativo, automatizar tais medidas (por exemplo, templates dos arquivos XML gerados pela UI do WebLogic) permitiu a equipe reproduzir de forma determinística servidores com a configuração necessária (SO, pacotes, servidor de aplicativos, configurações de ambiente) para uma determinada aplicação (um exemplo de implementação de infra-estrutura como código).
Os avanços de automação foram recebidos inicialmente com ceticismo pela equipe de Ops (operações), pois a quebra dos silos exigia comunicação direta e passos incrementais que fossem de fácil implantação. Como exemplo, nos estágios iniciais todos as etapas recém-automatizadas (que antes eram manuais) ainda precisavam da aprovação explícita de uma pessoa de Ops. Outro exemplo que Dan se lembrou de tratar Ops como um cliente foi a escolha da linguagem (shell script) para implementar o código de deploy denonimado "Conan, o Deployador": a equipe aceitou a escolha do time de Ops, embora essa fosse a opção menos desejada pela equipe.
De alguma forma, o Dan North nos convenceu que o Conan poderia ser utilizado para a automação de todo o deploy.
Vários dos membros desta equipe se tornaram ativos promotores de Continuous Delivery e do movimento DevOps: Chris Read participou do primeiro DevOps Days em 2009, Jez Humble e Dave Farley (que não era um membro da equipe de build, mas líder de tecnologia de diversas outras equipes) escreveram o livro Continuous Delivery, Sam Newman apresentou tutoriais sobre Continuous Delivery e Julian Simpson se tornou conhecido como o "build doctor".
Minha lembrança mais forte é da equipe Conan ser a equipe mais cabeluda, fedorenta, desbocada e efetiva que já conheci.
Muitas técnicas que a equipe introduziu no projeto posteriormente se tornaram destaque no livro Continuous Delivery, como exemplo, single deployable artifacts (artefatos únicos de deploy), implantações blue-green e implantações self-service.
O melhor de tudo, sem mais releases durante fins de semana devido aos deploys "blue-green".
Um artigo de 2006 intitulado "The Deployment Production Line" (A Linha de Produção de Deploy), já abordou alguns dos problemas e soluções para a automação de um pipeline de build.
Você tem histórias semelhantes de automação e colaboração pré-DevOps para compartilhar com a comunidade?