Recentemente o amigo e ex-Lambda3 Osmar Landin iniciou uma série de posts sobre o Jenkins. Apesar de ele normalmente escrever sobre TFS, essa nova série de posts teve uma motivação mais do que justa:

Nem todo mundo pode (ou quer) usar o TFS. Às vezes a melhor (ou a única) solução é partir para um stack open-source. Nesses casos, o que usar para automação de build?

A resposta dele a essa pergunta foi “Jenkins”. Se você se identificou com essa situação, deve ler sua série de posts. Por outro lado, apesar de eu ter me inspirado nos posts dele, minha motivação foi um pouquinho diferente. O que eu quero discutir é:

Eu uso TFS como meu repositório de controle de versão e estou mais que satisfeito. Agora, quero automatizar meus builds. O que faço?

Se você veio a este blog é bem possível que já use – ou que pretenda usar – o TFS. Portanto, vamos falar especificamente sobre automação de build para usuários do TFS.

Automação de build no TFS

Caso você não saiba, o TFS tem sua própria ferramenta de automação de build: o Team Foundation Server Build Service, mais conhecido como Team Build.

Como o TFS tem seu próprio serviço de build, somos levados a crer que a melhor (ou a única) solução para automatizar builds no TFS é usar o Team Build. Só que isso não é necessariamente verdade.

A solução nativa: Team Build

A proposta da Microsoft, desde sempre, era oferecer uma solução completa de ALM. Para isso, era indispensável que houvesse um mecanismo de automação de build disponível out-of-box na ferramenta. Assim, desde a primeira versão do produto temos no Team Build a solução padrão para automação de builds no TFS. Porém, uma coisa é certa: o Team Build mudou bastante nesses quase dez anos de produto:

• 2005-2008: o Team Build tinha uma arquitetura monolítica, difícil de escalar e distribuir. Os scripts de build (chamados de build process templates no linguajar do TFS) eram arquivos XML do MSBuild, que era o motor de build usado pelo Team Build. Desnecessário dizer que a experiência de autoria e personalização de scripts de build estava longe de ser amigável. Ainda por cima, toda e qualquer interação com a ferramenta de builds (consulta a logs, agendamento de builds etc.) era feita apenas através do Visual Studio.
• 2010-2012: o Team Build deu um grande salto em 2010, quando o motor de build deixou de ser o MSBuild para ser substituído pelo Windows Workflow Foundation. Com isso a experiência de autoria de scripts de build passou a oferecer uma interface gráfica – o designer de workflows de WF do Visual Studio – e ganhou novos recursos como o Gated Check-in e a Análise de Impacto em Testes. Entretanto, verdade seja dita: ainda que a experiência de autoria de scripts tenha melhorado bastante, ela não se tornou exatamente amigável. Eu diria que o termo correto aqui seria “menos árida”. Em contrapartida, temos dois lados positivos importantes: a mudança na arquitetura, que passou a ser realmente distribuída, com controladores e agentes de build que podem ser instalados, provisionados e alocados independentemente; e o acesso aos logs de builds, às filas e ao agendamento de builds através da interface web, livrando-nos um pouco das amarras do Visual Studio.
• 2013: Apesar de a versão 2013 não ter grandes mudanças em relação à anterior, há uma que merece destaque: foram incluídos pontos de extensibilidade em PowerShell. Agora é possível inserir scripts PowerShell em pontos estratégicos do build – como antes da compilação ou após os testes, por exemplo – de modo a permitir personalizações simples do script de build, sem a necessidade de editar o XAML do Workflow Foundation.

Provavelmente um dos recursos de maior destaque ao longo das diversas versões do Team Build é o Gated Check-In, que permite uma pré-validação do check-in (ao contrário da Integração Contínua, que faz uma pós-validação). Assim, tornou-se possível oferecer uma segurança adicional ao processo de check-in, recusando um changeset que não satisfaça as condições descritas na definição de build de Gated Check-In. Sei que o Gated Check-In normalmente suscita discussões acaloradas por isso discutir seu mérito está totalmente fora do escopo deste post.

Alternativas? Claro que há várias alternativas ao Team Build no mercado. Conheça abaixo duas delas. Elas definitivamente não são as únicas. Eu as escolhi porque as vejo serem usadas com mais frequência em projetos típicos .NET e Java.

A alternativa open-source: Jenkins

Nascido como um fork do Hudson – uma das mais antigas e conhecidas soluções de CI baseadas em Java – o Jenkins surgiu após algumas mudanças polêmicas de licenciamento e política de relacionamento da Oracle com a comunidade open-source. Na minha humilde opinião, a comunidade do Hudson Jenkins saiu ganhando com isso, pois parece que ganharam uma motivação extra com a liberdade recém-conquistada.

Aliás, por falar em comunidade, esse é de longe um dos pontos mais fortes a favor do Jenkins: ele tem uma comunidade vibrante e participativa, o que se reflete na enormidade de plug-ins disponíveis. Agora, aqui entre nós: podiam dar uma repaginada na UI, né? A aparência velha e desgastada da UI do Jenkins depõe, IMHO, contra a qualidade do software.

Outro ponto forte do Jenkins, em especial quando comparado com o Team Build, é que toda a UI é web. Não há nenhum tipo de configuração ou edição client-side. Mesmo a criação e configuração das definições de build são feitas diretamente no browser, diferente do Team Build que requer o pesado e desajeitado Designer de Workflows do WF. Isso dá uma liberdade e uma flexibilidade muito grandes aos times de desenvolvimento, que não dependem do Visual Studio e podem criar seus Jobs (o termo usado no Jenkins para as definições de build) à vontade, combinando os diversos plug-ins para a construção de um pipeline de build.

Há algum lado negativo no Jenkins? Bom isso depende da sua definição de negativo :-). Vou citar alguns pontos de atenção comuns, comuns principalmente em ambientes corporativos:

• Open-source: Infelizmente isso ainda é um ponto negativo em muitas empresas, que têm preconceito contra software open-source. Se sua empresa tem uma política de só adquirir software comercial, que tenha uma empresa por trás e com uma contrato de suporte bem definido, o Jenkins pode não ser uma opção;
• Feito em Java: O Jenkins é feito em Java. Isso pode parecer bobagem, mas empresas que usam TFS obviamente vão hospedar seus serviços num servidor Windows. Por conta disso, acabam normalmente preferindo soluções .NET (que se integram mais seamlessly a ambientes Windows no geral e ao IIS mais especificamente). Hospedar o Jenkins no IIS requereria um trabalho de configuração adicional;
• Muitas opções: E desde quando isso é um problema? Bem, se você leu o livro Don’t make me think, sabe que opções demais não são necessariamente uma coisa boa. Se tudo que eu preciso do meu servidor de automação de build é indicar o nome de uma solution .NET, um build.xml do Ant ou um pom.xml do Maven, o Team Build acaba sendo mais simples e prático que o Jenkins.

A alternativa comercial: TeamCity

Quando a gente compara o Team Build e o Jenkins pode ficar com a sensação de “oito ou oitenta?” Nesse caso, pode ser que o TeamCity seja o meio-termo – o seu “44” :-).

Tal como o Jenkins, o TeamCity também é um servidor de automação de build extremamente flexível, com uma interface Web rica e flexível. Ainda não tem um ecossistema de plug-ins tão rico quanto o do Jenkins, mas por outro lado tem a seu favor o fato de ser um produto comercial, com uma empresa (a JetBrains) por trás e com uma política de suporte oficial. Para muitas empresas, essa pode ser a condição sine qua non para escolha da ferramenta.

Como decidir?

Sei que escolher uma ferramenta de maneira objetiva não é das tarefas mais simples. Por isso, vou compartilhar alguns critérios que podem ajudá-lo nesse processo. Nem de longe tenho a pretensão de oferecer uma “receita de bolo”, mas apenas um pequeno ponto de partida. Ajuste os itens abaixo como achar melhor.

Escolha o Team Build se…

• … não quer ter de administrar uma outra infraestrutura, com um modelo de segurança e manutenção à parte do TFS;
• … ter uma experiência integrada ao Team Explorer do Visual Studio e do Eclipse for importante para seus desenvolvedores;
• … você não precisa de muitas opções de personalização. Ao invés disso, prefere alguns modelos pré-definidos para os quais possa apenas passar alguns parâmetros;
• … for importante ter o suporte oficial da Microsoft no seu ambiente, pois o Team Build estaria coberto pelo suporte do TFS;
• … Gated Check-In for importante para você;
• … você estiver familiarizado com .NET, MSBuild e/ou Workflow Foundation, pois nesse caso seria mais fácil criar extensões (“plug-ins”) para seu build.

Escolha o Jenkins se…

• … você não tem restrição com open-source nem Java e prefere a flexibilidade da interface web;
• … seus desenvolvedores precisam criar Jobs (definições de build) com tamanha liberdade e variedade que um conjunto pré-definido de modelos não resolveria;
• … seu software e/ou seu ambiente têm alguma peculiaridade que depende de um plug-in que exista no Jenkins e não esteja disponível nem para MSBuild nem para Team Build.

Escolha o TeamCity se…

• … você prefere uma interface Web flexível como a do Jenkins, mas não tem a opção de adotar uma solução open-source e precisa adquirir um produto comercial.

Conclusão

Escolher a melhor ferramenta de build para seus projetos hospedados no TFS pode não ser tão óbvia, afinal. Vários critérios – infraestrutura disponível, custo de manutenção e ecossistema, dentre outros – podem levá-lo a preferir uma outra ferramenta que não o Team Build. Lembre-se: no fim do dia, seu trabalho é entregar software, não manter ferramentas de ALM. Seu servidor de build deve ajudar, não atrapalhar. Escolha aquele que te ajuda mais – e happy coding!

Um abraço,
Igor