Tarefa de pré-construção - excluindo a cópia de trabalho no CruiseControl.NET

Question

Atualmente estou no processo de criação de um ambiente de integração contínua no trabalho.Estamos usando VisualSVN Server e CrusieControl.NET.Ocasionalmente, uma compilação falhará e um sintoma é que há conflitos na cópia de trabalho do CruiseControl.NET.Acredito que isso se deva à maneira como configurei as soluções do Visual Studio.Esperamos que quanto mais projetos executarmos neste ambiente, melhor será a nossa compreensão de como configurá-los, por isso não estou questionando por que os conflitos acontecem nesta fase.Para corrigir as compilações, excluo a cópia de trabalho e forço uma nova compilação - isso funciona sempre (atualmente).Então minhas perguntas são:a exclusão da cópia de trabalho é uma parte válida de um processo de construção de integração contínua e como faço para fazer isso?

Tentei soluções incluindo MSTask e chamando delete na linha de comando, mas não estou tendo sorte.

Desculpe por ser tão prolixo - bom trabalho, este é um beta :)

Answer 1

Fazer uma exclusão completa antes ou depois da compilação é uma boa prática.Isso significa que não há chance de seu ambiente de construção coletar um arquivo desatualizado.Sua construção exatamente em relação ao que está no repositório.

Excluir a cópia de trabalho é possível, pois fiz isso com Nant.

Em Nant, eu teria um script limpo em sua própria pasta, fora daquele que desejo excluir, e então o invocaria no CC.net.

Presumo que isso também seja possível com um arquivo em lote.Dê uma olhada no comando rmdir http://www.computerhope.com/rmdirhlp.htm

@pauldoo

Prefiro que meu servidor de CI faça uma exclusão completa, pois não quero nenhuma surpresa quando for fazer uma versão de lançamento, que sempre deve ser feita a partir de um estado limpo.Mas deveria ser capaz de lidar com ambos, não há razão para não

Answer 2

@jamie:Há um motivo pelo qual talvez você não consiga fazer uma compilação limpa sempre que usar um servidor de integração contínua: tempo de compilação.Em alguns projetos em que trabalhei, compilações limpas levam mais de 80 minutos (um projeto incorporado que consiste em milhares de arquivos C++ para checkout e depois compilar em vários destinos).Nesse caso, você deve pesar o benefício do feedback rápido em relação à probabilidade de que uma compilação limpa capte algo que uma compilação incremental não consegue.Em nosso caso, trabalhamos para melhorar e paralelizar o processo de construção e, ao mesmo tempo, permitir compilações incrementais em nossa máquina de CI.Tivemos alguns problemas porque não estávamos fazendo compilações limpas, mas ao fazer uma compilação limpa todas as noites ou semanalmente, você poderia remover o risco sem perder o feedback rápido da sua máquina de CI.

Answer 3

Se você verificar o CC.NET jira há um patch verificado para implementar o CleanCopy para Subversion que faz exatamente o que você deseja e apenas define CleanCopy igual a true dentro do seu bloco de controle de origem, assim como no TFS.

Answer 4

É muito comum e geralmente uma boa prática que qualquer processo de construção faça uma 'limpeza' antes de fazer qualquer construção significativa.Isso evita que quaisquer 'artefatos' de compilações anteriores manchem a saída.

Uma limpeza é essencialmente o que você está fazendo ao excluir a cópia de trabalho.

Answer 5

@Brad Barker

Limpar significa simplesmente eliminar os produtos de construção.

Excluir a cópia de trabalho também exclui todo o resto (arquivos de origem e de projeto, etc.).

Em geral, é bom que sua máquina de construção possa operar sem fazer uma exclusão completa, pois isso replica o que um desenvolvedor normal faz.Quaisquer conflitos encontrados durante a atualização são um aviso antecipado do que seus desenvolvedores podem esperar.

---

@jamie

Para lançamentos formais, sim, é melhor fazer um checkout completamente limpo.Então eu acho que depende do propósito da construção.