O que deve ir em um script MSBuild exceto compilação?

Question

Atualmente estou tentando configurar CruiseControl.net, e assim eu me pergunto como dividir minhas tarefas.

Geralmente, eu quero correr testes de unidade (xUnit.net), Arquivo de Ajuda Generation (Sandcastle) e FxCop.

Agora eu só quero saber se eu deveria especificar um novo alvo na configuração msbuild ( "Documentação") e usar isso para executar SandCastle, ou se o que pertence em um script separado? Além disso, msbuild destina-se a construção de algo, então eu acho que NCover, xUnit e FxCop não deve ser parte dela, ou deveriam?

Qual é o escopo pretendido do msbuild?

Answer 1

Coloque quase tudo em scripts MSBuild, para que você e outros desenvolvedores podem executar os mesmos passos localmente via linha de comando. Caso contrário, quando algo der errado com a construção, você tem que depurá-lo no servidor CC. Não é uma experiência agradável de depuração. Além disso, você quer executar a construção localmente antes cometer para se certificar de que funciona.

As poucas coisas que eu não iria colocar em scripts de MSBuild são:

• atualização SVN, como CC tem que fazer isso de qualquer maneira, e você geralmente não quer atualizar ao fazer uma compilação local. (Bem, eu do tipo svn up && msbuild muitas vezes, mas isso é tão curta que eu não precisa colocar isso em um script.)
• Criação e publicação de relatórios de construção; novamente este é o domínio do CC, e não é útil localmente

Quanto à estruturação seus arquivos MSBuild, você vai querer um script de construção "mestre" que você pode usar para construir tudo ou apenas alguns alvos, por exemplo.

• MSBuild /t:Build apenas construir o código de forma incremental
• MSBuild /t:Rebuild para uma limpeza reconstruir
• MSBuild /t:UnitTest para testes de unidade apenas correr
• MSBuild para a escolha mais frequente, dizem, o equivalente a t:Build;UnitTest
• MSBuild /t:All ao código de construção, documentação e instalação limpa, executar todos os testes, e empacotar os resultados

Você também pode adicionar alvos "atalho" para variações populares.

Ter um único arquivo mestre de construção não significa que tudo está definido neste arquivo único; você pode incluir outros arquivos MSBuild e / ou msbuild chamada de forma recursiva para organizar a sua construção. Por exemplo:

• O arquivo mestre proj deve ser relativamente simples; principalmente, deve definir coisas específicas do projeto como a lista de soluções para construir, e específica do projeto substituições
• Deixe o arquivo mestre incluem um único arquivo .targets que contém metas e propriedades padrão; se esforçam para manter este projeto neutro e reutilizável.
• Se o arquivo .targets ficar muito grande, dividi-la em arquivos separados, por exemplo, um para o código, um para ajuda e documentação, um para configuração e embalagem. Deixe seu arquivo .targets principais incluem aquelas sub-arquivos, de modo que o seu arquivo proj ainda precisa incluir apenas um arquivo
• Da mesma forma, você pode dividir o arquivo mestre proj se necessário, por exemplo, pelo subsistema.

Answer 2

Eu tenho um script de construção para projetos individuais, e eu simplesmente acorrentar os de um segunda arquivo de construção na construção de um conjunto ... por exemplo, meus protobuf-net identificadores de arquivo de compilação de versões (SVN) , compilação (MSBuild + NAnt para mono), testando (NUnit), a embalagem (ZIP), etc. é seu processo de construção; fazer o que precisa ;-P Se poderia também, por exemplo, fazer a implantação e documentação, se eu quisesse.

Também depende de como você trabalha; se você estiver usando CruiseControl, ele pode lidar com grande parte desta para você. Quanto a mim, como uma linha de comando passo "construir".