Controle seus projetos legados no TFS

Quem disse que é preciso estar na versão mais nova das linguagens de programação da moda para poder adotar práticas de DevOps e usar uma ferramenta de ALM como o TFS ou o VSTS?

Nesta série de posts, quero mostrar como a manutenção de seus projetos legados pode ser muito mais simples do que você imagina se você se permitir experimentar.

 

Continue lendo “Controle seus projetos legados no TFS”

Como é licenciado o serviço de build do Visual Studio Team Services?

Há um tempinho atrás surgiu dentro do time de ALM da Lambda3 uma rica discussão sobre o modelo de licenciamento do serviço de Build do Visual Studio Team Services (VSTS).

O quê? Você não sabia que os builds no VSTS são cobrados? Então é melhor você ler este post.

Continue lendo “Como é licenciado o serviço de build do Visual Studio Team Services?”

Azure DevTest Labs é legal pra caramba!

Nesta semana na Lambda3 fiz um brown bag sobre Azure DevTest Labs, recurso do Microsoft Azure que foi lançado oficialmente na semana passada.

Do que se trata? Bem, se hoje você precisa implorar “pelamordedeus” na sua empresa para conseguir uma máquina, VM, servidor ou algo que o valha, certamente vai querer saber o que o DevTest Labs tem a oferecer.

Continue lendo “Azure DevTest Labs é legal pra caramba!”

Configurando um URL amigável no TFS

imageConfigurar o TFS já deixou, há muito tempo, de ser algo complicado – mesmo considerando que uma instalação típica de TFS é composta de vários servidores além do próprio TFS (SQL Server, SharePoint etc.). Esta característica, entretanto, torna uma atividade ainda um tanto complicada: criar um URL amigável para o TFS, que seja aplicado a todos os seus componentes. Continue lendo “Configurando um URL amigável no TFS”
240

Como automatizar builds no Windows XP com TFS 2013

imageA 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:

  1. 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;
  2. 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:

Programa de Instalação do TFS 2010 com a opção de Build selecionada
299

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:

Associando o novo serviço de build ao TFS 2013
186

Agora, configure o serviço. Hospedaremos um controlador e seu(s) agente(s):

Criando um controlador e um agente no serviço de build 2010
205

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):

TFS 2013 com os modelos de processo do 2010 para uso no agente de build 2010
175

Conclusão

Viu como dá para ter um agente de build 2010 rodando em um computador Windows XP(*) juntamente com sua infraestrutura TFS 2013?

Agente de teste 2010 rodando num computador Windows XP (Server 2003)
205

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.