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.

Entre teste automatizado e implantação automatizada, fico com a implantação

"I pity da fool" - Mr. T“Como assim”, você pode estar pensando, “o Igor não testa o que ele desenvolve?!”

Calma, pequeno padawan. Vou explicar melhor o que eu quis dizer…

Primeiro, a pergunta obrigatória: você usa controle de versão nos seus projetos? Hoje em dia é cada vez mais difícil encontrar alguém que responda “não” a essa pergunta. Aliás, essa é normalmente uma das primeiras coisas que se faz durante o setup de um novo projeto: preparar o controle de versão e já fazer o check-in / commit inicial do seu projeto – antes mesmo de se escrever a primeira linha de código.

Até aqui, tudo bem. Mas e agora? O que fazer depois de configurar o controle de versão?

A resposta depende, naturalmente, de para quem você está perguntando:

  1. Se você perguntar para um adepto do Extreme Go-Horse (ou uma de suas variações), a resposta provavelmente seria “agora é só sair codando!”
  2. Por outro lado, um adepto de ATDD/BDD/TDD diria algo como “hora do Red-Green-Refactor!”

Agora, se perguntar para mim, eu direi: “hora de configurar os builds de CI e CD.”

CI? CD?!

Sim, Continuous Integration (Integração Contínua) e Continuous Deployment (Implantação Contínua). Antes mesmo dos meus testes, configuro meus builds e meu processo de implantação. Só depois é que começo a fazer algum código.

Parece exagero falar de build e deployment antes do software, não? Só que, por conta disso, muitos times deixam para se preocupar com o deployment apenas ao fim do projeto. E, invariavelmente, sofrem um bocado até conseguirem fazer funcionar. E esses times, com um processo essencialmente manual, estão ficando numa situação cada vez mais complicada. Não raro, encontro clientes que às vezes levam horas e mais horas para conseguir publicar alguma coisa em produção! Não seria melhor pensarmos nisso mais cedo para evitar problemas?

Se você ainda não se convenceu, dê uma lida no trecho abaixo do Scrum Guide:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

O trecho em negrito é a chave de onde quero chegar. Ao final de cada sprint, o time de desenvolvimento deve entregar um incremento do produto (do software que está sendo desenvolvido) que seja potencialmente liberável. Em outras palavras, nosso software deve estar num estado em que ele possa, eventualmente, ser colocado em produção. Liberar ou não esse incremento de software para os usuários não deve ser pautado pelo estado do software (“não funciona em produção!”) mas apenas por uma decisão de negócios do Product Owner, que pode ver valor naquele incremento que acabou de ser apresentado. Se o time não exercita o processo de implantação ao longo da sprint, como pode ter certeza de que sua entrega é potentially releasable? E se seu processo de implantação não é automatizado, como pode garantir que ele será reproduzível e consistente?

Mas para o produto ser potencialmente liberável ele também não precisa estar testado? Claro que sim. Mas de uma maneira ou de outra, esse é um problema que a maioria dos times já resolve hoje.

Não quero dizer com isso que testes automatizados não são importantes. Pelo contrário! Lembre-se, apenas, que seus testes automatizados se beneficiam de um processo de build e implantação automatizados. Se começarmos por aí, à medida que os testes forem sendo criados nossos ambientes já estarão prontos para sua execução.

Desde que adotei essa prática – build e implantação configurados logo no início do projeto – tenho levado isso tão a sério que até mesmo coisas que aparentemente não seriam “automatizáveis” entram no balaio. Afinal, automatizar implantação de ASP.NET MVC com WebDeploy não tem absolutamente dificuldade nenhuma. Agora, concorda comigo que coisas não-triviais como pacotes do SQL Server Integration Services, justamente por serem não-triviais, são as que mais se beneficiam de uma implantação automatizada?

E você, o que acha? Dê sua opinião nos comentários!

Um abraço,
Igor