Blog da Improve It

Barrigas abertas

Publicado por Vinicius Manhães Teles há mais de 5 anos.

O Marcelo Baltar fez alguns comentários, nesse artigo, sobre a utilização do CruiseControl no processo de integração contínua e eu gostaria de levantar algumas considerações. Preferi fazer isso através de um novo artigo. O Marcelo cita o seguinte:

"Parabéns, mais um excelente post. Mas devo dizer que eu também tenho uma preferência pelos testes assíncronos (CruiseControl-like ;) ). Além das questões técnicas, já bem exploradas no seu post e em alguns comentários, esse tipo de abordagem aproxima-se mais dos conceitos pregados pelas metodologias 'ágeis'.

No meu entender é mais proveitoso o desenvolvedor 'commitar' seu trabalho o quanto antes (lógico, com os devidos testes implementados) e já avançar para as próximas tarefas ao invés de ser obrigado a passar por todo esse processo de integração 'pré-commit'. Afinal de contas, quão realmente grave/problemático seria o commit de código que quebra o que está no repositório? Pela minha experiência, isso acontece pouquíssimo, e quando acontece, graças a granularidade dos commits, pode ser facilmente corrigido."

Marcelo, muito obrigado pelo comentário. Compreendo sua percepção de que o uso do CruiseControl possa estar mais associado a metodologias ágeis, porém não compartilho essa mesma visão. Acredito que isso tem a ver com a interpretação do que seja uma "metodologia ágil". Não sei se você chegou a ler o artigo sobre agilidade x Agilidade. O termo "ágil" não está associado apenas ao conceito de velocidade, mas sim ao Manifesto Ágil e seus princípios.

Um dos valores fundamentais no mundo ágil é feedback. Receber feedback cedo e agir sobre ele rapidamente. A forma de receber feedback e atuar sobre ele é diferente dependendo se você utiliza um modelo de integração síncrona ou assíncrona. No assíncrono, o feedback tende a ser mais demorado e pode passar despercebido. Por exemplo, se ele vier por email, pode ser que o desenvolvedor não esteja consultando os emails com freqüência. Isso é comum de acontecer em XP, por exemplo, devido à programação em par e outros fatores.

Desenvolvimento ágil também está relacionado a entregar software funcionando. Então, cada novo código introduzido no projeto tem que estar funcionando para gerar valor de verdade. Por essa razão, o código que vem do repositório tem que estar em ordem permanentemente. O uso de uma ferramenta como o CruiseControl, pelas razões descritas acima, permite a existência de código quebrado no repositório. Ele não leva a isso, mas permite.

Nos projetos que eu conheci, que utilizavam CruiseControl, era comum o repositório estar quebrado. A razão era sempre alguma coisa "boba" que ia ficando lá porque ninguém queria parar para consertar. Nós aqui chamamos isso de "barriga aberta". Pense em um cirurgião. Quando ele vai operar uma pessoa, ele abre a barriga, faz o que precisa ser feito e fecha, antes de partir para outra cirurgia. Ele não abre a barriga de um, começa a operar e, em seguida, abre a barriga de outro antes de terminar a primeira cirurgia (como ilustrado abaixo). Ele sabe que isso seria perigoso e improdutivo. Nós não. Nós somos de computação, então a gente adora fazer aquilo que parece rápido, mas costuma gerar dores de cabeça mais adiante. :-)

Evite deixar barrigas abertas. Ilustração de Leandro Mello.

Na minha opinião, fazer um commit e partir para outra atividade, antes de receber feedback sobre o que foi colocado no repositório é o mesmo que "deixar uma barriga aberta". Para nós, desenvolvedores, que estamos sempre ansiosos para passar para a próxima atividade, é tentador demais seguir com o próximo cartão, mesmo enquanto ainda há pendências no atual. E o modelo de integração assíncrona permite isso. Já a integração síncrona, não. Ela obriga o desenvolvedor a parar momentaneamente, ter certeza de que tudo correu bem e só então prosseguir para a próxima atividade. Isso está alinhado a um princípio do XP chamado passos de bebê. Acredito que o importante não seja a velocidade com que partimos para a próxima atividade, mas sim quão rápido conseguimos entregar código que temos certeza de estar funcionando.

Outra questão, também ligada ao feedback é o próprio tempo de execução dos testes. A integração síncrona, para funcionar, exige testes que executem rapidamente. Mais de cinco minutos para integrar já é um problema. Kent Beck costuma dizer: se essa atividade é difícil, execute-a freqüentemente. Fazer builds que executem rapidamente é desafiador. É algo que exige atenção permanente. A integração síncrona nos obriga a ter essa atenção e nos leva a melhorar os testes quando o tempo cresce. Na assíncrona, é fácil demais deixar os testes demorarem cada vez mais e não fazer nada a respeito.

No meu entender, essa é uma questão sistêmica, ou seja, no curto prazo, trabalhar com o CruiseControl pode parecer uma boa idéia, pela aparente velocidade que ele traz ao processo de integração. No médio e longo prazo, entretanto, o comportamento da equipe, influenciado pelas facilidades oferecidas pelo CruiseControl, atrapalham o projeto. Digo isso com base no que pude observar em projetos que usavam o CruiseControl. Entretanto, cada projeto é uma realidade. Se no seu caso o CruiseControl funciona e não causa os problemas sistêmicos que mencionei, use-o. No meu caso, ainda prefiro a integração síncrona.

Tags , , ,  | 5 comentários

O que você achou? Coloque seus comentários e sugestões abaixo!

Acompanhe o RSS dessa página.

Comentários (5 até o momento)

  1. AkitaOnRails disse aproximadamente 10 horas depois:

    Discussão interessante, mas fiquei com uma pulga atrás da orelha.

    Independente de filosofias, na prática eu prefiro fazer commits o tempo todo. Às vezes depois de mudar uma única função, ou uma única linha. Se eu estivesse num ambiente onde a única forma de se fazer o commit fosse rodando a suite de testes antes, eu simplesmente pararia de fazer commits.

    Mas aí eu fico com aquele velho problema: estou no meio do meu dia, vou fazer meu big-commit, só no fim do dia. Putz, mudei de idéia, estes 6 arquivos que mudei na verdade não era assim que queria fazer. Bom, só dar um revert ... hm, mas eu não fiz commits constantes. Bom, só me resta lembrar de cabeça o que eu fiz e dar um 'rollback-manual'.

    Ou, se eu realmente estiver num ambiente hostil, instalo darcs, git ou outro repositório decentralizado com interface a Subversion. Ah! Agora sim, farei meu desenvolvimento inteiro sem nunca usar o repositório. Principalmente se eu estiver trabalhando num módulo paralelo com pouca interação com outros módulos. Ao final da semana eu sincronizo os repositórios, retiro possíveis conflitos e faço o super-big-commit.

    Vai da disciplina de cada desenvolvedor. 'bem, acabei de fazer uma mudança importante, melhor rodar a suite de testes para garantir que nada quebrou'. Ou, 'bom, vou criar um novo componente, melhor escrever meus testes antes'. Assim por diante.

    Meus dois centavos. Cada deve equipe trabalhar da maneira como achara melhor. CruiseControl é um bom sistema, não sei se eu usaria, mas se é bom o suficiente para ThoughtWorks poderia ser bom para mim. XP funciona bem para várias equipes, talvez funcione comigo. Ainda não sei, preciso me convencer. Por enquanto fico com minha rotina de escrever meu código no meu ritmo, rodo meus teste, faço commits quando quiser, ou quando precisar.

  2. Marcelo Baltar disse 2 dias depois:

    Olá! Voltei! rs

    Fiquei lisonjeado de meu comentário merecer outro post! Sério!

    Bom, realmente no meu comentário anterior "ágil" ficou parecendo sinônimo de "veloz", "rápido", etc. Claro que quando falamos de "metodologias ágeis" a coisa é bem mais ampla. Em especial, o "feedback", que você bem citou, e que, para mim, é um dos pontos chaves para se conseguir entregar um sistema que realmente tenha valor para o cliente. Maiores detalhes nos excelentes artigos deste site. :)

    Mas você também falou do "comportamento da equipe". E aqui acho que encontramos a grande diferença entre os problemas que você tem encontrado com o CruiseControl e a forma como estou acostumado a lidar com ele. Nos projetos em que trabalhamos, o fato do repositório estar quebrado é quase um "blocker". "Quase", não totalmente. Quando o código não compila, quando os testes não rodam, etc. a ação deve ser imediata para corrigir este problema.

    "Bom", você deve estar pensando, "mas aí é melhor fazer a integração síncrona, já que vou ter que parar o desenvolvimento mesmo...". O ponto é esse: nos projetos em que tenho trabalhado (grifo, grifo, grifo), isso acontece pouquíssimo, talvez pelo tipo de sistema/forma de trabalho, divisão de tarefas, maturidade da equipe, testes, etc., etc... E quando ocorre, a baixa granularidade dos commits permite uma resolução rápida. Então, na minha avaliação o custo/benefício tem compensado.

    Tenho que confessar que não tenho experiência com a integração síncrona para fazer o paralelo. Fiquei apenas com a impressão (como o Akita, talvez), que ela cria um overhead meio indesejado às vezes. Não posso falar com tanta propriedade sobre uma ser melhor que a outra, deixo isso para usted. :)

    Comprometo-me a fazer uma experiência com a síncrona por um tempo e, se tiver oportunidade, dou notícias. Onde posso comprar um Bob Esponja? :)

    E também experimentar o git, Akita. Gosto muito dessa idéia de repositório descentralizado!

    Abraços!

  3. Marcelo Baltar disse 3 dias depois:

    Só completando: nosso trunk no SVN nunca tem código que irá para o cliente, por isso ele não é "sagrado" para nós, no sentido de nunca poder estar quebrado. As tags, sim. Nelas estarão os releases que iremos distribuir e aí a coisa é séria. O paciente só vai pra lá com a barriga fechada. :)

  4. Celestino Gomes disse 6 dias depois:

    Concordo: O que está no trunk não vai para o cliente, mas imagine. Final do dia, meus pares "commitam" e vão para casa. Na manhã seguinte, depois de uma bela noite de sono (desenvolvedor dorme?), checkout para os pares e... BOOM! Testes quebrando... Tudo bem, um par vai dar conta dos testes quebrando, mas e o outro par, vai pegar outro cartão, mas tendo a suite de testes quebrando em algo que não está trabalhando?

    Bom, minha situação é a inversa a sua Marcelo, eu nunca trabalhei com integração assincrona e compartilho do mesmo sentimento que o Vinícius!

    Mas o que sei é que, independente de integração síncrona ou assíncrona, tudo depente de uma equipe bem integrada. Como o pessoal do Grupo Santa Isabel, ter uma Equipe Afinada!

  5. Marcelo Baltar disse 6 dias depois:

    Oi Celestino!

    Respondendo diretamente sua pergunta: sim! :)

    Se estes BOOMs ocorressem diariamente, uma vez por semana, que seja, pode ter certeza que eu pararia com a integração assíncrona. :)

    Mas eles só tem chance de ocorrer, na grande maioria dos casos, em big refactories. Mas aí não tem jeito, a equipe toda tem que estar mais envolvida mesmo.

    Abraços!