¿Cómo y por qué configuro una máquina de compilación C #? [cerrado]

Estoy trabajando con un pequeño equipo de desarrollo (4 personas) en un proyecto de C #. He propuesto configurar una máquina de compilación que haga compilaciones y pruebas nocturnas del proyecto, porque entiendo que esto es algo bueno. El problema es que no tenemos mucho presupuesto aquí, así que tengo que justificar el gasto a los poderes fácticos. Entonces quiero saber:

Actualización: Jenkins es la versión más actualizada de Hudson. Todos deberían estar usando Jenkins ahora. Actualizaré los enlaces en consecuencia.

Hudson es gratuito y extremadamente fácil de configurar y se ejecutará fácilmente en una VM.

En parte de un viejo post mío:

Lo usamos para

• Implementar servicios de Windows
• Implementar servicios web
• Ejecute MSTests y muestre tanta información como cualquier prueba junit
• Lleve un registro de tareas bajas, medianas y altas
• advertencias de tendencia y errores

Estas son algunas de las cosas .net integradas que Hudson admite

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• fxcop
• stylecop
• advertencias del compilador
• tareas de código

Además, Dios no lo quiera, está utilizando una fuente visual segura, también lo admite . Te recomiendo que eches un vistazo al artículo de Redsolo sobre la construcción de proyectos .net usando Hudson

Tus preguntas

• P : ¿Qué tipo de herramientas / licencias necesitaré? En este momento, utilizamos Visual Studio y Smart Assembly para compilar, y Perforce para el control de código fuente. ¿Necesitaré algo más o hay un equivalente de un trabajo cron para ejecutar scripts automatizados?

• R: Acabo de instalar Visual Studio en una copia nueva de una VM que ejecuta una instalación nueva y parcheada de un sistema operativo Windows Server. Entonces necesitarías las licencias para manejar eso. Hudson se instalará como un servicio de Windows y se ejecutará en el puerto 8080 y configurará con qué frecuencia desea que escanee su repositorio de código en busca de código actualizado, o puede indicarle que se compile en un momento determinado. Todo configurable a través del navegador.

• P: ¿Qué, exactamente, me dará esto, aparte de una indicación de una construcción rota? ¿Debo configurar proyectos de prueba en esta solución (archivo sln) que serán ejecutados por estos scripts, para que pueda probar funciones particulares? Tenemos, por el momento, dos pruebas de este tipo, porque no hemos tenido el tiempo (o, francamente, la experiencia) para hacer buenas pruebas unitarias.

  R: Recibirá un correo electrónico la primera vez que una compilación falla o se vuelve inestable. Una compilación es inestable si una prueba unitaria falla o se puede marcar como inestable a través de cualquier número de criterios que establezca. Cuando falla una prueba o construcción de unidad, se le enviará un correo electrónico y le dirá dónde, por qué y cómo falló. Con mi configuración, obtenemos:

  • lista de todas las confirmaciones desde la última compilación de trabajo
  • cometer notas de esas confirmaciones
  • lista de archivos modificados en las confirmaciones
  • salida de la consola desde la compilación misma, que muestra el error o la falla de la prueba

• P: ¿Qué tipo de hardware necesitaré para esto?

  A: una máquina virtual será suficiente

• P: Una vez que una compilación se ha terminado y probado, ¿es una práctica común colocar esa compilación en un sitio ftp o tener alguna otra forma de acceso interno? La idea es que esta máquina haga la compilación, y todos vamos a ella, pero podemos hacer compilaciones de depuración si es necesario.

  R: Hudson puede hacer lo que quiera con él, lo que incluye identificarlo a través del hash md5, cargarlo, copiarlo, archivarlo, etc. Lo hace automáticamente y le proporciona un largo historial de artefactos de construcción.

• P: ¿Con qué frecuencia debemos hacer este tipo de compilación?

  R: Tenemos nuestro SVN de encuesta cada hora, buscando cambios en el código y luego ejecutando una compilación. Nocturno está bien, pero en cierto modo no vale la pena OMI ya que lo que has trabajado ayer no estará fresco en tu mente en la mañana cuando entres.

• P: ¿Cómo se gestiona el espacio? Si hacemos compilaciones nocturnas, ¿deberíamos mantener todas las compilaciones antiguas, o comenzar a deshacernos de ellas después de aproximadamente una semana?

  R: Eso depende de usted, después de tanto tiempo muevo nuestros artefactos de compilación al almacenamiento a largo plazo o los elimino, pero todos los datos que se almacenan en archivos de texto / archivos xml que guardo, esto me permite almacenar el registro de cambios, los gráficos de tendencias, etc en el servidor con muy poco espacio consumido. También puede configurar Hudson para que solo evite los artefactos de un número final de compilaciones

• P: ¿Hay algo más que no esté viendo aquí?

  R: No, ve a buscar a Hudson ahora mismo, ¡no te decepcionará!

Hemos tenido mucha suerte con el siguiente combo:

1. Visual Studio (específicamente, usando la herramienta de línea de comandos MSBuild.exe y pasándole nuestros archivos de solución. Elimina la necesidad de scripts de msbuild)
2. NAnt (como la biblioteca de sintaxis / tarea XML mejor que MSBuild. También tiene opciones para operaciones de control de src P4)
3. CruiseControl.net : panel web integrado para monitorear / iniciar compilaciones.

CCNet ha incorporado notificaciones para enviar correos electrónicos cuando las compilaciones tienen éxito / fallan

Sobre la justificación: esto quita la carga de los desarrolladores que realizan compilaciones manuales y hace mucho para eliminar el error humano de la ecuación. Es muy difícil cuantificar este efecto, pero una vez que lo hagas, nunca volverás. Tener un proceso repetible para construir y lanzar software es primordial. Estoy seguro de que has estado en lugares donde crean el software a mano y sale a la luz, solo para que tu chico de compilación diga "¡Vaya, debo haber olvidado incluir esa nueva DLL!"

En hardware: tan potente como puedas conseguir. Más potencia / memoria = tiempos de construcción más rápidos. Si puede permitírselo, nunca se arrepentirá de tener una máquina de construcción de primer nivel, sin importar cuán pequeño sea el grupo.

En el espacio: ayuda a tener mucho espacio en el disco duro. Puede crear sus scripts NAnt para eliminar archivos intermedios cada vez que se inicia una compilación, por lo que el verdadero problema es mantener los historiales de registro y los instaladores de aplicaciones antiguas. Tenemos software que monitorea el espacio en disco y envía alertas. Luego limpiamos el disco manualmente. Por lo general, debe hacerse cada 3-4 meses.

En las notificaciones de compilación: Esto está integrado en CCNet, pero si va a agregar pruebas automatizadas como un paso adicional, compóngalo en el proyecto desde el principio. Es extremadamente difícil respaldar las pruebas de ajuste una vez que un proyecto se hace grande. Hay toneladas de información sobre marcos de prueba (probablemente también una tonelada de información sobre SO), por lo que diferiré en nombrar cualquier herramienta específica.

En mi lugar de trabajo anterior usamos TeamCity . Es muy fácil y poderoso de usar. Se puede usar de forma gratuita con algunas restricciones. También hay un tutorial sobre Dime Casts . La razón por la que no usamos CruiseControl.NET es que tuvimos muchos proyectos pequeños y es bastante doloroso configurar cada uno en CC.NET. Recomiendo encarecidamente TeamCity. Para resumir si te interesa el código abierto, CC.NET es el abuelo con una curva de aprendizaje ligeramente superior. Si su presupuesto le permite definitivamente ir con TeamCity o ver la versión gratuita.

¿Cómo? Echa un vistazo al blog de Carel Lotz .

¿Por qué? Hay varias razones en las que puedo pensar:

• Una compilación funcional, cuando se implementa correctamente, significa que todos los desarrolladores pueden compilar en su máquina cuando la compilación es verde
• Una construcción funcional, cuando se implementa correctamente, significa que está listo para implementar en cualquier momento
• Una compilación de trabajo, cuando se implementa correctamente, significa que todo lo que liberes ha hecho un viaje a tu sistema de control de fuente.
• Una construcción funcional, cuando se implementa correctamente, significa que se integra temprano y con frecuencia, lo que reduce su riesgo de integración.

El artículo de Martin Fowler sobre Integración continua sigue siendo el texto definitivo. ¡Échale un vistazo!

El argumento principal a favor es que reducirá el costo de su proceso de desarrollo, al alertarle lo antes posible de que tiene una compilación rota o pruebas fallidas.

El problema de integrar el trabajo de múltiples desarrolladores es el principal peligro de hacer crecer un equipo. Cuanto más grande sea el equipo, más difícil será coordinar su trabajo y evitar que jueguen con los cambios del otro. La única buena solución es decirles que "se integren temprano y con frecuencia", registrando pequeñas unidades de trabajo (a veces llamadas "historias") a medida que se completan.

Debe hacer que la máquina de compilación se reconstruya CADA vez que se realicen algunos controles, durante todo el día. Con Cruise Control, puede obtener un icono en su barra de tareas que se vuelve rojo (¡e incluso habla con usted!) Cuando se rompe la construcción.

A continuación, debe realizar una compilación limpia completa todas las noches donde la versión de origen está etiquetada (dado un número de compilación único) que puede elegir publicar para sus partes interesadas (gerentes de producto, personal de control de calidad). Esto es para que cuando se reporta un error, esté en contra de un número de compilación conocido (eso es extremadamente importante).

Idealmente, debe tener un sitio interno donde se puedan descargar las compilaciones, y tener un botón en el que pueda hacer clic para publicar la compilación nocturna anterior.

Solo trato de construir un poco sobre lo que dijo mjmarsh, ya que sentó una gran base ...

• Estudio visual. MSBuild funciona bien.
• NAnt .
• NantContrib . Esto proporcionará tareas adicionales, como las operaciones de Perforce.
• CruiseControl.net . De nuevo, esto es básicamente su "panel de compilación".

Todo lo anterior (excepto VS) es de código abierto, por lo que no está buscando ninguna licencia adicional.

Como mencionó Earwicker, construya temprano, construya a menudo. Saber que algo se rompió y que puedes producir un producto es útil para atrapar cosas desde el principio.

NAnt también incluye tareas para nunit / nunit2 , por lo que en realidad puede automatizar sus pruebas unitarias. Luego, puede aplicar hojas de estilo a los resultados y, con la ayuda del marco proporcionado por CruiseControl.net, obtener resultados de prueba unitarios legibles e imprimibles para cada compilación.

Lo mismo se aplica al ndoc tarea . Tenga su documentación producida y disponible, para cada compilación.

Incluso puede usar la tarea ejecutiva para ejecutar otros comandos, por ejemplo, producir un Instalador de Windows usando InstallShield.

La idea es automatizar la construcción tanto como sea posible, porque los seres humanos cometen errores. El tiempo dedicado por adelantado es tiempo ahorrado en el camino. La gente no tiene que cuidar a la construcción pasando por el proceso de construcción. Identifique todos los pasos de su compilación, cree scripts de NAnt para cada tarea y cree sus scripts de NAnt uno por uno hasta que haya automatizado completamente todo su proceso de compilación. También pone todas sus compilaciones en un solo lugar, lo cual es bueno para fines de comparación. ¿Algo se rompió en Build 426 que funcionó bien en Build 380? Bueno, existen los entregables listos para probar: cógelos y pruébalos.

• No se necesitan licencias. CruiseControl.net está disponible gratuitamente y solo necesita el SDK .NET para construir.
• Un servidor de compilación, incluso sin pruebas unitarias automatizadas, proporciona un entorno controlado para las versiones de compilación. No más "John generalmente construye en su máquina, pero está enfermo. Por alguna razón no puedo construir en mi máquina"
• En este momento tengo uno configurado en una sesión de PC virtual.
• Si. La construcción necesita ser volcada en algún lugar accesible. Las compilaciones de desarrollo deberían tener la depuración activada. Release build debería tenerlo apagado.
• Con qué frecuencia depende de usted. Si se configura correctamente, puede construir después de cada check-in con muy poca sobrecarga. Esta es una gran idea si tiene (o planea tener) pruebas unitarias en su lugar.
• Mantenga los hitos y lanzamientos todo el tiempo que sea necesario. Cualquier otra cosa depende de la frecuencia con la que construyes: ¿continuamente? tirar a la basura. ¿Diario? Mantenga el valor de una semana. ¿Semanal? Mantenga el valor de dos meses.

Cuanto más grande sea su proyecto, más verá los beneficios de una máquina de construcción automatizada.

Se trata de la salud de la construcción. Lo que esto te atrapa es que puedes configurar cualquier tipo de cosas que quieras que sucedan con las compilaciones. Entre estos, puede ejecutar pruebas, análisis estático y generador de perfiles. Los problemas se solucionan mucho más rápido, cuando trabajó recientemente en esa parte de la aplicación. Si comete pequeños cambios, casi le dice dónde lo rompió :)

Por supuesto, esto supone que lo configura para compilar con cada registro (integración continua).

También puede ayudar a acercar el control de calidad y el desarrollo. Como puede configurar pruebas funcionales para ejecutar con él, junto con el generador de perfiles y cualquier otra cosa que mejore la retroalimentación al equipo de desarrollo. Esto no significa que las pruebas funcionales se ejecuten con cada registro (puede tomar un tiempo), sino que configura compilaciones / pruebas con herramientas que son comunes a todo el equipo. He estado automatizando las pruebas de humo, por lo que en mi caso colaboramos aún más estrechamente.

Por qué: hace 10 años, nosotros, como desarrolladores de software, solíamos analizar algo en el enésimo grado, obtener la firma de los documentos (escritos en un lenguaje humano) y luego comenzar a escribir el código. Hacíamos una prueba unitaria, una prueba de cadena y luego llegamos a la prueba del sistema: la primera vez que el sistema completo se ejecuta en conjunto, a veces una semana o meses después de que firmamos los documentos. Fue solo entonces que descubrimos todos los supuestos y malentendidos que teníamos cuando analizamos todo.

La integración continua como idea hace que construyas un sistema completo (aunque, inicialmente, muy simple) de principio a fin. Con el tiempo, la funcionalidad del sistema se desarrolla ortogonalmente. Cada vez que realiza una compilación completa, realiza la prueba del sistema temprano y con frecuencia. Esto significa que encuentra y corrige errores y suposiciones lo antes posible, cuando es el momento más barato para corregirlos.

Cómo: en cuanto al cómo, escribí un blog sobre esto hace un momento: [ Haga clic aquí ]

Más de 8 publicaciones van paso a paso sobre cómo configurar un servidor Jenkins en un entorno Windows para soluciones .NET.