Integração contínua é com TeamCity

Recentemente fui convidado a montar o ambiente de integração contínua de uma empresa. O trabalho inicial de verificação dos projetos, testes e builds existente foi feito como manda o figurino. Todos os projetos usavam maven2 e, felizmente, todos eles (inclusive os sub-projetos) possuíam pom’s bem configurados e completamente funcionais.

Os builds e processos internos (manuais) para builds da empresa estavam ok, verificados e funcionando. Feito isso fomos aos testes. Testes!? Ok, vamos ao próximo passo e esqueça os testes por enquanto. O controle de versão era feito com Subversion e os clientes usando Tortoise. A IDE utilizada por toda a organização era o IntelliJ IDEA, mesmo assim o cliente para o SVN era o Tortoise, ainda tento compreender isso até hoje.

wheresthebuild-smallA empresa estava em um momento de criação e manutenção de testes funcionais, então, algumas pessoas estavam trabalhando exclusivamente com Selenium. Era uma boa oportunidade, pois estes testes seriam todos automatizados no ambiente de integração contínua a ser preparado. Uma série de procedimentos foram realizados até chegarmos no ambiente de facto, mas vou pular isso para o post não ficar grande e chato de mais.

Comecei então com a preparação de alguns protótipos. Já trabalhei algumas vezes em ambientes de integração contínua com o CruiseControl e também com o CruiseControl.rb, logo pensei em utilizar um desses. Pesquisando e perguntando a conhecidos cheguei às indicações de: Hudson com muitas indicações, Continuum da Apache, TeamCity da JetBrains e Bamboo da Atlassian, sendo estes dois últimos privados e com custo para licença. Ainda assim estava considerando as duas alternativas pagas logo depois de alguma alternativa da família CC, isto porque a empresa possuía licenças do Jira e Confluence, logo o Bamboo poderia ser uma boa pedida devido a recursos de integração. E também possuíam licenças do IntelliJ IDEA, logo a integração com a IDE poderia ser um ponto positivo para o TeamCity.

Alguma coisa aconteceu comigo e na manhã seguinte eu resolvi começar pelas ferramentas que eu não conhecia. Comecei pelo Hudson, TeamCity e por último Continuum, resolvi parar por aqui pra não perder mais tempo, nesse momento já havia uma escolha muito clara e três dias já haviam se passado.

Hudson

Comecei com o Hudson, foi o menor download (~20mb). Ele pode ser usado em modo stand-alone com uma simplicidade absurda, ideal para quem quer conhecer e testar a ferramenta. A interface foi um ponto positivo desde o começo, eu lembrava sempre do CruiseControl.

A configuração foi simples e rápida, só precisei informar onde estavam o JDK, Ant, Maven2 e o servidor de SMTP de preferência. Nesse momento pensei que ele poderia ter configurado isso tudo – menos o smtp – sozinho, afinal todas as ferramentas citadas possuíam suas variáveis de ambiente devidamente cadastradas, mas tudo bem, vamos continuar.

Criei um primeiro projeto, build com maven2 e repositório SVN, no Hudson isso é um Job. A objetividade foi outro grande fator positivo, logo depois de dizer o nome do job e tipo de build fui para uma tela para preencher informações sobre o projeto, como por exemplo URL do SVN e localização do pom.xml. Mas nesta mesma tela, informações e opções sobre o build também eram exibidas, eu pude definir logo ali se os builds antigos seriam descartados ou não, se o build possuia algum parâmetro adicional, o tipo de notificação e quando e para quem ela seria enviada, opções de agendamento e dependências e algumas outras. Este início achei bem legal pois a objetividade e simplicidade não poderiam ser maiores, ponto para o Hudson.

Este é O Hudson
Este é O Hudson

A disposição das informações e os conceitos informativos também são bem legais, por exemplo a saúde do projeto ser exibida em forma de previsão do tempo: uma nuvem com trovoadas para muitos builds falhando e um sol para muitos builds de sucesso. Suporte a criação de tags no controle de versão, rss feeds, notificações diversas e algumas outras características estão presentes em todos eles. O que me chamou a atenção e vi como um ponto forte no Hudson foram os plugins que podem ser desenvolvidos por terceiros e instalados no seu servidor, dentre os que gostei tem um do twitter, cobertura, clover, PMD, GIT, LDAP, Active Directory, JMeter, Ivy, GCalendar e mais um montão, uma ótima pedida para extender a usabilidade.

Mais um ponto forte é a capacidade de trabalhar com builds distribuídos em vários servidores, para quem tem muitos projetos ou muita gente trabalhando ao mesmo tempo num mesmo projeto e precisa gerar uma release a cada commit esse recurso pode ser muito interessante.

Mas as alegrias não duraram muito. Por algum motivo ainda desconhecido, ao executar qualquer goal do maven2 com o Hudson ele simplesmente ignorava o meu M2_HOME/conf/settings.xml e com isso não identificava o proxy cadastrado para os repositórios, usuário para conexões http, regras para em quais goals os testes serão executados e mais algumas coisas. Ou seja, não consegui fazer nenhum build para os projetos com maven2. Testei com outros projeto usando Ant build e tudo correu super bem. Isso tudo levou quase um dia inteiro, como precisava definir o que seria usado resolvi passar para a próximo opção e desisti do Hudson, infelizmente. É certo que se eu gastar mais algum tempinho eu consigo descobrir a causa do problema e resolve-la, mas nesse momento não foi possível.

TeamCity

Este me assustou no começo, ~224mb de download, 11 vezes maior que o Hudson. Logo pensei que seria uma carroça ou um elefante branco de recursos inúteis, mas me enganei feio, muito feio. O instalador, apesar de grande é bem intuitivo, wizards, frufrus, etc.

Vou falar logo das limitações e licenciamento. O TeamCity tem um esquema interessante de licenciamento, existem duas versões: professional e enterprise. A diferença entre elas é que a professional pode ter somente 20 contas de usuários, 20 build configurations e 3 build agents, além de não ter integração de login com LDAP. Esta versão é gratuita para empresas e projetos comerciais. E a versão enterprise custa, para empresas, U$1.999,00 sem limitações de usuários, build configurations e com integração com LDAP, mas com somente 3 build agents, adicionais são comprados por fora. E a mesma versão enterprise, sem limites de buid agents e sem nenhum outro limite, para projetos open source é gratuita. Então se a sua empresa é pequena ou se você quer usar em um projeto open source, o TeamCity é completamente gratuito.

Instalação concluída e pronto! Não precisava fazer mais nada, só criar e configurar os projetos. Pontos para o TeamCity aqui.

Depois da instalação mais surpresas: a interface do TeamCity, ela é simplesmente fantástica. É bonita, informativa e principalmente muito útil (não recebi jabá pra falar isso não). Todas as configurações, sem exceções, podem ser feitas facilmente na interface. As notificações na interface são muito bem posicionadas e exibem todas informações necessárias só com um simples ‘passar’ do mouse por um link ou ícone – um viva ao prototype.

O recurso de Build Grid é muito bom e funciona de verdade. No TeamCity existe um conceito de Build Agent, que é um computador capaz de executar os builds, o computador onde for instalado o TeamCity já será um build agent, por padrão. E ele permite que você tenha vários builds agents, logo, podemos distribuir o build dos projetos utilizando várias recursos de customização, como por exemplo sempre usar um build agent X, ou usar o que estiver livre ou usar o que deu resultados no menor tempo ou até mesmo simplesmente ir pra fila e deixar que algum build agent assuma a responsabilidade pelo build.

Um ponto que eu não gostei muito na versão enterprise (com as restrições) foi que as notificações são configuradas por usuário, ou seja, um usuário pode escolher não ser notificado por nenhuma ação num determinado projeto. Na versão enterprise sem restrições e na versão professional as notificações podem ser configuradas no perfil do usuário e também no projeto. Este foi um ponto que não gostei muito, mas que não foi o suficiente para não usar a ferramenta.

Um recurso que eu só encontrei no TeamCity e que teve um grande peso na decisão foi o Pre-Tested/Delayed Commit, um recurso que só funciona no TeamCity quando usa-se o plugin do TeamCity na IDE: Eclipse, IntelliJ IDEA ou Visual Studio. Isso garante que no controlador de versão só haverá código funcionando, ou seja, se um commit for quebrar o build ele não será efetivado no controlador de versão. O TeamCity (junto com o plugin) interceptam o commit, executam os testes, o build e se tudo passar, então o commit é feito no controlador de versão, caso contrário o desenvolvedor é notificado da falha.

Continuum

Quando cheguei ao Continuum, confesso que já havia tomado a decisão de usar o TeamCity, então talvez este teste não tenha sido feito com a merecida atenção e dedicação.

Das três alternativas que eu testei nessa semana este foi a que teve a instalação menos idiota mais difícil. Dois comandos, ao invés de um comando (hudson) ou um wizard (teamcity). Mas assim como as outras ferramentas, foi fácil de instalar e testar.

No quesito configuração ele foi o menos eficiente, não encontrou nada previamente instalado, nem mesmo as variáveis de ambiente ele procurou. Precisei configurar manualmente tudo: JDK, maven, repositório do maven, etc.

Na criação dos builds usando maven2 mais problemas. No Continuum o conceito é diferente, ao invés de informarmos a URL do projeto no SVN precisamos informar a URL do pom.xml. Ok, concordei. Mas ao fazer o check-out do pom, antes de iniciar o check-out do projeto ele reclamava de um elemento que estava faltando no pom, algo até então inédito pra mim nas ferramentas de integração contínua e até mesmo para um build com maven2 em modo stand-alone. Tentei criar este elemento, procurei sobre quais valores usar mas mesmo assim não tive sucesso. Com projetos usando Ant build foi tudo ok.

Exceto o problema anterior a utilização não foi ruim e nem tiveram recursos que eu procurei e não encontrei, exceto, é claro, o Delayed Commit.

Conclusão

youbrokethebuild-smallNão preciso nem me esforçar muito para dizer que a opção escolhida na empresa foi o TeamCity. Diversos motivos além da ferramenta contribuíram para isso. A empresa é pequena, quase 20 pessoas e os projetos são grandes, mas são poucos em quantidade, ou seja, as restrições de contas de usuário e build agents não foram problemas para escolhermos o TeamCity. Deixei bem claro sobre estas restrições mas o pessoal gostou da idéia e principalmente da ferramenta em si e, inclusive, já pensam em viabilizar a aquisição da versão professional sem restrições.

As outras ferramentas, na minha opinião, atendem perfeitamente a quase todos ambientes de integração contínua. O Hudson me chamou muito a atenção, gostei de verdade dos recursos, utilização e configuração dele, só não foi escolhido por dois motivos: não ter conseguido fazer o build com maven2 e por não ter suporte a delayed commit, que era uma necessidade atual. Mas com certeza será uma ferramenta que estará no topo da lista quando eu tiver que preparar outro ambiente de integração contínua.

Já o Continuum, este com certeza não teve a avaliação perfeita e justa, como foi a última ferramenta que testei acabou sofrendo muito, sendo sincero não me esforcei muito para testá-lo, os primeiros problemas já eram motivos desanimadores. Mas eu o considerarei novamente numa próxima oportunidade.

imagens retiradas daqui.


8 comentários sobre “Integração contínua é com TeamCity

  1. Post muito bom. Ainda não conhecia o Hudson, parece interessante. Estou utilizando o CruiseControl.NET mas tenho visto muitas recomendações boas do TeamCity. Acho que depois dessas suas recomendações vou instalá-lo para comparar.
    Valeu!

  2. Sou usuário do Hudson a meio ano e só posso elogiar essa ferramenta, utilizo com java (maven 1 e maven 2) e com .NET pois ele é projetado para ser utilizado em varias linguagems alem de possuir muitos plugins e tudo free. Vinha tambem da familia do CC, mas o hudson é bem superior. Sobre o TeamCity não tive a oportunidade de trabalhar.

  3. Estou usando o Team City e gostando mto tbm, mas estou usando a versão free e não sei se por isso não consigo gerenciar os usuários. Gostaria de deixar configurado um usuario para que os desenvolvedores tivesse autonomia para rodar o ANT quando desejassem, mas que eles tivessem acesso somente ao projeto que ele esta participando, sem enxergar os outros configurados. Uma maneira que pensei dar certo, foi restringir que o deploy fosse realizado após o commit em um determinado arquivo (tipo um versão.html). Sempre que o desenvolvedor quisesse realizar um deploy novo, ele incrementaria o versao.html faria um commit no CVS, disparando assim o processo de deploy do ANT. É possível ??

  4. Muito obrigado pela resposta imediata =) !!
    E sobre a segunda questão? Em Build Triggering, consigo configurar que o deploy seja realizado após o tempo q eu quiser depois de um commit. Eu consigo criar uma regra para que esse deploy só seja realizado após um commit de um arquivo em específico? (Acredito q em Build Trigger Rules, porém não encontro nada sobre a sintaxe a ser usada para isso…)

  5. Parceiro, eu estou procurando e ja pesquisei na especificação, mas não encontrei como adicionar novos agentes e uma vez que o usuario encontra-se desconnectado do projeto e sem autorização, como eu faço pra configurar isso, estou usando o TeamCity, qualquer a ajuda ja é válida!

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios são marcados com *