¿Qué artefactos guardar para una construcción nocturna?

StackOverflow https://stackoverflow.com/questions/230595

Pregunta

Supongamos que configuro un compilación nocturna automática . ¿Qué artefactos de la compilación debo guardar?

Por ejemplo:

  • código fuente de entrada
  • binarios de salida

Además, ¿cuánto tiempo debo guardarlos y dónde?

¿Cambian sus respuestas si hago Integración continua?

¿Fue útil?

Solución

Aquí hay algunos artefactos / información que estoy acostumbrado a mantener en cada compilación:

  • El nombre de la etiqueta de la instantánea que está generando (etiquete y haga un checkout limpio antes que cree)
  • Los scripts de compilación ellos mismos o su número de versión (si los trata como un proyecto separado con su propio control de versión)
  • La salida del script de compilación: registros y producto final
  • Una instantánea de su entorno:
    • versión del compilador
    • versión de la herramienta de compilación
    • bibliotecas y versiones dll / libs
    • versión de la base de datos (cliente y servidor)
    • versión ide
    • versión del intérprete de guiones
    • versión del sistema operativo
    • versión de control de origen (cliente y servidor)
    • las versiones de otras herramientas utilizadas en el proceso y todo lo que podría influye en el contenido de sus productos de compilación. Por lo general, hago esto con una secuencia de comandos que consulta toda esta información y la registra en un archivo de texto que se debe almacenar con los otros artefactos de compilación.

Hágase esta pregunta: " si algo destruye por completo mi entorno de compilación / desarrollo, ¿qué información necesitaría para crear una nueva para poder rehacer mi compilación # 6547 y terminar con el mismo resultado que obtuve la primera vez? ? "

Tu respuesta es lo que debes mantener en cada compilación y será un subconjunto o superconjunto de las cosas que ya mencioné.

Puede almacenar todo en su SCM (recomendaría un repositorio separado), pero en este caso su pregunta sobre cuánto tiempo debe mantener los elementos pierde sentido. O debe almacenarlo en carpetas comprimidas o grabar un CD / DVD con el resultado de la compilación y los artefactos. Lo que elija, tenga una copia de seguridad.

Debe almacenarlos siempre que los necesite. El tiempo dependerá del ritmo de su equipo de desarrollo y de su ciclo de lanzamiento.

Y no, no creo que cambie si haces una integración continua.

Otros consejos

No debes guardar nada por guardarlo. debe guardarlo porque lo necesita (es decir, el control de calidad usa compilaciones nocturnas para probar). En ese momento, "cuánto tiempo guardarlo" se convierte por mucho tiempo que QA los quiera.

no 'guardaría' código fuente tanto como etiquetarlo / etiquetarlo. No sé qué control de fuente está utilizando, pero el etiquetado es trivial (rendimiento y espacio en disco) para cualquier sistema de control de fuente de calidad. Una vez que se etiqueta su compilación, a menos que necesite binarios, realmente no hay ningún beneficio en tenerlos disponibles, ya que simplemente puede volver a compilar cuando sea necesario desde la fuente.

La mayoría de las herramientas de CI le permiten etiquetar en cada compilación exitosa. Esto puede volverse problemático para algunos sistemas, ya que fácilmente puede tener más de 100 etiquetas por día. Para tales casos, recomiendo seguir ejecutando una compilación nocturna y solo etiquetar eso.

Esta no es una respuesta directa a tu pregunta, pero no olvides controlar la versión de la configuración de compilación nocturna. Cuando la estructura del proyecto cambia, es posible que tenga que cambiar el proceso de compilación, lo que romperá las compilaciones más antiguas a partir de ese momento.

Además de los binarios como todos los demás han mencionado, recomendaría configurar un servidor de símbolos y un servidor de origen y asegurándote de que obtienes la información correcta en ellos. Ayudará en la depuración tremendamente.

Guardamos los archivos binarios, despojados y sin mostrar (por lo tanto, tenemos exactamente el mismo binario, una vez con y una vez sin símbolos de depuración). Además, compilamos todo dos veces, una vez con la salida de depuración habilitada y una vez sin (de nuevo, eliminados y no asignados, por lo que cada compilación da como resultado 4 binarios). La compilación se almacena en un directorio de acuerdo con el número de revisión SVN. De esa manera, siempre podemos conservar la fuente del repositorio de SVN simplemente revisando esta misma revisión (de esa manera la fuente también se archiva).

Una sorprendente que aprendí recientemente: si estás en un entorno que podría ser auditado, querrás guardar toda la salida de tu compilación, la salida del script, la salida del compilador, etc.

Esa es la única forma de verificar la configuración del compilador, los pasos de compilación, etc.

  

Además, ¿por cuánto tiempo guardarlos y dónde guardarlos?

Guárdelos hasta que sepa que la compilación no se lanzará a producción, siempre y cuando tenga los bits compilados.

Un lugar lógico para guardarlos es su sistema SCM. Otra opción es usar una herramienta que los guarde automáticamente, como AnthillPro y su tipo.

Estamos haciendo algo cercano a " incrustado " desarrollo aquí, y puedo decirte lo que ahorramos:

  • el número de revisión y la marca de tiempo de SVN, así como la máquina en la que se construyó y por quién (también grabado en los binarios de compilación)
  • un registro de compilación completo, que muestra si se trataba de una compilación completa / incremental, cualquier salida interesante (STDERR) de las herramientas de horneado de datos producidas, una lista de archivos compilados y cualquier advertencia del compilador (esto se comprime muy bien, siendo texto)
  • los binarios reales (para cualquier configuración de compilación de 1-8)
  • archivos producidos como un efecto secundario de la vinculación: un archivo de comando de vinculador, un mapa de direcciones y una especie de " manifiesto " archivo que indica lo que se grabó en los binarios finales (CRC y tamaño para cada uno), así como la base de datos de depuración (equivalente a .pdb)

También enviamos por correo el resultado de ejecutar algunas herramientas sobre el " efecto secundario " Archivos a usuarios interesados. En realidad no los archivamos, ya que podemos reproducirlos más adelante, pero estos informes incluyen:

  • tamaño total y delta del sistema de archivos, desglosado por tipo de archivo y / o directorio
  • tamaños de sección de código total y delta (.text, .data, .rodata, .bss, .sinit, etc.)

Cuando tenemos pruebas de unidad o pruebas funcionales (por ejemplo, pruebas de humo) en ejecución, esos resultados aparecen en el registro de compilación.

Aún no hemos descartado nada, dado que nuestras compilaciones de objetivos generalmente terminan en ~ 16 o 32 MiB por configuración, y son bastante compresibles.

Mantenemos copias sin comprimir de los binarios durante 1 semana para facilitar el acceso; después de eso solo conservamos la versión ligeramente comprimida. Aproximadamente una vez al mes tenemos un script que extrae cada .zip que produce el proceso de compilación y 7-zips un mes entero de resultados de compilación juntos (que aprovecha solo tener pequeñas diferencias por compilación).

Un día promedio puede tener una docena o dos compilaciones por proyecto ... El buildserver se activa cada 5 minutos para verificar las diferencias y compilaciones relevantes. Un .7z completo en un proyecto grande y muy activo durante un mes puede ser de 7-10GiB, pero sin duda es asequible.

En su mayor parte, hemos podido diagnosticar todo de esta manera. Ocasionalmente, hay un problema en el sistema de compilación y un archivo no es realmente la revisión que se supone que debe ser cuando se produce una compilación, pero generalmente hay suficiente evidencia de esto en los registros. A veces tenemos que desenterrar una herramienta que comprende el formato de la base de datos de depuración y alimentarla con algunas direcciones para diagnosticar un fallo (tenemos volcados de pila automáticos integrados en el producto). Pero generalmente toda la información necesaria está ahí.

Aún no hemos tenido que descifrar los archivos .7z, por mencionar. Pero tenemos la información allí, y tengo algunas ideas interesantes sobre cómo extraer fragmentos de datos útiles de ella.

Guarde lo que no se puede reproducir fácilmente. Trabajo en FPGA donde solo el equipo de FPGA tiene las herramientas y algunos núcleos (bibliotecas) del diseño tienen licencia para compilar en una sola máquina. Entonces guardamos los flujos de bits de salida. Pero intente verificarlos unos a otros en lugar de con un sello de fecha / hora / versión.

¿Guardar como en el check in al control del código fuente o simplemente en el disco? No guarde nada en el control del código fuente. Todos los archivos derivados deben estar visibles en el sistema de archivos y disponibles para los desarrolladores. No registre los binarios, el código generado a partir de archivos XML, los resúmenes de mensajes, etc. Un paso de empaquetado separado hará que estos productos finales estén disponibles. Como tiene el número de cambio, siempre puede reproducir la compilación si es necesario asumiendo que, por supuesto, todo lo que necesita para hacer una compilación está completamente en el árbol y está disponible para todas las compilaciones mediante la sincronización.

Guardaría tus binarios construidos exactamente en la medida en que tengan la oportunidad de entrar en producción o ser utilizados por algún otro equipo (como un grupo de control de calidad). Una vez que algo ha dejado de producir, lo que haces con él puede variar mucho. Para muchos equipos, mantendrán solo su versión anterior más reciente (para el retroceso) y, de lo contrario, descartarán sus versiones.

Otros tienen requisitos reglamentarios para mantener todo lo que entró en producción durante siete años (bancos). Si usted es una empresa de productos, mantendría el binario que un cliente podría haber instalado en caso de que un técnico de soporte quiera instalar la misma versión.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top