Como automatizar builds no Windows XP com TFS 2013
A inspiração deste post veio da necessidade específica de um de nossos clientes. Ele tem um enorme sistema de ERP escrito em Delphi e que estamos trazendo para dentro do TFS.
Até aí, nada de mais. Não fosse um “pequenino” detalhe:
Versões mais antigas do Delphi - como 5, 6 ou 7 - têm problemas de compatibilidade com novas versões do Windows. Por isso, um agente de build capaz de compilar aplicações Delphi depende do Windows XP.
Ignoremos por um segundo o fato de que o Windows XP não é mais suportado. O cliente precisa manter um sistema legado e nós vamos ajuda-lo com isso.
Mas aí surge outro complicador: o agente de build do TFS 2013, baseado no .NET 4.5.1, requer no mínimo Windows 7. E agora, como resolver esse conflito entre o Windows exigido pelo Delphi (XP) e o exigido pelo agente de build do TFS (7 ou superior)?
A resposta é, na verdade, mais simples do que esperamos. Ela envolve um “truquezinho” relativamente desconhecido: combinar um servidor TFS 2013 com um serviço de build TFS 2010. Sim, é isso mesmo. Você pode usar um agente de build 2010 com um servidor TFS 2013!
Bem, vamos por partes: Por que cargas d’água alguém quereria usar um agente de build antigo ao invés do novo que vem com o TFS 2013? Bem, existem dois motivos para isso:
- Atualização gradual de ambiente: Clientes que já usam o TFS provavelmente têm ambientes com um ou mais servidores de build. Até o TFS 2010, sempre que você atualizava sua versão do TFS (por exemplo, do 2005 para o 2008 ou do 2008 para 0 2010) era obrigado a atualizar também todos os servidores de build. Isso tornava a atualização um processo ainda mais complicado (e arriscado) pois envolvia o roll-out simultâneo em vários servidores. Contudo, desde o TFS 2012, você tem a opção de manter os agentes de build na versão anterior e atualizar só o servidor. Com isso, você poderia atualizar gradualmente os agentes de build num segundo momento;
- Compatibilidade com tecnologias legadas: Se você precisa fazer automação de build de tecnologias que não funcionariam num novo agente TFS 2012/2013 - por exemplo, devido à atualização da versão mínima do Windows ou à atualização do .NET Framework – o ideal seria não atualizar o agente de build. O TFS 2010 (e, por conseguinte, seu serviço de build) foram feitos sobre o .NET Framework 4.0, que é a última versão a suportar o Windows XP. Assim, você pode ter o serviço de build do TFS rodando sobre Windows XP (*).
No nosso caso o motivador foi a compatibilidade com legado. E a solução foi bem simples.
Integrando um agente 2010 a um servidor 2013
Instale em uma máquina Windows XP o TFS 2010. Não esqueça de instalar também o Service Pack 1. Na máquina XP, você precisará apenas do serviço de build:
Depois da primeira fase da instalação (que apenas copia os binários para o servidor) vem a configuração. Comece selecionado sua Team Project Collection no TFS 2013 à qual o serviço de build será associado:
Agora, configure o serviço. Hospedaremos um controlador e seu(s) agente(s):
IMPORTANTE: Sempre precisamos instalar um novo controlador. Não podemos misturar controladores e agentes de versões diferentes.
E finalmente, mas não menos importante: Você deve obter um build process template (o script de build em formato XAML) do TFS 2010. Os agentes de build 2010 não são compatíveis com os arquivos XAML nativos do TFS 2013. Para isso, acesse um servidor TFS 2010 (se você não tiver um, sugiro que baixe a máquina virtual do Brian Keller) e copie os arquivos DefaultTemplate.xaml, LabDefaultTemplate.xaml e UpgradeTemplate.xaml (além de quaisquer templates de build de 2010 que você porventura possa ter):
Conclusão
Viu como dá para ter um agente de build 2010 rodando em um computador Windows XP(*) juntamente com sua infraestrutura TFS 2013?
Um abraço,
Igor
(*) Se você reparou na última figura, deve ter notado que estou, na verdade, usando um Windows Server 2003 (e não um Windows XP). Fiz isso porque: (1) O Windows Server 2003 é a versão servidor do Windows XP. Portanto, do ponto de vista da compatibilidade com o Delphi, atende à nossa necessidade. Além disso, (2) o Windows XP tem um problema de compatibilidade com o Hyper-V que faz com que o desempenho da máquina virtual seja muito comprometido.
10/12/2013 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 4 mins.
