¿Cómo gestionar twigs de mantenimiento / corrección de errores en Subversion cuando se deben build proyectos de installation?

Tenemos un set de productos relacionados escritos en VB6, con algunos proyectos C # y VB.NET, y todo el origen se guarda en un único repository de Subversion.

No hemos estado utilizando las sucursales en Subversion (aunque ahora hacemos lanzamientos de tags), y simplemente hacemos todo el desarrollo en trunk, creando nuevas versiones cuando el trunk es lo suficientemente estable. Esto causa un gran dolor cuando lanzamos una nueva versión, se encuentran problemas con ella y ya hemos comenzado a trabajar en nuevas funciones o cambios importantes en el troncal. En el pasado, abordamos esto de una de dos maneras, dependiendo de la gravedad de los problemas y cuán estable creíamos que era el tronco:

  1. Date prisa para estabilizar el maletero, solucionar los problemas y luego lanzar una actualización de mantenimiento basada en la revisión HEAD, pero esto tuvo el efecto secundario de las versiones que corrigieron los errores pero introdujo nuevos problemas debido a funciones a medio terminar o correcciones de errores que estaban en el maletero .

  2. Haga que los clientes esperen hasta el próximo lanzamiento oficial, que generalmente es de unos pocos meses.

Queremos cambiar nuestras políticas para lidiar mejor con esta situación. Estaba considerando crear una "twig de mantenimiento" en Subversion cada vez que etiqueto un lanzamiento oficial. Luego, el nuevo desarrollo continuará en el enlace troncal, y puedo fusionar soluciones específicas periódicamente desde el enlace troncal en la twig de mantenimiento y crear una versión de mantenimiento cuando se acumulen suficientes soluciones, mientras seguimos trabajando en la próxima actualización principal en paralelo. Sé que también podríamos tener un troncal más estable y crear una twig para nuevas actualizaciones, pero mantener el desarrollo actual en el troncal me parece más simple.

El principal problema es que si bien podemos ramificar fácilmente el código fuente de una label de lanzamiento y volver a comstackrlo para get los binarys para esa versión, no estoy seguro de cómo manejar los proyectos de configuration e instalador. Usamos QSetup para crear todos nuestros progtwigs de installation, y ahora cuando tenemos que modificar un proyecto de configuration, simplemente editamos el file de proyecto in situ (todos los proyectos de configuration y cualquier dependencia que no compilemos nosotros mismos se almacenan en un server separado, y nos aseguramos de comstackr siempre los proyectos de configuration solo en esa máquina). Sin embargo, dado que podemos agregar o eliminar files a la configuration a medida que cambia nuestro código, no hay garantía de que los proyectos de configuration de hoy funcionen con el código fuente de ayer.

Iba a poner todos los proyectos de QSetup en Subversion para tratar con esto, pero veo algunos problemas con este enfoque.

Quiero que la creación de progtwigs de installation sea lo más automatizada posible y, como mínimo, quiero una máquina de creación separada en la que pueda crear la versión que quiero (primero cogiendo el código de Subversion), tomar el proyecto de configuration para ese Suelte de Subversion, recompile la configuration y luego copie la configuration en otro lugar de la networking para realizar testings de control de calidad y eventual lanzamiento a los clientes.

Sin embargo, cuando alguien necesita cambiar un proyecto de configuration (para agregar una nueva dependencia que ese tronco ahora requiere o para hacer otros cambios), hay un problema. Si lo tratan como un file fuente y lo comtestingn en su propia máquina para editarlo, no podrán agregar files al proyecto a less que primero copien los files que necesitan agregar a la máquina de creación (para que estén disponible para otros desarrolladores), luego copie todas las otras dependencies de la máquina de compilation a su máquina, asegurándose de que coincida exactamente con la estructura de la carpeta. El problema aquí es que QSetup usa routes absolutas para cualquier file agregado a un proyecto de installation. Sin embargo, esto significa instalar un set de dependencies de installation en las máquinas de desarrollo, lo que parece desorderado (y que podría desestabilizar el entorno de desarrollo si alguien ejecuta accidentalmente el proyecto de installation en su máquina).

Además, ¿cómo gestionamos las dependencies de terceros? Por ejemplo, si la twig de mantenimiento actual usó MSXML 3.0 y la troncal ahora requiere MSXML 4.0, no podemos volver atrás y crear una versión de mantenimiento si ya hemos reemplazado la biblioteca MSXML en la máquina de compilation con la última versión (suponiendo que ambas versiones tener el mismo nombre de file). La única solución que puedo pensar es poner todas las dependencies de terceros en Subversion junto con el código fuente, o para asegurarnos de poner diferentes versiones de biblioteca en carpetas separadas (es decir, C:\Setup\Dependencies\MSXML\v3.0 y C:\Setup\Dependencies\MSXML\v4.0 ). ¿Una de las forms es "mejor" o más común que la otra?

¿Existen mejores prácticas para enfrentar esta situación? Básicamente, si lanzamos v2.0 de nuestro software, queremos poder lanzar v2.0.1, v2.0.2 y v.2.0.3 mientras trabajamos en v2.1, pero todo el proyecto de configuration / installation y configuration El problema de la dependencia hace que esto sea más complicado que la típica respuesta "solo crea una twig en Subversion y recomstack según sea necesario".

A mi entender, la key es deshacerse de routes absolutas y ubicaciones de networking "conocidas". No los tengas. Nunca.

Donde trabajo, guardamos todos los files de configuration, proyectos, dependencies – TODO – en el mismo repository de código donde está el código principal. De esta manera, cuando creamos una twig, todo el material de configuration se ramifica junto con él, y se conserva en la misma forma que en el momento de la bifurcación.

El único problema que veo aquí es que, como mencionaste, QSetup usa routes absolutas. Aunque considero que esto es completamente ridículo, entiendo que probablemente no considerarás cambiar a algo más profesional (utilizamos NSIS, por cierto).

Sin embargo, me parece que se puede aplicar una solución relativamente simple. Supongo que aquí QSetup mantiene sus proyectos en algún tipo de formatting de text comprensible para los humanos (de lo contrario, es simplemente ridículo más allá de la comprensión). Como tal, puede crear una copy de su (s) file (s) de proyecto QSetup y replace todas sus routes por routes relativas, con algún tipo de marcador al comienzo, como %ROOT%\Dependencies\SomeDep.dll : %ROOT%\Dependencies\SomeDep.dll

Luego, puede hacer que su script de compilation ejecute una sencilla utilidad justo antes de llamar a QSetup, que creará el file de proyecto "real" reemplazando %ROOT% con la ruta apropiada, donde el repository pasa a estar desprotegido.

Después de implementar esto, puede crear una construcción en cualquier máquina, ya sea una máquina de construcción designada, una de desarrollo o alguna otra.