Private Builds e Gated Check-ins

Caixa de diálog de Gated Check-inSe você leu meu último post sobre Private Builds, deve ter notado uma semelhança com a funcionalidade de Gated Check-in.

Para aqueles que não sabem o que é um Gated Check-in, vai aí um resumo de um post que fiz sobre o assunto:

O problema da solução apresentada acima [NA: Uso de Integração Contínua], baseada apenas no servidor de build, é que o check-in precisa ser feito antes de ser validado. Ou seja, em caso de problemas eu necessariamente terei que desfazer manualmente as alterações que quebraram o build. O ideal seria que eu pudesse disparar o buid antes do check-in, só efetivando a alteração no controle de versão se tudo corresse bem. É justamente disso que trata o conceito de gated check-in: As operações de check-in são interceptadas (geralmente usando shelvesets) e redirecionadas para um servidor de build especial. Esse servidor combina o código-fonte que já existe no TFS com as alterações que acabaram de vir do desenvolvedor. Se tudo correr bem, só então é que o check-in será consumado.

Reparou na parte que diz que o TFS “combina o código-fonte que já existe no TFS com as alterações que acabaram de vir do desenvolvedor”? É exatamente isso que faz o Private Build, certo?

Logo, podemos dizer que Private Build e Gated Check-in são a mesma coisa? Bem, quase. Smile

Private Build e Gated Check-in são baseados na mesma infraestrutura que permite a execução de builds baseados em shelvesets. A diferença é o gatilho: enquanto o Private Build é opcional e disparado sob demanda pelo desenvolvedor, o Gated Check-in é obrigatório e disparado no check-in.

Qual é o melhor? Private Build ou Gated Check-in?

Não sei se dá para ser tão simplista assim. Neste caso não há melhor ou pior.

Temos clientes que preferem a segurança do Gated Check-in. Ele reduz drasticamente o risco de quebras no build. Entretanto, ele torna o processo de check-in mais burocrático e lento. Times mais maduros acabam sendo “atrapalhados” pelo Gated Check-in.

Minha opinião pessoal? Use Gated Check-in na branch de desenvolvimento APENAS SE O TIME AINDA NÃO FOR MADURO. Em todos os outros casos, confie no bom-senso do time. Eles usarão o Private Build sempre que necessário.

 

Um abraço,
  Igor

Use Private Builds – e pare de passar vergonha!

TFS Build Wall - painel com status de builds mostrando builds quebrados
184

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! Smile

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”).

Exemplo de definições de build. Usaremos a build CI

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

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…”:

Menu "Queue new build..."
240

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

Caixa de diálogo Queue new build com a opção "What do you want to build?"
244

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!

Caixa de diálogo de criação de shelveset
181

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:

Janela de status do build indicando a execução do build privado
91

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