build-process - esquema - integracion continua devops

Integración continua frente a compilaciones nocturnas (8)

Depende del propósito y la duración de cada una de tus compilaciones. Básicamente, debe identificar lo que está tratando de aprender de CI y decidir si vale la pena gastar los recursos en ejecutar compilaciones múltiples.

Utilizamos integración continua en mi último trabajo para algunos propósitos diferentes.

Primero, lo usamos para asegurarnos de que el repositorio y, por lo tanto, los desarrolladores siempre tuvieran una versión del código compilado. Pocas cosas son peores para los miembros del equipo que tener que gestionar los cambios rotos de otra persona a través de comentarios, comentarios, reversiones y fusiones, porque una persona ingresó el código incorrecto. Para esto, teníamos una compilación que se ejecutaba instantáneamente sin pruebas u otra validación, por lo que sabíamos lo antes posible si el código era seguro para actualizar. Las construcciones generalmente duraban unos diez minutos y la máquina probablemente corría alrededor del 50% en un día normal de trabajo. Aquí no se generó ninguna documentación, solo un pase silencioso o una sirena de alto volumen.

En segundo lugar, queríamos saber lo antes posible si las reglas se han roto o no. Cuanto más rápido encuentre una regla rota, más fácil será arreglarla. Para este propósito, teníamos una máquina separada que ejecutaba una compilación completa y validación del código. Esta máquina funcionaba de 12 a 14 horas al día continuamente en un día normal de trabajo. El estado del correo electrónico de la construcción se envió describiendo pruebas de unidad rotas, cumplimiento de código, etc.

Nos detuvimos allí en lo que respecta a las compilaciones desencadenadas automáticamente. Una construcción nocturna encima de eso parecía un poco extrema para nosotros. Pero supongo que si quisieras tener una compilación de instantáneas archivada a diario, es posible que quieras programar una tercera compilación con los pasos adicionales necesarios para eso. Sin embargo, tuvimos otra compilación que envolvió y archivó nuestros artefactos de implementación de control de calidad para una implementación rápida y sencilla, pero solo hemos activado manualmente esa.

Leer esta publicación me ha dejado preguntándome; ¿Las compilaciones nocturnas son mejores para una situación que la integración continua? El consenso de las respuestas parece ser bastante desequilibrado a favor de la integración continua, ¿es ese evangelismo o no hay realmente ninguna razón para usar compilaciones nocturnas cuando la integración continua es una opción?

En mi opinión profesional, la única razón para usar compilaciones nocturnas es cuando el proceso de compilación lleva tanto tiempo que no puede completarse en un tiempo "razonable".

Por ejemplo, si su proceso de compilación tarda 5 horas en completarse, realmente no hay ninguna razón para hacer una compilación en el check-in.

Más allá de eso, hay tanto valor en saber tan pronto como sea posible cuando una construcción falla que anula otras preocupaciones.

En nuestra organización, las construcciones nocturnas y las compilaciones CI tienen dos propósitos distintos. La compilación de CI es una compilación de "último código" en la que las pruebas unitarias se ejecutan contra la última verificación como era de esperar. También ejecutamos varias métricas de código en la compilación CI.

Para construcciones nocturnas, sin embargo, solo incorporamos código fuente que ha pasado por el proceso de revisión por pares y se considera listo para la prueba.

De esta forma, la compilación nocturna siempre contiene compilación que está "lista para pruebas", mientras que la compilación CI contiene características que, aunque funcionales (en la medida en que pasen las pruebas unitarias) pueden no estar listas para enviarlas al grupo de prueba.

Los grupos de prueba escriben nuevas CR exclusivamente a partir de una de las compilaciones nocturnas en oposición a la compilación CI, aunque también están disponibles para pruebas de tipo exploratorio informales.

Sí, si tiene un proceso que desea adjuntar a una compilación, pero es un recurso pesado. Por ejemplo, en mi equipo ejecutamos JTest durante la construcción nocturna. No podemos ejecutarlo durante el día porque:

Requiere muchos recursos, que pueden no estar disponibles
Tarda 4 horas para completar cada vez

Si realmente está haciendo una integración continua con todas las pruebas disponibles, las compilaciones nocturnas serían redundantes, ya que lo último que se verificó en ese día ya habría sido probado.

Por otro lado, si su régimen de CI solo implica ejecutar un subconjunto de todas las pruebas disponibles, por ejemplo, debido a que algunas de sus pruebas tardan mucho tiempo en ejecutarse, puede usar las pesadillas también para ejecutar todas las pruebas. Esto te permitirá detectar muchos errores temprano, y si no puedes atraparlos temprano, al menos puedes atraparlos de la noche a la mañana.

No sé, sin embargo, si eso es técnicamente todavía CI, ya que solo estás haciendo una compilación "parcial" cada vez, ignorando algunas de las pruebas.

Si tiene un buen proceso sólido de CI en su lugar, un "nocturno" sigue siendo útil.

Como se mencionó, una compilación "nocturna" puede hacer pruebas exhaustivas y quizás algunas pruebas de sistema de alto nivel. Cosas de extremo a extremo.
El concepto de construcción "nocturna" es fácil de entender para todos en la organización. Si tiene problemas para comunicar las construcciones de CI a otros grupos (por ejemplo, un grupo de control de calidad que no tiene el mismo manejo en Agile que el grupo Dev), un "nocturno" es un concepto poderoso y simple.
Si su nightly es un conjunto separado de recursos, puede administrarse por separado y utilizarse para cortar imágenes "doradas" con algunas afirmaciones de integridad del software. Por ejemplo, el desarrollador escribe código, algún sistema de compilación confiable que dev no puede tocar lo construye, QA prueba la compilación de oro y la firma. En tal situación, la construcción nocturna funciona como un sistema de construcción de producción.

Solo algunos pensamientos.

Creo que las otras publicaciones cubren los motivos comunes, como tener un proceso de compilación que lleva "demasiado tiempo" o tener que ejecutar solo un subconjunto de pruebas durante la compilación de CI. Pero hay otra razón que es política.

En algunas organizaciones, las compilaciones oficiales son manejadas por un equipo de construcción / infraestructura / gestión de versiones / SCM mínimamente receptivo. En estos casos, puede ponerlos a cargo de la construcción nocturna y luego ejecutar la construcción de CI fuera del desarrollo. Esto evita una pelea porque su construcción sigue siendo "la versión oficial" y su compilación de CI le brinda la retroalimentación que necesita.

Tenemos integración continua y construcciones nocturnas en su lugar. Ellos sirven dos propósitos diferentes.

Nuestro mecanismo de integración continua crea el software y ejecuta pruebas unitarias bajo el paquete de integración continua.

Nuestra construcción nocturna etiqueta a la fuente bajo control de versión, crea el software, ejecuta las pruebas de la unidad bajo la suite de construcción nocturna. El software construido aquí se usa luego en varias pruebas de sistema y pruebas de estrés.

Creo que uno de los principales diferenciadores para la compilación nocturna son las pruebas del sistema.