¿En qué punto debe cambiar para lanzar build?

Una de las prácticas establecidas en la Entrega continua de Jez Humble es que debe crear un paquete y luego lanzarlo a cada entorno en el que implemente, de modo que la implementación y los artefactos se hayan probado varias veces antes de pasar a producción.

Apoyo totalmente esta idea.

Por otro lado, las compilaciones en modo de depuración que le dan rastros de pila con números de línea son increíblemente útiles en entornos de prueba, como lo es la capacidad de depuración remota. Pero, desea enviar una versión de lanzamiento a producción.

Entonces, para las personas que siguen el primer principio, ¿en qué momento cambian de depuración a versiones de lanzamiento?

¿Es antes de la primera implementación en un entorno de prueba? ¿O construyes de nuevo en algún momento del proceso de promoción, pensando que confiarás en el proceso de compilación sobre el software? ¿O simplemente lo arruinas todo y despliegas versiones de depuración en producción?

Nota: Sé que esto realmente no se aplica a los idiomas interpretados porque generalmente puede mover el interruptor en la configuración en lugar de hacerlo en el momento de la compilación.

Entonces, para las personas que siguen el primer principio, ¿en qué momento cambian de depuración a versiones de lanzamiento?

Cambiamos temprano, cuando el código fuente obtuvo un número de versión y fue empujado a la cola de compilación de Debian. Sin embargo, estamos en la afortunada situación de hacer software científico con entradas y salidas bien especificadas y poca interacción del sistema, por lo que el costo de reproducir una situación de error es bastante bajo.

Esta es también mi respuesta general: el punto de cambiar las compilaciones depende principalmente de los costos de reproducción de los errores. Si estos son muy altos, incluso enviaría compilaciones de depuración para probar a los clientes. Si bien eso conlleva el riesgo de fallas de compilación para la compilación de producción, esto aún podría ser más barato que pasar semanas en la reproducción de casos de prueba.

Entonces, para las personas que siguen el primer principio, ¿en qué momento cambian de depuración a versiones de lanzamiento?

Tan pronto como pasamos al control de calidad, cambiamos a versiones de lanzamiento. Pero cuando creamos una versión de lanzamiento, nuestro proceso de compilación también construye una versión de depuración de los dlls. Esto nos permite colocar rápidamente los dlls de depuración en el entorno de control de calidad y obtener información adicional si es necesario.

Tanto la versión de lanzamiento como la de depuración de los dlls están respaldadas y conservadas durante varios años.

En nuestro entorno, el código se implementa en muchos sitios. Y, por lo tanto, debe haber un contexto diferente aplicado a cada instancia de implementación. Por lo general, lo implementamos en lugares clave "de menor riesgo" y vemos la experiencia.

Esta implementación todavía está en producción , por lo tanto, este no es el modo de 'depuración'. Pero también supone que las pruebas se hacen bien.

Por supuesto, con el modo de depuración desactivado, la depuración rápida del código (en el sitio) puede ser difícil. Pero si la versión ha fallado, la producción cambia de nuevo a versión alternativa.

Sin embargo, intentamos mantener o crear un entorno idéntico, que pueda reproducir dicho entorno para volver a probarlo. (Sé que esto no siempre es trivial), pero todo lo que necesitamos a veces es reproducir las transacciones / entradas.

El punto es, cuanto la tentación, el lanzamiento del modo de depuración no debería estar en producción. Sin embargo, no diré que esto es una regla.

Otra cosa es que el lanzamiento todavía se llama prueba hasta que haya establecido (al ejecutarse durante un tiempo considerable) otras premisas que aún no lo aceptan.

Hay otras pocas prácticas para garantizar que el proceso de compilación en sí no sea completamente defectuoso. Vea esto: una forma sencilla de mejorar la calidad de la versión en el entorno RAD

Tenemos nuestras máquinas de desarrollador configuradas para compilar versiones de depuración. Pero una vez que los desarrolladores confirman el código, se crea un paquete de implementación en nuestro entorno de integración continua (TeamCity) y se crea para su lanzamiento. Por lo tanto, cada vez que decidimos implementar en QA, tomamos el último paquete de implementación del servidor CI y lo enviamos, por lo que siempre se publica a menos que esté en una máquina de desarrollo.

Por cierto, para algunos idiomas, incluso cuando se compila para el lanzamiento, aún puede crear símbolos de depuración. En .NET, por ejemplo, hay una configuración "solo pdb" que permite optimizaciones pero aún crea archivos de depuración. Obviamente, la depuración en una versión de lanzamiento es más complicada ya que no es equivalente línea por línea, pero aún puede ser útil en caso de apuro.