Ah, molesta. Visual Studio 2003 y Control de Crucero.NET. Sencillo y elegante. Un script NAnt básico para construir la solución y listo. Ejecute NUnit, la salida va a un formato que CC pueda entender y el tío de Bob. Déjame cuantificar esto. Nuestro servidor de crucero tiene un cliente Subversion (línea de comando) y el SDK .NET 1.1. Visual Studio no está instalado porque, obviamente, es un servidor y Cruise solo necesita algo con lo que construir el sistema.
Ingrese a Visual Studio 2005. Recientemente configuré CI para nuestros proyectos de 2005, pero es simplemente feo, en muchos sentidos. Primero, intentamos que el sistema se compilara utilizando MSBuild. Eso estuvo bien porque simplemente puedes ingresar esto:
msbuild /t:rebuild nombre_solución.sln
(o cualquier objetivo que quieras como Depurar o Liberar)
Como dije, si eso es todo, no fue problema, pero se pone muy feo muy rápido.
Primero están los proyectos de prueba unitaria VSTS. Todo el equipo está equipado con Visual Studio Team Suite. Una propuesta costosa, pero hecha hace mucho tiempo por alguien más sabio que yo. Aunque no hay problema. Realmente no usamos mucho el Administrador de pruebas, no hay pruebas web automatizadas, por lo que simplemente escribimos pruebas unitarias (y las ejecutamos con el excelente TestDriven.NET de Jamie Cansdale). Sin embargo, cuando MSBuild consigue una solución que contiene un proyecto de prueba unitaria VS, necesita un conjunto adicional de ensamblajes (ensamblajes enterrados en GAC_MSIL y otros lugares). El fragmento del archivo ccnet.config para poner en marcha MSBuild fue bastante sencillo:
A través de la fuerza bruta (ejecute MSBuild, averigüe qué ensamblaje necesita, vaya a buscarlo, haga espuma, enjuague, repita) pude obtener una solución de 2005 (con proyectos de prueba unitaria) para compilar. Sin embargo, ejecutar las pruebas es otra historia. Una vez más, la fuerza bruta reinó aquí mientras pasaba una o dos horas ejecutando MSTest.exe para intentar convencer a un par de cientos de pruebas unitarias para que se ejecutaran. La entrada cc.config para obtener algunas pruebas unitarias se parece a esto:
Recuerde que dije que este servidor no tenía Visual Studio instalado. Para las soluciones VS2005, acabo de instalar .NET SDK 2.0 y fue suficiente. Aunque MSTest.exe no está incluido, tomé el archivo (y es un loco conjunto de DLL adicionales esparcidos por todo el disco duro) de otro sistema y lo pegué donde estaba el EXE para que fuera feliz.
No hay riesgo de ejecutar MSTest contra un proyecto de prueba unitaria. Comencé a ejecutar la prueba, pero luego encontré un error COM loco (CLSID no registrado) y eso fue suficiente para mí. De ninguna manera voy a rastrear todas las estúpidas configuraciones de registro COM para Visual Studio 2005. ¿Y qué diablos fue esto? COM? Pensé que nos habíamos deshecho de eso hace unos 3 compiladores.
Así que me vi obligado a instalar un Team Suite completo en el servidor. Está bien, voy a morder. Quiero decir, no necesito todo para que todo esté bien (me sigo repitiendo mientras veo cómo se llenan un millón de entradas de registro). Unas horas más tarde, estoy mirando mi símbolo del sistema nuevamente y escribo mi comando MSTest.exe. Y aparece un cuadro de diálogo. Sí, un cuadro de diálogo modal que me dice que algo anda mal (no recuerdo los detalles pero no fue muy informativo).
Visual Studio se instaló bien y pude compilar, ejecutar y construir la solución que estaba intentando, pero probar desde la línea de comandos con MSTest.exe fue imposible. No importa cuánto lo intenté, cuánto limpié o cuántas vírgenes sacrifiqué, simplemente no funciona. Y hay otro problema. Con 2003 y nuestras pruebas NUnit, obtenemos algunas buenas estadísticas. Horarios, mensajes informativos, todo eso bueno. Con MSTest no obtenemos nada (aparte de x número de pruebas ejecutadas y tal vez una falla, pero no pude llegar tan lejos para ver si daría los detalles de la falla). Además de eso, el registrador MSBuild muerde y produce alrededor de 10,000 líneas de galimatías que no son muy útiles. Sí, podría dedicar mi tiempo a escribir un nuevo xslt para hacerlo bonito, recortar las líneas "Todo estuvo bien" que llenan el registrador de tareas de MSBuild, pero creo que eso no es un valor agregado a mis tarifas.
Aquí hay un correo electrónico de muestra que recibí de la compilación y que le da una idea de lo inútil que es una combinación CC.NET/MSBuild/MSTest:
BUILD SUCCESSFUL
Proyecto: NOMBRE DEL PROYECTO
Fecha de construcción: 8/12/2006 8:08:30 a.m.
Duración: 00:00:55
Solicitud de integración: intervaloTrigger desencadenó una compilación (ForceBuild)
Errores (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): error MSB4041: el espacio de nombres XML predeterminado del proyecto debe ser el espacio de nombres XML de MSBuild. Si el proyecto está creado en formato MSBuild 2003, agregue xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " al archivo <Project>. elemento. Si el proyecto se creó en el formato antiguo 1.0 o 1.2, conviértalo al formato MSBuild 2003.
Advertencias (1)
SourceReportsServerReportsServerReports.rptproj (,): advertencia MSB4122: Error al escanear las dependencias del proyecto "SourceReportsServerReportsServerReports.rptproj". El espacio de nombres XML predeterminado del proyecto debe ser el espacio de nombres XML de MSBuild. Si el proyecto está creado en formato MSBuild 2003, agregue xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " al archivo <Project>. elemento. Si el proyecto se creó en el formato antiguo 1.0 o 1.2, conviértalo al formato MSBuild 2003. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
Pruebas ejecutadas: 0, Fallas: 0, No ejecutadas: 0, Tiempo: 0 segundos
No se realizan pruebas
Este proyecto no tiene ninguna prueba.
Modificaciones desde la última compilación (0)
Es feo. Realmente feo. MSBuild produce un montón de resultados locos. Escribir un nuevo archivo MSBuild no es un paseo por el parque e incluso para alguien como yo que conoce bastante bien NAnt, todavía estoy entendiendo cómo MSBuild hace las cosas. Tuve que crear una configuración especial dentro de Visual Studio para omitir nuestro proyecto de Informe porque MSBuild no puede compilarlos (de ahí el objetivo AutomatedBuild anterior, que no es la misma configuración que usan nuestros desarrolladores y algo que no me gusta hacer porque es una punto de un servidor CI, compilaciones consistentes para todos).
Según el resultado anterior, Cruise dijo que la compilación estuvo bien, pero apareció un mensaje de error en el registrador de MSBuild (nuestro proyecto de informe). Este es un proyecto de 2005, por lo que la información no tiene sentido (creo que es un error registrado pero quién sabe cuándo podría solucionarse). Y realmente no puedo integrar la salida de MSTest en el correo electrónico porque, bueno, no hay ninguna. Hay aproximadamente un centenar de pruebas en este proyecto, pero el registrador no produce nada.
Además, hay algunos tipos de proyectos que MSBuild no puede manejar y, nuevamente, se necesita un genio para crear un archivo MSBuild (incluso usando algo interesante como MSBuild Sidekick) que pueda llamar a otra tarea de MSBuild y excluir ciertos proyectos. Ciertamente, esto no es tan fácil como lo era en 2003, cuando acababa de crear una lista de exclusión (excluimos nuestra aplicación cliente porque no había una licencia adicional para el control de la red y apareció un cuadro de diálogo modal cuando incluso la versión de prueba fue revisada por el compilador).
Vale, esto es más que nada una perorata, pero hay algo de sabiduría aquí. La integración continua no tiene por qué ser tan difícil. CruiseControl.NET es una herramienta excelente y muy flexible con nuevas herramientas y la integración de resultados de esas herramientas. Sin embargo, cuando esas herramientas requieren un millón de configuraciones de registro e incluso más archivos DLL (colocados en lugares muy específicos, créanme, no pueden simplemente tirarlos al GAC y dar por terminado el día) y deshacerse de trozos de XML que ningún simple mortal (bueno tal vez DonXml podría) podría traducir, simplemente está mal. Y en cuanto al Team Build integrado que nos pudo proporcionar, es tan inútil como a) no puede programar compilaciones para que se activen mediante comprobaciones de código y b) nuevamente requiere que se instale un cliente Team Suite completo en el servidor. . En el peor de los casos, cuando comencé a configurar servidores CC.NET, me tomó 4 horas. Ahora puedo hacerlo en una hora (lo que incluye probar la compilación del primer proyecto). Ya pasé un buen día intentando conseguir algo para compilar. Se está compilando ahora, pero el resultado es malo y no se ejecutan pruebas y eso simplemente no es lo suficientemente bueno para mí. Puede ejecutar MSBuild y (tal vez) MSTest con CruiseControl.NET. No es imposible. Si instala el cliente completo y sus proyectos son "perfectos", funcionará, pero el resultado no es tan bueno y verá cómo la CPU de su servidor se bloquea cuando se realizan las compilaciones.
Mi consejo es evitar intentar combinar MSBuild, MSTest y CruiseControl y seguir con NAnt y NUnit (usando MSBuild si es necesario al crear soluciones 2005).
No hace falta decir que estoy considerando una opción en este momento. Volcar la instalación de VS2005 en el servidor, cambiar todas nuestras pruebas unitarias a NUnit y usar NAnt para hacer todo (y simplemente llamar a MSBuild como una tarea ejecutiva para proyectos VS2005). Todavía necesito ejecutar proyectos de 2003 para que nuestro servidor CI se vea como un monstruo de Frankenstein cuando termine, construyendo proyectos VS2003 y VS2005, ejecutando NUnit, MSBuild, NAnt, Simian, FxCop y cualquier otra cosa que tengamos en nuestro mezcla. Incluso teniendo en cuenta que, al utilizar NAnt, la salida será más sencilla (y se integrará bien con CC.NET), la salida de prueba será útil e informativa, y no necesito instalar un software de 15.000 dólares en un servidor que tenga la clara posibilidad de para que aparezca un cuadro de diálogo modal algún día cuando no pueda encontrar alguna clave de registro.
Grrr. Argh.