java - subversion - svn tutorial

Alternativa a los binarios en Subversion (15)

Algunos de mis colegas están convencidos de que comprometer la construcción de artefactos para el repositorio de subversión es una buena idea. El argumento es que de esta manera, la instalación y actualización en las máquinas de prueba es fácil, ¡simplemente "svn up"!

Estoy seguro de que hay argumentos de peso contra esta mala práctica, pero todo lo que puedo pensar son tontos como "ocupa más espacio". ¿Cuáles son las mejores razones para no hacer esto? ¿Y qué otros enfoques deberíamos hacer en su lugar?

Esto es para código Java si eso hace la diferencia. Todo está compilado de Eclipse (sin compilaciones PDE automáticas).

Cuando digo agregar los artefactos de construcción, quiero decir que una confirmación se vería así:

"Added the new Whizbang feature" M src/foo/bar/Foo.java M bin/Foo.jar

Cada cambio de código tiene el archivo jar generado correspondiente.

Estoy seguro de que hay argumentos de peso contra esta mala práctica

Tiene una presunción equivocada de que cometer "artefactos de compilación" para el control de versiones es una mala idea (a menos que haya formulado su pregunta de forma incorrecta). No lo es.

Está bien, y es muy importante, mantener lo que llamas "artefactos de construcción" en el control de versiones. Más que eso, también debe mantener los compiladores y cualquier otra cosa utilizada para transformar el conjunto de archivos de origen en un producto final.

En cinco años a partir de ahora, seguramente utilizará diferentes compiladores y diferentes entornos de compilación, que pueden no ser capaces de compilar la versión actual de su proyecto, por la razón que sea. Lo que podría ser un pequeño cambio simple para corregir un error en una versión heredada, se transformará en una pesadilla de portar ese viejo software a compiladores actuales y herramientas de compilación, solo para recompilar un archivo fuente que tuvo un cambio de una línea.

Por lo tanto, no hay ninguna razón por la que tengas tanto miedo de almacenar "artefactos de compilación" en el control de versiones. Lo que puede querer hacer es mantenerlos en lugares separados.

Sugiero separarlos como:

Tienes que configurar tu IDE o tus scripts de compilación para colocar los archivos de objetos en / ProjectName / trunk / build / object (quizás incluso recreando la estructura de directorios en ... / source).

De esta forma, le da a sus usuarios la opción de finalizar / ProjectName / trunk para obtener el entorno de construcción completo, o / ProjectName / trunk / source para obtener el origen de la aplicación.

En ../build/bin y ../build/lib debe colocar los compiladores y las bibliotecas que se utilizaron para compilar el producto final, los que se utilizan para enviar el software al usuario. En 5 o 10 años, los tendrá allí, disponibles para su uso en alguna eventualidad.

"cometer artefactos de compilación en el repositorio de subversión" puede ser una buena idea si sabes por qué .

Es una buena idea para un propósito de administración de lanzamiento , más específicamente para:

1 / problema de embalaje

Si un artefacto de construcción no es solo un exe (o un dll o ...), sino también:

algunos archivos de configuración
algunos scripts para iniciar / detener / reiniciar su artefacto
algunos sql para actualizar su base de datos
algunas fuentes (comprimidas en un archivo) para facilitar la depuración
alguna documentación (javadoc comprimido en un archivo)

entonces es una buena idea tener un artefacto de construcción y todos los archivos asociados almacenados en un VCS.
(Porque ya no es solo una cuestión de "reconstruir" el artefacto, sino también de "recuperar" todos esos archivos extra que harán funcionar ese artefacto)

2 / Problema de implementación

Supongamos que necesita implementar muchos artefactos en diferentes entornos (prueba, homologación, preproducción, producción).
Si:

usted produce muchos artefactos de construcción
esos artefactos son bastante largos para recrear desde cero

luego tener esos artefactos en un VCS es una buena idea, para evitar volver a crearlos.
Puede consultarlos desde el entorno al entorno.

Pero debes recordar:

1 / no puede almacenar todos los artefactos que hace en el VCS: toda la compilación intermedia que realiza para fines de integración continua no debe almacenarse en el VCS (o termina con un enorme repositorio con muchas versiones inútiles de los binarios).
Solo las versiones necesarias para fines de homologación y producción deben ser referenciadas.
Para la compilación intermedia, necesita un repositorio externo (maven o un directorio compartido) para publicar / probar rápidamente esas compilaciones.
2 / no debe almacenarlos en el mismo Repositorio de Subversion, ya que su desarrollo está comprometido (número de revisión) con mucha más frecuencia que sus compilaciones significativas (las que se consideran dignas de homologación y despliegue de producción)
Eso significa que los artefactos almacenados en ese segundo repositorio deben tener una convención de nomenclatura para la etiqueta (o para una propiedad) a fin de recuperar fácilmente el número de revisión del desarrollo desde el que se han construido.

¿Quiere decir que tiene las fuentes más el resultado de la compilación en el mismo repositorio?

Este es un buen argumento para una compilación diaria, con scripts de compilación versionados en un repositorio separado. Binario en el repositorio en sí mismo no está mal, pero las fuentes + resultado de la construcción me parecen malas

Si construyes varios binarios y no notas una ruptura de compilación en algún lado, terminas con binarios de diferentes revisiones y te estás preparando para una sutil búsqueda de errores.

Abogar por una secuencia de comandos autobuild diaria, con versiones separadas, que solo contra los códigos binarios + código

Controlar binarios significativos viola un principio de uso del código fuente / SVN, a saber, que los archivos en el control fuente deben poseer una propiedad significativa de la diferencia .

El archivo fuente de hoy es significativamente diferente al archivo fuente de ayer; una diferencia producirá un conjunto de cambios que tienen sentido para un lector humano. La imagen de hoy del frente de la oficina no posee una diferencia significativa con respecto a la imagen de ayer de la oficina.

Debido a que las cosas como las imágenes no poseen el concepto de diferencia, ¿POR QUÉ las está almacenando en un sistema que existe para registrar y almacenar las diferencias entre los archivos?

El almacenamiento basado en revisiones se trata de almacenar historiales de cambios en los archivos. No existe un historial de cambios significativo en los datos de (por ejemplo) archivos JPEG. Dichos archivos también se almacenan perfectamente en un directorio.

Más prácticamente, almacenar archivos de gran tamaño (crear archivos de salida) en SVN hace que la verificación sea lenta. El potencial para abusar de SVN como un repositorio binario generalizado está ahí. Todo parece estar bien al principio, porque no hay muchos archivos binarios. Por supuesto, la cantidad de archivos aumenta a medida que pasa el tiempo; He visto módulos que tardan horas en verificarse.

Es mejor almacenar grandes archivos binarios asociados (y archivos de salida) en una estructura de directorio y hacer referencia a ellos desde el proceso de compilación.

Creo que la sensación de haber hecho algo malo cuando los archivos binarios se envían al VCS se basa en la idea básica de que uno nunca debe colocar cosas redundantes en un archivo, razonado por la economía de recursos y los inconvenientes de la administración de datos dobles.

Por eso: si puede reconstruir fácilmente su estado de trabajo archivado a partir de los otros archivos de esa determinada versión, como con la recompilación simple o la instalación de configuraciones estándar, no debe comprometer dichos binarios, sino que debe confirmar algo como un archivo README o INSTALL. Si las dificultades o el riesgo de no poder reconstruir son demasiado, comprométase.

El control de versiones debe tener todo lo que necesita hacer: svn co y luego compilar. No debería tener productos intermedios o finales, ya que eso frustra el propósito. Puede crear un nuevo proyecto en SVN para el resultado y versionar el resultado binario por separado (para versiones y parches si es necesario).

En mi experiencia, el almacenamiento de Jars en SVN termina en un lío.
Creo que es mejor guardar los Jar-Files en un Maven-Repository como Nexus .
Esto también tiene las ventajas de que puede usar una herramienta de gestión de dependencia como Maven o Ivy.

En mi opinión, el repositorio de código solo debe contener el código fuente y las bibliotecas de terceros necesarias para compilar este código fuente (también las bibliotecas de terceros pueden recuperarse con alguna herramienta de administración de la dependencia durante el proceso de compilación). Los archivos binarios resultantes no deben verificarse junto con el código fuente.

Creo que el problema en su caso es que no tiene los scripts de compilación adecuados en su lugar. Es por eso que construir un binario a partir de las fuentes implica algún trabajo como iniciar el eclipse, importar el proyecto, ajustar las paginas de clase, etc.

Si hay scripts de compilación en su lugar, obtener los binarios se puede hacer con un comando como:

svn update; ant dist

Creo que la razón más importante para no registrar los archivos binarios junto con la fuente es el tamaño resultante de su repositorio. Esto causará:

Repositorio más grande y quizás demasiado poco espacio en el servidor del sistema de versiones
Mucho tráfico entre el servidor del sistema de versiones y los clientes
Tiempos de actualización más largos (imagine que hace una actualización de SVN desde Internet ...)

Otra razón podría ser:

El código fuente es fácilmente comparable, por lo que muchas de las características de un sistema de control de versiones tienen sentido. Pero no puedes comparar binarios fácilmente ...

También su enfoque, como se describe arriba, introduce una gran cantidad de gastos generales en mi opinión. ¿Qué sucede si un desarrollador se olvida de actualizar un archivo jar correspondiente?

En mis proyectos, generalmente tengo ganchos de postconstrucción para construir a partir de una copia de trabajo especial en el servidor, concretamente en una ruta accesible desde un navegador HTTP. Eso significa que, después de cada commit, cualquiera [que pueda leer la web interna] puede descargar fácilmente los binarios relevantes. Sin problemas de consistencia, actualización instantánea + una ruta hacia pruebas automatizadas.

En primer lugar, Subversion (y todos los demás hoy en día) no son administradores de control de código fuente (siempre pensé que SCM significa Software Configuration Management), sino sistemas de control de versiones. Eso significa que almacenan los cambios en las cosas que almacena en ellos, no tiene que ser un código fuente, pueden ser archivos de imágenes, recursos de mapa de bits, archivos de configuración (texto o xml), todo tipo de cosas. Solo hay 1 razón por la que los archivos binarios compilados no se deben considerar como parte de esta lista, y eso se debe a que puede reconstruirlos.

Sin embargo, piense por qué le gustaría almacenar los binarios publicados allí también.

En primer lugar, es un sistema para ayudarlo, no para decirle cómo debe desarrollar sus aplicaciones. Haz que la computadora trabaje para ti, en lugar de contra ti. Entonces, ¿qué sucede si el almacenamiento de archivos binarios ocupa espacio? Usted tiene cientos de gigabytes de espacio en disco y redes súper rápidas. No es gran cosa almacenar objetos binarios allí (mientras que hace diez años podría haber sido un problema, esta es quizás la razón por la que la gente piensa en los binarios en SCM como una mala práctica).

En segundo lugar, como desarrollador, puede sentirse cómodo con el uso del sistema para reconstruir cualquier versión de una aplicación, pero los otros que podrían usarlo (por ejemplo, qa, prueba, soporte) podrían no hacerlo. Esto significa que necesitarías un sistema alternativo para almacenar los binarios, y realmente, ¡ya tienes un sistema así, es tu SCM! Haz uso de eso

En tercer lugar, supones que puedes reconstruir desde la fuente. Obviamente, almacena todo el código fuente allí, pero no almacena el compilador, las bibliotecas, los SDK y todos los demás bits dependientes que se requieren. ¿Qué sucede cuando alguien viene y pregunta "¿me puedes construir la versión que enviamos hace 2 años? Un cliente tiene un problema con esa versión". 2 años es una eternidad hoy en día, ¿tienes incluso el mismo compilador que usabas en ese momento? ¿Qué sucede cuando se comprueba todo el origen solo para descubrir que el sdk recientemente actualizado es incompatible con su fuente y falla con errores? ¿Limpia su caja de desarrollo y reinstala todas las dependencias solo para construir esta aplicación? ¿Puedes recordar cuáles eran todas las dependencias?

El último punto es el más importante, para ahorrar unos pocos k de espacio en disco, puede costar días si no semanas de dolor. (Y la ley de Sod también dice que cualquier aplicación que necesites reconstruir será la que requiera la dependencia más oscura y difícil de configurar de la que siempre hayas querido librarte)

Así que almacena los binarios en tu SCM, no te preocupes por las trivialidades.

PD. pegamos todos los binarios en su propio directorio ''release'' por proyecto, luego cuando queremos actualizar una máquina, usamos un proyecto especial ''setup'' que consiste en nada más que svn: externals. Exporta el proyecto de instalación y listo, ya que recupera las cosas correctas y las coloca en la estructura de directorios correcta.

Los binarios, especialmente los tuyos, pero también los de terceros, no tienen cabida en una herramienta de control de origen como SVN.

Idealmente, debería tener scripts de compilación para construir sus propios binarios (que luego se pueden automatizar con una de las muchas y finas herramientas automáticas de compilación que pueden verificar la fuente directamente desde SVN).

Para los binarios de terceros, necesitará una herramienta de administración de dependencias como Maven2. A continuación, puede configurar un repositorio Maven local para manejar todos los archivos binarios de terceros (o simplemente confiar en los públicos). El repositorio local también puede administrar sus propios binarios.

Poner los binarios en el tronco o las ramas es definitivamente excesivo. Además de ocupar espacio como usted menciona, también genera inconsistencias entre el código fuente y los binarios. Cuando se refiere a la revisión 1234, no desea preguntarse si eso significa "la compilación resultante de la fuente en la revisión 1234" frente a "los binarios en la revisión 1234". La misma regla de evitar inconsistencias se aplica al código autogenerado. No debe versionar lo que puede generar la compilación.

OTOH Estoy más o menos bien con poner binarios en las etiquetas . De esta manera, es fácil para otros proyectos utilizar los binarios de otros proyectos a través de svn: externals, sin necesidad de construir todas estas dependencias. También permite a los probadores cambiar fácilmente de etiquetas sin necesidad de un entorno de construcción completo.

Para obtener los binarios en las etiquetas, puede usar este procedimiento:

echa un vistazo a una copia de trabajo limpia
ejecutar el script de construcción y evaluar los resultados de las pruebas
si la construcción es correcta, svn add the binaries
en lugar de comprometerse con el tronco o la rama, marque directamente desde su copia de trabajo de la siguiente manera: svn copy myWorkingCopyFolder myTagURL
descartar la copia de trabajo para evitar confirmaciones accidentales de binarios en el tronco o rama

Tenemos un script tagbuild para semiautomatizar los pasos 3 y 4.

Un servidor de integración continua como Hudson tendría la capacidad de archivar artefactos de construcción. No ayuda a su argumento con "por qué no", pero al menos es una alternativa.

Una buena razón sería obtener rápidamente un ejecutable ejecutándose en una máquina nueva. En particular, si el entorno de construcción tarda un tiempo en configurarse. (Cargar compiladores, bibliotecas y herramientas de terceros, etc.)

Subversion es un Administrador de control de fuente -> Los binarios no son fuente
Si utiliza el comando "svn up" para actualizar la producción, ¿todos los desarrolladores con commit-permissions pueden actualizar / modificar / interrumpir la producción?

Alternativas: utilice la integración continua como Hudson o Cruise Control.