Ah, que problema. Visual Studio 2003 e Cruise Control.NET. Simples e elegante. Um script NAnt básico para construir a solução e pronto. Execute o NUnit, a saída vai para um formato que CC pode entender e seu tio de Bob. Deixe-me quantificar isso. Nosso servidor Cruise possui um cliente Subversion (linha de comando) e o SDK .NET 1.1. O Visual Studio não está instalado porque, claro, é um servidor e o Cruise só precisa de algo para construir o sistema.
Entre no Visual Studio 2005. Recentemente configurei o CI para nossos projetos de 2005, mas é simplesmente feio, em muitos aspectos. Primeiro, tentei fazer com que o sistema fosse compilado usando o MSBuild. Tudo bem porque você pode simplesmente inserir isto:
msbuild /t:rebuild nomedasolução.sln
(ou qualquer alvo que você queira, como Debug ou Release)
Como eu disse, se isso é tudo, não há problema, mas fica muito feio muito rápido.
Primeiro, há projetos de teste de unidade VSTS. A equipe está toda equipada com Visual Studio Team Suite. Uma proposta cara, mas feita há muito tempo por alguém mais sábio que eu. Não há problema. Na verdade, não estamos usando muito o Test Manager, não há testes automatizados da web, então apenas escrevemos testes de unidade (e os executamos com o excelente TestDriven.NET de Jamie Cansdales). No entanto, quando o MSBuild obtém uma solução que contém um projeto de teste de unidade VS, ele precisa de algum conjunto adicional de assemblies (assemblies enterrados no GAC_MSIL e em outros locais). O trecho no arquivo ccnet.config para iniciar o MSBuild foi bastante simples:
<msbuild>
<executável>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</executável>
<workingDirectory>D:ccnetprojectsProjectName</workingDirectory>
<projectFile>SolutionName.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<targets>Construir</targets>
<timeout>600</timeout>
<logger>C:Arquivos de programasCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
Através de força bruta (execute o MSBuild, descubra qual montagem ele precisa, vá procurá-lo, ensaboe, enxágue, repita) consegui obter uma solução de 2005 (com projetos de teste de unidade) para compilar. No entanto, executar os testes é outra história. Mais uma vez, a força bruta reinou suprema aqui enquanto eu caminhava por uma ou duas horas executando o MSTest.exe para tentar fazer com que algumas centenas de testes de unidade fossem executados. A entrada cc.config para obter alguns testes de unidade é mais ou menos assim:
<exec>
<executável>C:Arquivos de ProgramasMicrosoft Visual Studio 8Common7IDEMSTest.exe</executável>
<baseDirectory>d:ccnetprojectsProjectName</baseDirectory>
<buildArgs>/testcontainer:SourceTestsUnitTestsbinAutomatedBuildUnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>
Lembre-se que eu disse que este servidor não tinha o Visual Studio instalado. Para as soluções VS2005, acabei de instalar o .NET SDK 2.0 e isso foi bom o suficiente. Embora MSTest.exe não esteja incluído, peguei o arquivo (e é um conjunto maluco de DLLs adicionais espalhadas por todo o disco rígido) de outro sistema e coloquei-o onde estava o EXE para que ficasse feliz.
Não há dados sobre como executar o MSTest em um projeto de teste de unidade. Comecei a executar o teste, mas depois ocorreu um erro louco de COM (CLSID não registrado) e isso foi o suficiente para mim. De jeito nenhum vou rastrear todas as configurações estúpidas do registro COM do Visual Studio 2005. E o que diabos foi isso? COM? Achei que tínhamos nos livrado disso há cerca de 3 compiladores.
Então, fiquei preso à instalação de um Team Suite completo no servidor. Ok, vou morder. Quer dizer, não preciso de tudo, então vai ficar tudo bem (continuo dizendo a mim mesmo enquanto vejo um milhão de entradas de registro serem preenchidas). Algumas horas depois, estou olhando para o prompt de comando novamente e digito meu comando MSTest.exe. E uma caixa de diálogo aparece. Sim, uma caixa de diálogo modal que me diz que algo está errado (não me lembro dos detalhes, mas não foi muito informativo).
O Visual Studio foi instalado corretamente e eu pude compilar, executar e construir a solução que estava tentando, mas testar a partir da linha de comando com MSTest.exe foi impossível. Não importa o quanto eu tentei, o quanto eu limpei ou quantas virgens eu sacrifiquei, simplesmente não funcionou. E há outro problema. Com 2003 e nossos testes NUnit, obtivemos algumas estatísticas interessantes. Horários, mensagens informativas, todas essas coisas boas. Com o MSTest não obtemos nada (além de x número de testes executados e talvez uma falha, mas não consegui chegar tão longe para ver se daria os detalhes da falha). Além disso, o registrador do MSBuild morde e produz cerca de 10.000 linhas de bobagens que não são muito úteis. Sim, eu poderia gastar meu tempo escrevendo um novo xslt para torná-lo bonito, cortar as linhas "Tudo estava bem" que preenchem o registrador de tarefas do MSBuild, mas acho que isso não agrega valor às minhas taxas.
Aqui está um exemplo de e-mail que recebi da compilação que dá uma ideia de quão inútil é uma combinação CC.NET/MSBuild/MSTest:
BUILD SUCCESSFUL
Projeto: NOME DO PROJETO
Data de construção: 8/12/2006 8h08h30
Duração: 00:00:55
Solicitação de integração: intervalTrigger acionou uma compilação (ForceBuild)
Erros (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): erro MSB4041: O namespace XML padrão do projeto deve ser o namespace XML do MSBuild. Se o projeto for criado no formato MSBuild 2003, adicione xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " ao campo <Project> elemento. Se o projeto foi criado no antigo formato 1.0 ou 1.2, converta-o para o formato MSBuild 2003.
Avisos (1)
SourceReportsServerReportsServerReports.rptproj (,): aviso MSB4122: Falha na verificação das dependências do projeto para o projeto "SourceReportsServerReportsServerReports.rptproj". O namespace XML padrão do projeto deve ser o namespace XML do MSBuild. Se o projeto for criado no formato MSBuild 2003, adicione xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " ao campo <Project> elemento. Se o projeto foi criado no antigo formato 1.0 ou 1.2, converta-o para o formato MSBuild 2003. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
Testes executados: 0, Falhas: 0, Não executados: 0, Tempo: 0 segundos
Nenhum teste executado
Este projeto não possui testes
Modificações desde a última compilação (0)
É feio. Realmente feio. O MSBuild produz uma tonelada de resultados malucos. Escrever um novo arquivo do MSBuild não é tarefa fácil e mesmo para alguém como eu, que conhece o NAnt muito bem, ainda estou pensando em como o MSBuild faz as coisas. Tive que criar uma configuração especial dentro do Visual Studio para omitir nosso projeto de relatório porque o MSBuild não pode construí-los (daí o destino AutomatedBuild acima, que não é a mesma configuração que nossos desenvolvedores usam e algo que não gosto de fazer porque é um ponto de um servidor de CI, compilações consistentes para todos).
A partir da saída acima, Cruise disse que a compilação estava correta, mas há uma mensagem de erro que saiu do registrador do MSBuild (nosso projeto de relatório). Este é um projeto de 2005, então a informação não faz sentido (acredito que seja um bug registrado, mas quem sabe quando poderá ser corrigido). E realmente não consigo integrar a saída do MSTest no e-mail porque, bem, não há nenhuma. Há cerca de cem testes neste projeto, mas o logger não produz nada.
Além disso, existem alguns tipos de projetos que o MSBuild não pode controlar e, novamente, é necessário um cientista espacial para criar um arquivo MSBuild (mesmo usando algo legal como o MSBuild Sidekick) que pode chamar outra tarefa do MSBuild e excluir determinados projetos. Isto certamente não é tão fácil como foi em 2003, quando você acabou de criar uma lista de exclusão (excluímos nosso aplicativo cliente porque não havia licença extra para o controle de grade e uma caixa de diálogo modal apareceu quando a versão de teste foi analisada por o compilador).
Ok, isso é principalmente um discurso retórico, mas há alguma sabedoria aqui. A integração contínua não precisa ser tão difícil. CruiseControl.NET é uma ferramenta excelente e muito flexível, com novas ferramentas e integração de resultados dessas ferramentas. No entanto, quando essas ferramentas exigem um milhão de configurações de registro e ainda mais DLLs (colocadas em locais muito específicos, acredite, você não pode simplesmente jogá-las no GAC e encerrar o dia) e despejar montes de XML que nenhum mero mortal (bem talvez DonXml pudesse) seria capaz de traduzir, está simplesmente errado. E quanto ao Team Build integrado que você poderia usar, isso é tão inútil quanto a) você não pode agendar compilações para serem acionadas a partir de verificações de código eb) novamente, ele requer que um cliente Team Suite completo seja instalado no servidor . Na pior das hipóteses, quando comecei a configurar os servidores CC.NET, demorou 4 horas. Agora posso fazer isso em uma hora (o que inclui testar a construção do primeiro projeto). Já passei um bom dia apenas tentando fazer algo para compilar. Está compilando agora, mas a saída é uma porcaria e não há execução de testes e isso não é bom o suficiente para mim. Você pode obter o MSBuild e (talvez) o MSTest em execução com CruiseControl.NET. Não é impossível. Se você instalar o cliente completo e seus projetos estiverem "perfeitos", ele funcionará, mas a saída não será tão quente e você verá a CPU do servidor bater quando as compilações acontecerem.
Meu conselho: evite tentar combinar MSBuild, MSTest e CruiseControl e siga NAnt e NUnit (usando MSBuild se necessário ao criar soluções de 2005).
Escusado será dizer que estou olhando para uma opção agora. Descartando a instalação do VS2005 no servidor, alterando todos os nossos testes de unidade de volta para NUnit e usando o NAnt para fazer tudo (e apenas chamando o MSBuild como uma tarefa executiva para projetos VS2005). Ainda preciso executar projetos de 2003 para que nosso servidor de CI pareça um monstro de Frankenstein quando eu terminar, construindo projetos VS2003 e VS2005, executando NUnit, MSBuild, NAnt, Simian, FxCop e tudo o mais que tivermos em nosso mistura. Mesmo considerando que, usando o NAnt, a saída será mais simples (e se integrará bem ao CC.NET), a saída do teste será útil e informativa, e não preciso instalar um software de US$ 15.000 em um servidor que tenha a possibilidade distinta para abrir uma caixa de diálogo modal algum dia, quando não conseguir encontrar alguma chave de registro.
Grr. Argh.