Lanzamiento de compilación vs compilación nocturna

Una solución típica es tener una compilación CI (integración continua) ejecutándose en un servidor de compilación: analizará el código fuente, realizará compilaciones (en depuración) y ejecutará pruebas, medirá la cobertura de las pruebas, etc.

Ahora, otro tipo de compilación generalmente conocido es "Compilación nocturna": haga cosas lentas como crear documentos de código, cree un paquete de instalación, implemente para probar el entorno y ejecute pruebas automáticas (humo o aceptación) contra el entorno de prueba, etc.

Ahora, la pregunta:

• ¿Es mejor tener una tercera "Versión de lanzamiento" separada como versión de lanzamiento?
• ¿O "Nightly build" en modo de lanzamiento y lo usa como lanzamiento?

¿Qué estás usando en tu empresa?

(La versión de lanzamiento también debería agregar algún tipo de etiqueta al control de origen de la versión potencial del producto).

Un caso para que la versión de lanzamiento sea igual a la versión nocturna es: desea probar exactamente lo mismo que publica . No desea descubrir errores en la producción que ya podrían haberse detectado en las pruebas de desarrollo.

La diferencia entre versiones y versiones nocturnas:

• la compilación nocturna se ejecuta automáticamente, bueno, todas las noches, mientras que la compilación de lanzamiento debe ejecutarse manualmente en ciertos momentos
• La compilación de lanzamiento idealmente debería etiquetar / ramificar el código fuente, y posiblemente implementar los artefactos de compilación en un repositorio central (por ejemplo, cuando se usa Maven)

Estas diferencias son en la práctica algunas opciones adicionales en la mayoría de los sistemas de gestión de compilación que conozco. Para minimizar la posibilidad de errores humanos, estos podrían guardarse, por ejemplo, en un archivo por lotes / script que toma solo los parámetros necesarios (y los valida).

Bueno, ¡me gustaría que la versión de lanzamiento fuera lo más cercana posible al proceso nocturno! Idealmente exactamente lo mismo pero con una etiqueta.

La cuestión es que si su versión de lanzamiento y la noche no son las mismas, existe la posibilidad de que lo que sea diferente pueda enmascarar un problema (o hacer que rastrear uno sea mucho más difícil).

Tendría un solo proceso de compilación, que compilaría todo cada check-in ejecutado por el servicio de CI. Eso sería tanto una versión de depuración como una versión de lanzamiento.

Tener dos o tres procesos separados es solo pedirles que comiencen a cambiar aleatoriamente sin estar documentados, y no pasará mucho tiempo antes de que alguien tenga que hacer 15 pasos para cada lanzamiento potencial para prepararlo para salir por la puerta.

Una cosa que me gusta hacer es poner la compilación nocturna en modo de lanzamiento en lugar de modo de depuración. Con marcos de registro como log4net reemplazando System.Diagnostics.Debug, las principales diferencias entre los modos Release y Debug son las duraciones de los objetos y las optimizaciones de código.

A menos que realmente vaya a adjuntar un depurador a su compilación nocturna, le sugiero que haga esto también.

El proceso que seguimos es que la compilación nocturna se ejecuta todas las noches y, si eso funciona, podemos implementar la misma compilación en nuestros otros servidores (sin reconstrucción, solo tome los instaladores empaquetados y ejecútelos). Si tenemos un problema con la compilación nocturna, verificamos los cambios en ella en una rama y ejecutamos una compilación "nocturna" fuera de esa rama durante el día. Las pruebas se pueden volver a ejecutar.