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

Question

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 existentes. Así que quiero saber:

¿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 a un trabajo cron para ejecutar scripts automatizados?

¿Qué, exactamente, me conseguirá 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, de modo que pueda tener pruebas de funciones particulares? Tenemos, en este momento, dos pruebas de este tipo, porque no hemos tenido el tiempo (o, francamente, la experiencia) para hacer buenas pruebas unitarias.

¿Qué tipo de hardware necesitaré para esto?

Una vez que una compilación ha sido terminada y probada, ¿es una práctica común colocar esa acumulació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 vayamos a ella, pero podemos hacer compilaciones de depuración si tenemos que hacerlo.

¿Con qué frecuencia debemos hacer este tipo de construcción?

¿Cómo se gestiona el espacio? Si hacemos construcciones nocturnas, ¿deberíamos mantenernos alrededor de todas las construcciones antiguas o comenzar a deshacernos de ellas después de aproximadamente una semana?

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

Me doy cuenta de que este es un tema muy grande, y estoy empezando. No pude encontrar un duplicado de esta pregunta aquí, y si hay un libro por ahí que debería obtener, hágamelo saber.

EDITAR: ¡Finalmente lo puse a trabajar! Hudson es completamente fantástico, y FxCop está demostrando que algunas características que pensamos que se implementaron en realidad estaban incompletas. También tuvimos que cambiar el tipo de instalador de Old-And-Busted vdproj a New Hotness WiX.

Básicamente, para aquellos que prestan atención, si puede ejecutar su compilación desde la línea de comandos, puede ponerla en hudson. Hacer que la compilación se ejecute desde la línea de comandos a través de MSBuild es un ejercicio útil en sí mismo, porque obliga a que sus herramientas sean actuales.

    

Answer 1

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

Hudson es gratis y extremadamente fácil de configurar y se ejecutará fácilmente en una máquina virtual.

En parte de un antiguo puesto mío:

Lo usamos para

• Implementar servicios de Windows
• Implementar servicios web
• Ejecutar MSTests & amp; muestra tanta información como cualquier prueba de junit
• Mantenga un registro de las tareas bajas, med, altas
• advertencias y errores del gráfico de tendencia

Aquí hay algunas de las cosas incorporadas en .net que Hudson admite

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

Además, Dios no permita que uses una fuente visual segura, que admite eso también . Le recomiendo que eche un vistazo a Redsolo's artículo 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 a un trabajo cron para ejecutar scripts automatizados?

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

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

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

  • lista de todas las confirmaciones desde la última compilación activa
  • enviar notas de esos compromisos
  • lista de archivos modificados en las confirmaciones
  • salida de la consola desde la compilación en sí, mostrando el error o el error de la prueba

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

  A: una máquina virtual será suficiente

• P: Una vez que se ha terminado y probado una compilación, ¿es una práctica común colocar esa acumulació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 vayamos a ella, pero podemos hacer compilaciones de depuración si es necesario.

  A: Hudson puede hacer lo que quieras con eso, que incluye ID'ing a través del hash md5, cargarlo, copiarlo, archivarlo, etc. Lo hace automáticamente y te proporciona con un largo historial de artefactos de compilación.

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

  A: Tenemos nuestra encuesta SVN cada hora, buscando cambios en el código y luego ejecutando una compilación. Todas las noches están bien, pero IMO un tanto inútil, ya que en lo que has trabajado ayer no estarás fresco en tu mente por la mañana cuando entres.

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

  A: 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 están almacenados en archivos de texto / archivos xml los conservo, 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 mantenga los artefactos de un número de compilaciones final

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

  A: No, ve por Hudson ahora mismo, ¡no te decepcionarán!

Answer 2

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 soluciones. elimina la necesidad de los scripts msbuild)
2. NAnt (como la sintaxis XML / biblioteca de tareas mejor que MSBuild. También tiene opciones para las operaciones de control de P4 src )
3. CruiseControl.net : incorporado en el panel web para el monitoreo / inicio de construcciones.

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

Sobre la justificación: Esto quita la carga a los desarrolladores que realizan compilaciones manuales y hace mucho para eliminar los errores humanos 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 compilan el software a mano y sale a la luz, solo para que tu compilador diga "Oops, ¡debo haberme olvidado de incluir esa nueva DLL!" & Quot;

En hardware: tan potente como puedas conseguir. Más poder / memoria = tiempos de construcción más rápidos. Si puedes pagarlo, nunca te arrepentirás de tener una máquina de construcción de primera categoría, sin importar cuán pequeño sea el grupo.

En el espacio: ayuda a tener suficiente espacio en el disco duro. Puede crear sus scripts NAnt para eliminar archivos intermedios cada vez que se inicie una compilación, por lo que el problema real es mantener los historiales de registro y los instaladores de aplicaciones anteriores. Tenemos software que monitorea el espacio en el 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, genere esto en el proyecto desde el principio. Es extremadamente difícil realizar un ajuste posterior de las pruebas una vez que el proyecto crece. Hay mucha información sobre los marcos de prueba (probablemente también mucha información sobre SO), por lo que me refiero a nombrar cualquier herramienta específica.

Answer 3

En mi lugar de trabajo anterior usamos TeamCity . Es muy fácil y poderoso de usar. Se puede utilizar 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 estás en el código abierto, CC.NET es el gran padre con una curva de aprendizaje ligeramente más alta. Si tu presupuesto te permite ir definitivamente con TeamCity o echa un vistazo a la versión gratuita.

Answer 4

¿Cómo? Eche un vistazo a blog .

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

• Una compilación en funcionamiento, cuando se implementa correctamente, significa que todos los desarrolladores pueden construir en su máquina cuando la compilación es verde
• Una compilación en funcionamiento, cuando se implementa correctamente, significa que está listo para implementarse en cualquier momento
• Una compilación en funcionamiento, cuando se implementa correctamente, significa que todo lo que liberes ha hecho un viaje a tu sistema de control de fuente.
• Una compilación en funcionamiento, 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 en Integración continua sigue siendo el texto definitivo. Échale un vistazo!

Answer 5

El principal argumento a favor es que reducirá el costo de su proceso de desarrollo, alertándole tan pronto como sea posible que tiene una compilación rota o pruebas reprobadas.

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

Debes hacer que la máquina de compilación se reconstruya CADA vez que se realicen algunas comprobaciones durante el día. Con el control de crucero, puedes obtener un ícono en la barra de tareas que se vuelve rojo (¡e incluso te habla!) Cuando se rompe la compilación.

Luego, debe realizar una compilación completa por la noche 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 así, cuando se informa de un error, va en contra de un número de compilación conocido (eso es extremadamente importante).

Lo ideal es 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.

Answer 6

Solo estoy tratando de construir un poco sobre lo que dijo mjmarsh, ya que puso una gran base ...

• Visual Studio. MSBuild funciona bien.
• NAnt .
• NantContrib . Esto proporcionará tareas adicionales como las operaciones de Perforce.
• CruiseControl.net . De nuevo, esto es básicamente tu " compilación del panel " ;.

Todo lo anterior (guardar para 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 puede producir un entregable es útil para detectar cosas desde el principio.

NAnt también incluye tareas para nunit / nunit2 , para que pueda automatizar las pruebas de su unidad. Luego, puede aplicar hojas de estilo a los resultados y, con la ayuda del marco proporcionado por CruiseControl.net, obtenga buenos resultados de pruebas de unidades legibles e imprimibles para cada compilación.

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

Incluso puede utilizar la tarea exec para ejecutar otros comandos, por ejemplo, para producir un instalador de Windows utilizando InstallShield.

---

La idea es automatizar la construcción tanto como sea posible, porque los seres humanos cometen errores. El tiempo pasado al frente es el tiempo ahorrado en el camino. La gente no tiene que cuidar a la compilación pasando por el proceso de compilación. Identifique todos los pasos de su compilación, cree secuencias de comandos NAnt para cada tarea y compile las secuencias de comandos NAnt una por una hasta que haya automatizado por completo todo el proceso de construcción. También coloca todas las compilaciones en un solo lugar, lo que es bueno para fines de comparación. ¿Algo se rompió en el Build 426 que funcionó bien en el Build 380? Bueno, hay entregables listos para la prueba. Agárrelos y pruébelos.

Answer 7

• No se necesitan licencias. CruiseControl.net está disponible de forma gratuita y solo necesita el .NET sdk para construir.
• Un servidor de compilación, incluso sin pruebas unitarias automatizadas, todavía proporciona un entorno controlado para la creación de versiones. No más "John generalmente se basa en su máquina, pero está enfermo. Por alguna razón no puedo construir en mi máquina "
• Ahora mismo tengo una configuración en una sesión de Virtual PC.
• Sí. La construcción debe ser objeto de dumping en un lugar accesible. Las compilaciones de desarrollo deberían tener la depuración activada. La versión de lanzamiento debería estar desactivada.
• ¿Con qué frecuencia depende de usted. Si se configura correctamente, puede crear después de cada registro una sobrecarga muy pequeña. Esta es una gran idea si tiene (o planea tener) pruebas de unidad en su lugar.
• Mantener hitos y lanzamientos el tiempo que sea necesario. Cualquier otra cosa depende de la frecuencia con la que construyas: ¿continuamente? tirar a la basura. ¿Diario? Mantener el valor de una semana. ¿Semanal? Mantener el valor de dos meses.

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

Answer 8

Se trata de la salud de la construcción. Lo que esto le da es que puede configurar cualquier tipo de cosas que quiera que ocurran con las compilaciones. Entre estos puede ejecutar pruebas, análisis estático y perfilador. Los problemas se resuelven mucho más rápido, cuando recientemente trabajó en esa parte de la aplicación. Si realizas pequeños cambios, entonces casi te dirá dónde lo rompiste :)

Esto, por supuesto, supone que se configura para compilar con cada registro (integración continua).

También puede ayudar a que QA y Dev se acerquen. Como puede configurar pruebas funcionales para ejecutar con él, junto con el generador de perfiles y cualquier otra cosa que mejore la retroalimentación para el equipo de desarrollo. Esto no significa que las pruebas funcionales se ejecuten con cada registro (puede llevar un tiempo), sino que se configuran las 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.

Answer 9

Por qué: Hace 10 años, nosotros, como desarrolladores de software, solíamos analizar algo hasta el noveno grado para que los documentos (escritos en un lenguaje humano) se "firmaran" y luego comenzamos a escribir códigos. Haríamos la prueba de unidad, la prueba de cuerdas y luego haríamos la prueba del sistema: la primera vez que el sistema se ejecutaría en conjunto, a veces una semana o meses después de que se aprobaran los documentos. Solo en ese momento podríamos descubrir todas las suposiciones y malentendidos que teníamos cuando analizamos todo.

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

cómo: En cuanto al cómo, hice un blog acerca de esto hace poco: [ Haga clic aquí ]

En 8 publicaciones, va paso a paso sobre cómo configurar un servidor Jenkins en un entorno Windows para soluciones .NET.