¿Pones compilaciones en un repositorio de código fuente?

Question

Me gustaría obtener algunos comentarios sobre esta idea, ya que puedo ver los pros y los contras de cada enfoque. Como desarrollador de Java, se trata de almacenar archivos jar en el depósito de código, pero podría extenderse fácilmente a otros lenguajes compilados.

Pros:

• puede recuperar fácilmente distribuciones previas, sin la necesidad de depender de (potientially ya no está disponible) de herramientas fecha recompilar.

Contras:

• Podría rápidamente "hincha" del repositorio de código, dependiendo de la frecuencia de las construcciones.

Answer 1

Archivamos versiones en una estructura de directorio y etiquetamos las versiones apropiadas en el control de código fuente. Esto nos da acceso a las versiones compiladas y la fuente que las generó.

Esto se hace fácilmente utilizando scripts de compilación para automatizar el etiquetado y el archivo de compilaciones de versiones.

Answer 2

Compromiso: almacene las herramientas y el código fuente en repositorios y compilaciones de etiquetas. De esta manera, siempre puedes volver a crear cualquier compilación de un producto.

Y siempre puede tener un repositorio separado para los artefactos compilados.

Answer 3

Poner versiones específicas de clientes en el repositorio.
En teoría, esto no es necesario, ya que siempre podemos reproducir esa versión, pero es bueno poder obtener el .msi exacto que se envió a un determinado cliente en una fecha determinada. Luego lo probamos en una versión limpia.

Una de las razones es que te protege contra cualquier cambio fuera de tu entorno de construcción como, por ejemplo, Windows o la actualización de Visual Studio. ¡Es posible que no puedas reproducir una compilación bit-bit de un msi si msi se ha actualizado!

Answer 4

Creo que es apropiado almacenar resultados de compilación en el sistema de control de versiones. Tanto para probar una versión específica de una compilación como para facilitar ciertas tareas de desarrollo.

Sin embargo, debe asegurarse de que también mantendrá todo lo que se necesitaría en el repositorio para recrear esa compilación exacta si fuera necesario. Debe usar etiquetado/etiquetado consitente para facilitar esto. Es posible que deba probar una corrección de errores con diferentes versiones de varios componentes, y dependiendo de la complejidad de su sistema en general, es posible que desee probar diferentes combinaciones.

Answer 5

Vamos a etiquetar el repositorio para cualquier compilación para que podamos obtener la fuente real de cualquier número de compilación &, luego zip y cargamos los archivos de compilación realmente publicados que están desplegados, solo para asegurarnos de que no haya ninguna configuración furtiva de último minuto ajustes durante el despliegue que no se reflejan en el tronco mismo.

Answer 6

Si puede crear un sistema de compilación lo suficientemente bueno como para que sea trivial recrear una compilación exacta simplemente con la extracción del código, no creo que haya ninguna necesidad de almacenar sus compilaciones en el repositorio.

Para la mayoría de mis cosas, no almaceno compilaciones específicas de mi código, pero sí almaceno versiones específicas de las bibliotecas en las que mi código se basa.Puse mucho esfuerzo hace unos meses para que sea trivial cargar una etiqueta y escribir "hormiga" y todo se desarrolla correctamente sin depender de nada fuera del árbol. (excluyendo el javac y la hormiga correctos)

Desafortunadamente, parte de nuestra base de código no tiene un sistema de compilación tan bueno (es decir, requiere la instalación manual de SDK y tomar varias librerías externas y variables de entorno) y sería difícil para recrear exactamente una versión específica de una compilación basada en el repositorio (estamos avanzando constantemente y no estamos realmente apoyando el código antiguo, por lo que la estación de trabajo de los desarrolladores está lo suficientemente cerca como para que aún no se haya quemado al tener que volver a una antigua rama antes de nuestra versión actual) y en ese caso, almacenamos nuestras compilaciones de lanzamiento (para el dedo gordo inevitable "oh no, estaba en el servidor equivocado haciendo algunas pruebas" o algo igualmente insidioso).

Answer 7

A veces. La mayoría de las veces la respuesta es no pero aún hay escenarios en los que, si tiene sentido, hazlo.

Como nota aparte, me sorprende que todavía esté abierto. Estas preguntas tipo discusión generalmente se votan cerradas en menos de 5 minutos.

Answer 8

No creo que haya una buena razón para versionar la compilación real. Etiquete la versión de origen y haga que solo un grupo controlado tenga acceso para cambiar las etiquetas. Una etiqueta de compilación nunca debe tener un checkin hecho por lo que debe ser trivial para recrear la compilación.

Answer 9

Guardo las construcciones en una carpeta en el servidor, y están respaldadas regularmente. Pero etiqueto la revisión que representa esa compilación. En la carpeta de compilación, almaceno no solo los ejecutables, binarios o páginas (nuestro caso es ASP.Net), sino también los scripts de cambio que obtenemos de SQL Delta.

Las etiquetas se nombran con el mismo identificador que los campos, por lo que si tiene la compilación "System_2009-07-30-01", tendrá una etiqueta con ese nombre. Entonces, si necesita arreglar algo, simplemente mire el nombre de la construcción, mire la etiqueta y luego mire la revisión que necesita para ver qué puede estar pasando.

Answer 10

Para mitigar la preocupación de que las herramientas de compilación antiguas no funcionen en un entorno más nuevo, archivamos nuestras imágenes de la máquina de compilación para las principales versiones. Es fácil de hacer para nosotros porque nuestras máquinas de construcción están virtualizadas. Es el plan B en caso de que otros medios no funcionen.

Answer 11

Creo fuentes, dependencias, binarios y construir herramientas deben ser versionados juntos ... Esta es la única manera de realizar un seguimiento de lo que está pasando con los grandes proyectos en los que la liberación final proviene de muchos proyectos de código ...