nightly build - nightly - Builds nocturnas: ¿Por qué debería hacerlo?
neutral build (16)
¿Por qué debería hacer Builds nocturnas?
Debe hacer versiones nocturnas para asegurarse de que su código base se mantenga saludable.
Un efecto colateral de hacer compilaciones nocturnas es que obliga al equipo a crear y mantener un script de compilación totalmente automatizado. Esto ayuda a garantizar que su proceso de compilación esté documentado y sea repetible.
Las compilaciones automatizadas son buenas para encontrar los siguientes problemas:
- Alguien registró algo que rompe cosas.
- Alguien olvidó registrar un archivo necesario o cambiarlo.
- Sus scripts de compilación ya no funcionan.
- Tu máquina de construcción está rota.
Hacer esto cada noche asegura que atrape tales problemas dentro de las 24 horas de cuando ocurren. Es preferible a encontrar todos los problemas 24 horas antes de que deba entregar el software.
También debe, por supuesto, tener pruebas unitarias automatizadas que se ejecutan para cada construcción nocturna.
Creo que son muy importantes especialmente en proyectos con más de 1 persona. El equipo necesita saber lo antes posible si alguien:
- comprueba en un archivo malo
- no verifica en un archivo
- ...
Cualquier automatización de compilación es mejor que ninguna automatización de compilación :-)
Personalmente, prefiero compilaciones diarias, de esa manera si la compilación no funciona, todo el mundo está alrededor para solucionarlo.
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 cambio entre una compilación y facilita saber quién rompió la compilación y también es fácil para arreglar la construcción
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 en el artículo de Fowler y en la entrada de Wikipedia entre otros lugares.
En mi experiencia personal, es una cuestión de control de calidad: cada vez que se modifican los códigos (o las pruebas, que se pueden ver como una forma de requisitos), es posible que aparezcan errores. Para garantizar la calidad, debe realizar una compilación nueva del producto como se enviaría 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 a un grupo mayor de usuarios, una compilación nocturna permite a todos estar en la "última versión", minimizando el dolor de fusionar sus propias contribuciones en el código.
Desea hacer compilaciones 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 cada noche , en lugar de hacerlo semanalmente 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 pueda automatizar el proceso de compilación, más tiempo ahorrará para cada compilación posterior. También elimina el proceso de creación del camino crítico de la entrega del producto final, lo que debería hacer feliz a su gerente. :)
En realidad, no lo que debería querer 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 este artículo de Martin Fowler sobre Integración Continua .
Para resumir, quiere construir y probar tan pronto como sea posible para detectar los errores de inmediato para que puedan corregirse, mientras que lo que estaba tratando de lograr cuando los causó todavía está fresco en su mente.
Hay varias razones, algunas serán más aplicables que otras
- Si su proyecto está siendo trabajado por dos o más personas
- Es una buena forma de obtener la última versión de código en la que no estás trabajando
- Una compilación nocturna proporciona un corte en el tiempo del estado actual del código
- Una compilación nocturna le dará una compilación estable si necesita enviar código a las personas
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 u otro control de versiones). 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 crezca, y la necesidad de informes y documentación crezca, eventualmente las construcciones tomarán más tiempo para ejecutarse. En ese momento, dividiré las compilaciones en compilaciones continuas (ejecución 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 precisos para gestionar 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 compilación 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, aquí es por qué lo hago (y por qué tú también):
Supongamos 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 se infiltró un problema 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.
Las compilaciones nocturnas no siempre son necesarias; creo que solo son realmente útiles en grandes proyectos. 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 hacer más compilaciones regulares.
Las compilaciones nocturnas solo son necesarias para proyectos significativamente grandes (cuando se tarda demasiado tiempo en compilarlo 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 construir el proyecto solo para que sepas que todo sigue funcionando.
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.
Personalmente, he encontrado que la integración continua es mejor que las versiones nocturnas:
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.
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.
Dependiendo de la complejidad de su producto, la integración continua puede o no ser capaz de ejecutar un conjunto completo de pruebas.
Imagine que Cisco prueba 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.
Bueno ... supongo que depende mucho de tu 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 compilaciones 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. :)
Cuando vi esta pregunta, primero busqué la respuesta de Joel Spolsky . Un poco decepcionado, así que planeé agregarlo aquí.
Espero que todos estén al tanto de Joel Test on Careers .
De su blog en The Joel Test: 12 pasos para mejorar el código
3. ¿Hace construcciones diarias?
Cuando utilizas el control de código fuente, a veces un programador accidentalmente comprueba algo que rompe la compilación. Por ejemplo, agregaron un nuevo archivo fuente y todo compila bien en su máquina, pero olvidaron agregar el archivo fuente al depósito de código. Así que bloquean su máquina y se van a casa, ajenos y felices. Pero nadie más puede trabajar, así que también tienen que irse a casa, infelices.
Romper la construcción es tan malo (y tan común) que ayuda a hacer construcciones diarias, para asegurar que ninguna rotura pase desapercibida. En equipos grandes, una buena manera de asegurar que las roturas se solucionen de inmediato es hacer la construcción diaria todas las tardes, por ejemplo, a la hora del almuerzo. Todos hacen la mayor cantidad de registros posibles antes del almuerzo. Cuando vuelven, la construcción está hecha. Si funcionó, ¡genial! Todos revisan la última versión de la fuente y continúan trabajando. Si la compilación falla, la arreglas, pero todos pueden seguir trabajando con la versión ininterrumpida de la fuente.
En el equipo de Excel, teníamos la regla de que quien rompió la construcción, como su "castigo", fue responsable de cuidar a los niños hasta que alguien más lo rompió. Este fue un buen incentivo para no romper la construcción, y una buena manera de rotar a todos a través del proceso de construcción para que todos aprendieran cómo funcionaba.
Aunque no tengo la oportunidad de hacer compilaciones diarias, soy un gran admirador de eso.
¿Todavía no está convencido? Consulte el informe aquí en Daily Builds Are Your Friend !!