Builds nocturnas: ¿Por qué debería hacerlo?

Question

¿Por qué debería hacer Nightly Builds?

Answer 1

Las compilaciones nocturnas no siempre son necesarias, creo que solo son realmente útiles en proyectos grandes. Pero si estás en un gran proyecto, una compilación nocturna es una buena forma de verificar que todo funcione, puedes ejecutar todas tus pruebas (pruebas unitarias, pruebas de integración), compilar todo tu código, en resumen, verificar que no haya nada roto en su proyecto.

Si tienes un proyecto más pequeño, tus tiempos de compilación y prueba serán más cortos, por lo que probablemente puedas permitirte hacer compilaciones más regulares.

Answer 2

Bueno ... Supongo que depende mucho de su proyecto, por supuesto. Si es solo su proyecto de pasatiempo, sin lanzamientos, sin dependencias, y nadie más que enviar código, podría ser excesivo.

Si, por otro lado, hay un equipo de desarrolladores que envían código, las versiones nocturnas automáticas lo ayudarán a garantizar la calidad del código en el repositorio. Si alguien hace algo que "rompe la construcción" para todos los demás, se notará rápidamente. Es posible romper la compilación sin darse cuenta, por ejemplo, olvidando agregar un nuevo archivo al repositorio, y las compilaciones nocturnas en una ubicación centralizada las detectarán con bastante rapidez.

Por supuesto, existen otros posibles beneficios, estoy seguro de que otros los suministrarán. :)

Answer 3

También depende del tamaño y la estructura de los equipos que trabajan en su proyecto. Si hay diferentes equipos que confían en las API de los demás, puede tener mucho sentido tener compilaciones nocturnas para una integración frecuente. Si estás pirateando con solo uno o dos compañeros de equipo, puede o no valer la pena.

Answer 4

Creo que son muy importantes especialmente en proyectos con más de 1 persona. El equipo necesita saber lo antes posible si alguien:

• cheques en un archivo malo
• no comprueba en un archivo
• ...

Answer 5

Debe hacer versiones compiladas para asegurar que tu código base se mantiene saludable.

Un efecto secundario de hacer las versiones compiladas es que obliga al equipo a crear y mantener un script de construcción totalmente automatizado. Esto ayuda a garantizar que su proceso de compilación esté documentado y sea repetible.

automatizado construye son buenos para encontrar los siguientes problemas:

• Alguien registró algo que rompe cosas.
• Alguien se olvidó de marcar un archivo necesario o cambiar.
• Sus scripts de compilación ya no funcionan.
• Su máquina de compilación está rota.

Hacer esto todas las noches le permite detectar estos problemas dentro de las 24 horas posteriores a su aparición. Es preferible a encontrar todos los problemas 24 horas antes de que deba entregar el software.

También debe, por supuesto, ha automatizado las pruebas unitarias que se ejecutan para cada nightly build.

Answer 6

Las compilaciones nocturnas solo son necesarias para proyectos significativamente grandes (cuando se tarda demasiado en construirlos a menudo durante el día). Si tiene un proyecto pequeño que no tarda mucho en compilarse, puede compilarlo a medida que obtiene piezas funcionales de código para que sepa que no ha estropeado nada en el proceso. Sin embargo, con proyectos más grandes esto no es posible por lo que es importante para construir el proyecto simplemente para que sepa que todo está en orden

Answer 7

trabajo que he encontrado personalmente integración continua a ser mejor que versiones compiladas:
http://en.wikipedia.org/wiki/Continuous_integration

Incluso lo uso en proyectos de un solo hombre, es increíble lo rápido que puede exponer problemas y cuidarlos allí mismo.

Answer 8

En realidad, lo que no le conviene es la integración continua y las pruebas automáticas (que es un paso más allá de las compilaciones nocturnas).

Si tiene alguna duda, debería leer this article by Martin Fowler about Continuous Integration.

Para resumir, usted quiere construir y probar lo más temprano posible para detectar errores de inmediato para que puedan repararse mientras que lo que estaba tratando de lograr cuando los causó aún está fresco en su mente.

Answer 9

De hecho, recomendaría hacer construcciones cada vez que ingrese. En otras palabras, recomendaría configurar un sistema de integración continua.

Las ventajas de tal sistema y otros detalles se pueden encontrar in Fowler's article y on the Wikipedia entry entre otros lugares.

En mi experiencia personal, es una cuestión de control de calidad: cada vez que se modifican los códigos (o pruebas, que se pueden ver como una forma de requisitos), es posible que aparezcan errores. Para garantizar la calidad, debe crear un construir el producto tal como sería enviado y realizar todas las pruebas disponibles. Cuanto más a menudo se hace esto, menos errores se permitirán para formar una colonia. Por lo tanto, se prefieren los ciclos diarios (nocturnos) o continuos.

Además, ya sea que restrinja el acceso de su proyecto a desarrolladores o un grupo mayor de usuarios, una compilación nocturna permite que todos estén en la "última versión", minimizando el dolor de fusionar sus propias contribuciones en el código.

Answer 10

automatización Cualquier construcción es mejor que no incluye la automatización de compilación :-)

Personalmente, prefiero versiones diarias - de esa manera si la acumulación no funciona, entonces todo el mundo está en torno a que te lo arreglen.

De hecho, si es posible, las compilaciones de Integración continua son el camino a seguir (es decir, una compilación en cada check-in) ya que eso minimiza la cantidad de cambios entre una compilación y facilita saber quién rompió la construir y también es fácil de arreglar la construcción.

Answer 11

Hay varias razones, algunas serán más aplicable que otros

• Si su proyecto está siendo trabajado por dos o más personas
• Es una buena manera de obtener la última versión del código que ha no están trabajando en
• un nightly build proporciona una rebanada en el tiempo de la situación actual del código
• un nightly build le dará una acumulación estable si necesita enviar código para las personas

Answer 12

Las compilaciones nocturnas son ideales para realizar análisis de código estático (consulte qalab y los proyectos de los que recoge estadísticas si se encuentra en el mundo java). Desafortunadamente, esto es algo que rara vez se hace.

Answer 13

Quiere hacer creaciones en un horario regular para detectar problemas con la integración de código entre desarrolladores. La razón por la que desea hacer esto todas las noches, a diferencia del programa semanal o en un horario más largo, es que cuanto más espere para descubrir este tipo de problemas, más difícil será resolverlos. La práctica de hacer una compilación en cada control (Integración Continua) es simplemente llevar el proceso de compilación nocturno a un extremo lógico.

El beneficio adicional de tener un proceso de compilación repetible también es importante a largo plazo. Si trabajas en un equipo donde hay varios proyectos en marcha, en algún momento necesitarás poder recrear fácilmente una versión anterior, quizás para crear un parche. :(

Cuanto más automatice el proceso de compilación, más tiempo ahorrará para cada construcción posterior. También elimina el proceso de creación de la ruta crítica de entrega del producto final, lo que debería hacer feliz a su gerente . :)

Answer 14

He estado haciendo ingeniería de construcción (entre otras cosas) durante 16 años. Creo firmemente en la construcción: temprana, construcción, a menudo, integración continua. Entonces, lo primero que hago con un proyecto es establecer cómo se construirá (Java: Ant o Maven; .NET: NAnt o MSBuild) y cómo se gestionará (Subversion o algún otro control de versión). Luego agregaré Integración continua (CruiseControl o CruiseControl.NET) dependiendo de la plataforma, luego dejaré que los demás desarrolladores pierdan.

A medida que el proyecto crece, y la necesidad de informes y documentación crece, con el tiempo las compilaciones tardarán más en ejecutarse. En ese momento, dividiré las compilaciones en compilaciones continuas (ejecutar al registrar) que solo compilan y ejecutan pruebas unitarias y compilaciones diarias que crean todo, ejecutan todos los informes y crean cualquier documentación generada. También puedo agregar una compilación de entrega que marque el repositorio y haga cualquier embalaje adicional para la entrega al cliente. Utilizaré objetivos de compilación detallados para administrar los detalles, de modo que cualquier desarrollador pueda construir cualquier parte del sistema: el servidor de integración continua usa exactamente los mismos pasos de desarrollo que cualquier desarrollador. Lo más importante es que nunca entregamos una compilación para pruebas o un cliente que no fue creado utilizando el servidor de compilación.

Eso es lo que hago - He aquí por qué lo hago (y por qué usted debe también):

Suponga que tiene una aplicación típica, con múltiples proyectos y varios desarrolladores. Si bien los desarrolladores pueden comenzar con un entorno de desarrollo común y consistente (el mismo sistema operativo, los mismos parches, las mismas herramientas y los mismos compiladores), con el transcurso del tiempo sus entornos divergirán. Algunos desarrolladores aplicarán religiosamente todos los parches de seguridad y actualizaciones, otros no.Algunos desarrolladores agregarán nuevas (tal vez mejores) herramientas, otros no. Algunos recordarán actualizar su espacio de trabajo completo antes de construir; otros solo actualizarán la parte del proyecto que están desarrollando. Algunos desarrolladores agregarán código fuente y archivos de datos al proyecto, pero se olvide de agregarlos al control de fuente. Otros escribirán pruebas unitarias que dependen de peculiaridades específicas de su entorno. Como consecuencia, verá rápidamente las siempre populares excusas "Bueno, construye/trabaja en mi máquina".

Al tener un servidor separado, estable, coherente, conocido y bueno para construir su aplicación, descubrirá fácilmente este tipo de problemas, y al ejecutar compilaciones a partir de cada confirmación, podrá identificar cuándo un problema se deslizó en el sistema. Aún más importante, debido a que usa un servidor separado para compilar y empaquetar su aplicación, siempre lo empaquetará todo de la misma manera, todo el tiempo. No hay nada peor que hacer que un desarrollador envíe una compilación personalizada a un cliente, hacer que funcione, y luego no tener idea de cómo reproducir las personalizaciones.

Answer 15

Dependiendo de la complejidad de su producto, la integración continua puede o no ser capaz de ejecutar un conjunto de pruebas completo.

Imagine Cisco probando un enrutador con literalmente miles de configuraciones diferentes para probar. Para ejecutar un conjunto de prueba completo en algunos productos lleva tiempo. Algunas veces semanas. Entonces necesitas construcciones para diferentes propósitos. Una construcción nocturna puede ser la base para un conjunto de pruebas más completo.

Answer 16

Cuando vi esta pregunta, primero busqué Joel Spolsky's respuesta. Un poco decepcionado, así que planeé agregarlo aquí.

Espero que todos estén al tanto de Joel Test on Careers.

Desde su blog el The Joel Test: 12 Steps to Better Code

3. ¿Haces versiones diarias?

Cuando utiliza el control de código fuente, a veces un programador accidentalmente comprueba algo que rompe la compilación. Por ejemplo, , han agregado un nuevo archivo de origen y todo se compila correctamente en su máquina , pero se olvidó de agregar el archivo de origen al repositorio de código . Entonces bloquean su máquina y se van a casa, inconscientes y contentos con . Pero nadie más puede trabajar, así que también tienen que irse a casa, infelices.

Romper la construcción es tan mala (y tan común) que ayuda a hacer construcciones diarias , para asegurar que ninguna rotura pase desapercibida. En equipos grandes , una buena forma de asegurar que las roturas se reparen de inmediato es para hacer la construcción diaria todas las tardes, por ejemplo, a la hora del almuerzo. Todos hacen tantos checkins como sea posible antes del almuerzo. Cuando vuelven, la construcción está lista. Si funcionó, ¡genial! Todo el mundo verifica la última versión de la fuente y continúa trabajando. Si la compilación falló, lo arreglas, pero todos pueden seguir trabajando con la versión intacta de la fuente preconstruida .

En el equipo de Excel que tenía una regla que quien rompió la construcción, ya que su "castigo", fue el responsable de las compilaciones de niñera hasta que alguien demás lo rompió. Este fue un buen incentivo para no romper la compilación, y una buena forma de rotar a todos a través del proceso de compilación para que todos supieran cómo funcionó.

Aunque no he tenido la oportunidad de hacer compilaciones diarias, soy un gran admirador de ello.

¿Aún no estás convencido? Consulte el informe aquí en Daily Builds Are Your Friend!!