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

Hemos tenido mucha suerte con el siguiente combo:

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

CCNet ha incorporado notificadores para enviar correos electrónicos cuando se construye con éxito/error

Sobre la justificación: Esto quita la carga a los desarrolladores que hacen 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á. Tener un proceso repetible para construir y lanzar software es primordial. Estoy seguro de que has estado en lugares donde construyen el software a mano y sale en la naturaleza, solo para que tu chico de construcción diga " Oops, debo haber olvidado incluir ¡ese nuevo DLL!"

En hardware: tan potente como puedas. Más potencia / memoria = tiempos de construcción más rápidos. Si puede permitírselo, nunca se arrepentirá de obtener 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 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 problema real es mantener los historiales de registro y los instaladores de aplicaciones antiguos. Tenemos software que monitorea el espacio en disco y envía alerta. Luego limpiamos la unidad 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, compile esto en el proyecto desde el primer momento. 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 por ahí (probablemente un montón de información sobre SO también), así que diferiré en nombrar cualquier herramienta específica.

En mi lugar de trabajo anterior usamos TeamCity. Es muy fácil y potente 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 teníamos un montón de pequeños proyectos y es bastante doloroso configurar cada uno en CC.NET. Recomiendo encarecidamente TeamCity. Para resumir si usted está hacia el código abierto entonces CC.NET es el abuelo con una curva de aprendizaje ligeramente superior. Si su presupuesto lo permite definitivamente vas con TeamCity o echa un vistazo a la versión gratuita.

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

¿Por qué? Hay varias razones que se me ocurren:

• Una compilación en funcionamiento, cuando se implementa correctamente, significa que todos sus 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 cualquier publicación ha hecho un viaje a su fuente sistema de control.
• Una compilación en funcionamiento, cuando se implementa correctamente, significa que se integra temprano y con frecuencia, lo que reduce el riesgo de integración.

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

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 fallidas.

El problema de integrar el trabajo de múltiples desarrolladores es el principal peligro de hacer crecer un equipo. Cuanto más grande es 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", comprobando en unidades pequeñas de trabajo (a veces llamado "historias") a medida que se completan.

Debe hacer que la máquina de compilación reconstruya CADA vez que se registre, a lo largo del día. Con el control de crucero, puede obtener un icono en su barra de tareas que se vuelve rojo (e incluso habla con usted!) cuando la estructura está rota.

Luego debe hacer una compilación completamente limpia cada noche donde la versión de origen está etiquetada (dado un número de compilación único) que puede elegir publicar a sus partes interesadas (gerentes de producto, personas de control de calidad). Esto es por lo que cuando se informa de un error, es contra 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 se pueda hacer clic para publicar la compilación nocturna anterior.

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

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

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

As Earwicker mencionado, construir temprano, construir a menudo. Saber que algo se rompió, y puede producir un entregable es útil para atrapar cosas desde el principio.

NAnt incluye tareas para nunit/nunit2 también, para que pueda automatizar sus pruebas unitarias. A continuación, puede aplicar hojas de estilo a los resultados, y con la ayuda del marco proporcionado por CruiseControl.net, tener buenos resultados de pruebas unitarias legibles e imprimibles para cada compilación.

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

Incluso puede usar la tarea exec para ejecutar otros comandos, por ejemplo, produciendo 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 invertido por adelantado es tiempo ahorrado en el camino. La gente no tiene que cuidar la construcción pasando por el proceso de construcción. Identificar todos los pasos de su compilación, cree scripts NAnt para cada tarea y construya sus scripts NAnt uno por uno hasta que haya automatizado completamente todo su proceso de compilación. También pone todas sus construcciones en un solo lugar, lo que es bueno para fines de comparación. ¿Se rompió algo en la construcción 426 que funcionó bien en la construcción 380? Bueno, hay los entregables listos para probar grab agárralos y prueba.

• No se necesitan licencias. CruiseControl.net está disponible gratuitamente y solo necesita el sdk. NET para compilarlo.
• Un servidor de compilación, incluso sin pruebas unitarias automatizadas, todavía proporciona un entorno controlado para la compilación de versiones. No más " John generalmente construye en su máquina, pero está enfermo. Por alguna razón no puedo construir en mi máquina"
• Ahora mismo tengo uno configurado en una sesión de PC Virtual.
• Sí. La construcción necesita ser desechada en algún lugar accesible. Las construcciones de desarrollo deberían tener la depuración activada. Release build debería tenerlo apagado.
• La frecuencia depende de usted. Si está configurado correctamente, puede construir después de cada check in muy poca sobrecarga. Esta es una gran idea si tiene (o planea tener) pruebas unitarias en su lugar.
• Mantenga hitos y lanzamientos el tiempo que sea necesario. Cualquier otra cosa depende de la frecuencia con la que construyas: ¿continuamente? desechar. ¿Todos los días? Mantén el valor de una semana. ¿Semanalmente? Mantenga el valor de dos meses.

Cuanto mayor sea tu proyecto obtiene 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 consigue 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 tratan mucho más rápido, cuando recientemente trabajó en esa parte de la aplicación. Si cometes pequeños cambios, entonces casi te dice dónde lo rompiste:)

Esto, por supuesto, supone que lo configures para construir con cada check in (continuo integración).

También puede ayudar a conseguir QA y Dev más cerca. Como puede configurar pruebas funcionales para que se ejecuten 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 (pueden tomar un tiempo), pero 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, como desarrolladores de software, solíamos analizar algo hasta el enésimo grado, obtener los documentos (escritos en un lenguaje humano) 'firmados' y luego comenzar a escribir código. Probamos la unidad, probamos la cadena y luego golpeamos la prueba del sistema: la primera vez que el sistema en su conjunto se ejecutaba juntos, a veces una semana o meses después de que obtuvimos los documentos firmados. Solo entonces descubriríamos todas las suposiciones y malentendidos que teníamos cuando analizábamos todo.

La integración continua como e idea hace que construya un sistema completo (aunque, inicialmente, muy simple) de extremo a extremo. Con el tiempo, la funcionalidad del sistema se construye ortogonalmente. Cada vez que usted hace una compilación completa usted está haciendo la prueba del sistema temprano y a menudo. Esto significa que encuentra y corrige errores y suposiciones tan pronto como sea posible, cuando es el momento más barato para solucionarlos.

Cómo: En cuanto al cómo, escribí sobre esto hace un rato: [Click Aquí]

Más de 8 mensajes va paso a paso sobre cómo configurar un servidor Jenkins en un entorno windows para soluciones.NET.