Integração contínua é uma ferramenta importante para garantia de qualidade do código produzido pelo time, certo?

Seu time usa TFS? E usa o Team Build para fazer integração contínua? Legal!

Só tem uma coisa que não é muito legal: ser a pessoa que quebrou o build. Principalmente se, em sua empresa, o status dos builds fica na parede, à vista de todos. Esta foto à direita é do ambiente de desenvolvimento de um de nossos clientes. Temos times mistos (desenvolvedores da Lambda3 e do cliente) trabalhando em projetos hospedados no TFS do cliente. E, acredite: assim que um build é quebrado, TODO MUNDO saca o smartphone do bolso e tira fotos da TV. Provavelmente a “vítima” que quebrou o build vai pagar o almoço e ainda vai ser “trolada” por um tempinho!

Evitar a quebra  do build é fácil, não? Basta compilar o código no seu computador e rodar todos os testes. Só então, se estiver tudo OK, você pode fazer o check-in com a certeza de que o build não será quebrado. Pena que nem sempre as coisas são tão simples assim…

Tem alguns cenários em que nem sempre é viável (ou possível) garantir a integridade do código antes do checkin. Por exemplo: se você está mexendo numa classe de uma biblioteca, que é consumida em várias partes de um grande sistema, você provavelmente precisaria executar novamente todos os seus testes. Não apenas os de unidade (esses são obrigatórios; você deveria executar sempre!) mas também os de integração. E é aí que as coisas começam a ficar mais complicadas.

Testes de integração são, por natureza, como elefantes: grandes, lentos e pesados. Ou seja, muitas vezes não dá para rodar testes de integração da máquina do desenvolvedor – principalmente se há dependência de complexos ambientes de testes que dificilmente poderiam ser reconstruídos no ambiente do desenvolvedor.

Caímos então no dilema: há testes que são inviáveis de se reproduzir no computador do desenvolvedor, por serem muito lentos ou por dependerem de um ambiente caro de se recriar para cada uma das pessoas no time. Nesses casos, o uso do servidor de automação de build é a melhor saída. E nesses casos eu corro o risco de fazer commit de código defeituoso, que quebraria o build e, eventualmente, atrapalharia o trabalho de outros membros do time. Como resolver?

Entra aí o conceito de Private Build: já pensou que legal seria poder rodar um build só seu, usando toda a infraestrutura já montada para a Integração Contínua (CI)? Com esse build você poderia validar o código usando o servidor de build mas, diferente do que acontece em builds de CI, você não precisaria fazer o commit/check-in para disparar o build. Você forneceria seu código ao TFS sem fazer check-in e, portanto, sem atrapalhar os outros! Dessa forma você poderia testar várias vezes seu código, até que estivesse OK. Só então você faria o check-in e dispararia o processo normal de CI.

Vamos ver como fazer isso?

Partiremos da premissa que você tem um ambiente de integração contínua já montado, capaz de rodar todos os seus testes (representado na figura abaixo pela definição de build “CI”).

Agora, faça suas alterações na sua aplicação. Eu espero .

Pronto? Então vamos testar essas alterações!

Clique com o botão direito na definição de build CI e selecione “Queue new build…”:

O “pulo do gato” vem a seguir: em “What do you want to build?”, selecione “Latest sources with shelveset” e, depois, em “Create”:

Vamos, agora, criar um shelveset com nossas alterações. Esse shelveset será usado para a execução do build. Vamos chamar nosso shelveset de PB (de Private Build; poderia ter chamado de qualquer outra coisa). Aí é só clicar em Queue!

Agora vamos ver o que aconteceu: quando você agenda um build privado, o TFS baixa a última versão do código-fonte no controle de versão para o agente de build e depois aplica o shelveset sobre a última versão do código. É como se você tivesse feito check-in do seu código! Entretanto, o TFS distingue builds privados daqueles que são agendados pelas vias comuns. Repare na mensagem indicando que seu shelveset está sendo validado e que, por padrão, o resultado do seu build não é copiado para a drop location:

Em caso de erro você pode corrigir seu código e reagendar um novo build privado – sem atrapalhar ninguém no time!

Viu como é simples usar builds privados? Agora você só quebra build se quiser!

Um abraço,
  Igor

Igor Abade

Igor Abade V. Leite ([email protected]) é Microsoft MVP (Most Valuable Professional) de Visual Studio ALM desde 2006. Palestrante em diversos eventos da comunidade de desenvolvimento de software (TechEd Brasil, The Developers’ Conference, DevOps Summit Brasil, Agile Brazil, Visual Studio Summit, QCON e outros), é também autor de artigos em revistas e sites como o MSDN Brasil. Desde março de 2011 é um dos sócios da Lambda3, uma consultoria especializada em ALM, desenvolvimento de software e treinamentos. Siga-o no Twitter @igorabade.