¿Cuál es la mejor manera de versionar un proyecto de múltiples componentes?

Tengo un programa que se compone de 5 componentes principales. La numeración de la versión estándar me parece demasiado limitante porque me gustaría ver en qué versión se encuentra cada componente.

¿Alguien ha encontrado una manera fácil de hacer esto aparte de enumerar cada uno por separado?

Tenemos exactamente el mismo problema con nuestro producto, y decidimos hacer números de versión individuales para cada componente y la versión del producto es solo una versión de marketing que se compone de varios componentes en una revisión específica.

Tenemos una "versión de lanzamiento del sistema", que es un número de versión estándar que describe una configuración particular de componentes, luego un archivo separado enumera las versiones de componentes individuales para ese lanzamiento en particular del sistema. Los clientes dicen 5.2.1 pero podemos buscar la compilación individual si es necesario. Por lo general, para una versión principal, sincronizamos todas las versiones individuales para que todo se construya a partir del mismo número de sucursal nuevamente.

El control de versiones es un problema que está separado del desarrollo de aplicaciones basadas en componentes. O quiere versionar cada componente, o quiere versionar toda la aplicación.

Un patrón bien conocido para el control de versiones es de Microsoft :

major version.minor version.build number.revision

Por ejemplo, puede ver los archivos DLL en la plataforma .NET para tener versiones como 2.0.3600.1, o algo así.

Por lo tanto, le recomiendo que primero determine si desea versionar todo el sistema o sus componentes. Si desea versionar todo el sistema, luego de cada integración, cree el proyecto completo y aumente la parte del número de compilación . Si no, simplemente versione cada componente en la compilación.

Tenga cuidado con las versiones, podría matarlo :-) No intente complicar demasiado las cosas.

Creo que el siguiente enfoque podría ayudarte:

Versión cada componente individualmente con el esquema de versiones que desee. Por sus comentarios, entiendo que tiene un VCS en su lugar. También supongo que cada componente tiene un archivo donde se guarda su versión (¿verdad?). Una vez por día / semana (lo que funcione mejor para su equipo) agregue una etiqueta a una de las revisiones más recientes en VCS que marque esa revisión como la última revisión oficial (y opcionalmente incremente un número de superrevisión). Ahora puede consultar el VCS para las revisiones con esa etiqueta y luego buscar la versión de los componentes en esa compilación oficial.

Si solo desea localmente, escriba un pequeño script que agregará la versión de cada componente desde el lugar donde está almacenado en el código.

Si desea hacerlo aún más elegante, una vez que realice el etiquetado, puede ver los archivos que pertenecen a cada componente, teniendo en cuenta que puede identificar los archivos que pertenecen a un componente específico. Si alguno cambió, incremente la versión para ese componente específico. La alternativa es hacer esto manualmente. Otra alternativa es una combinación de ramificación y fusión con el seguimiento de versiones.

La mayoría de los números de versión usan una revisión mayor y menor que es impulsada por el marketing, por lo que no puede usarlos para rastrear versiones de componentes individuales. En resumen, necesita encontrar alguna otra parte de la versión que pueda usar para rastrear versiones de componentes individuales, y reservar los números de versión mayor y menor para rastrear todo el paquete.

Si está siguiendo algo similar al patrón de Microsoft:

major-version.minor-version.build-number.revision

Puede usar .revision para rastrear la versión de cada componente individual, y usar los números de revisión menor y mayor para rastrear un cambio completo del producto, de la manera habitual.

Si sigue un patrón similar a este:

Major-Version.Minor-Version.Build-Number

Tendrá que usar el número de compilación para rastrear las versiones de componentes individuales.

Se escriben libros enteros sobre el software de versiones.

Aquí hay un enfoque que uso.

Cada parte tiene una versión en forma:

major.minor.developmental

Cada uno de estos es un número, comenzando en 0.

Para un lanzamiento formal (es decir, a clientes), la parte de desarrollo siempre debe ser 0 como una cuestión de política.

Major se incrementa por decisión de marketing.

Minor se incrementa con los conjuntos de características que se lanzan al mercado.

Ejemplo:

• Comienzo el desarrollo en un nuevo componente, por lo que mi número de versión será 0.0.1. Cuando libero mi escritorio para mis colegas, por ejemplo, para pruebas internas, el número de desarrollo sube a 0.0.2, 0.0.3, y así sucesivamente.

• Lancé esta nueva cosa al mercado como 1.0.0, donde el único cambio permitido desde el final del desarrollo hasta el lanzamiento fue cambiar el número de versión (por ejemplo, 0.0.43 -> 1.0.0).

• Se agregarán algunas características nuevas. Comienzo a trabajar en la línea de base 1.0.0, agregando estas características, por lo que las versiones que lanzo a mis colegas para probar son 1.0.1, 1.0.2, etc.

• Las siguientes características se lanzan al mercado como 1.1.0.

• El departamento de marketing decide que la próxima gran cosa será realmente grande, por lo que saldrá como 2.0.0. Comienzo a trabajar en 1.1.1, avanzo a través de 1.1.x, y lo lanzo como 2.0.0.

Y así el ciclo se repite.

Este enfoque, para cada componente, le brinda la trazabilidad de la ascendencia.

Para administrar el desarrollo, utilice el sistema de administración de revisiones de origen (y objeto), ramas y etiquetas (etiquetas, sea cual sea su terminología del día).

Su control de revisión puede administrar cada componente completamente por separado, con ramas de desarrollo y etiquetas / etiquetas para cada uno. O puede agruparlos todos juntos, en cuyo caso es posible que desee ramificar por paquete de trabajo, pero asegúrese de etiquetar / etiquetar liberando cada componente (y cuando lo haga, etiquete / etiquete todo, no solo los bits para el componente. De esta manera, tiene una instantánea del estado de todo en ese momento).

Es probable que su proceso de lanzamiento requiera una cuidadosa reflexión. El uso de este enfoque incluye algunos pasos manuales, y esto puede ser indeseable; todo esto depende de cómo su sistema de compilación ingrese los números de versión en el objeto final. Para muchos códigos incrustados donde los números de versión son solo números nombrados (por ejemplo, #definido en código C), tiene pocas opciones, pero de todos modos hacer esto manualmente. Las plataformas de escritorio con buenas GUI a menudo hacen que todo sea mucho más amigable.

Resumen

Para mí, la única forma confiable de versionar el software es usar el identificador hash o changeset de su sistema de control de versiones.

Un número de versión de compilación general puede ser útil, pero solo se garantiza que sea único si tiene un servidor de compilación y / o firma cada versión. Sin embargo, para muchos de nosotros, esto simplemente no es viable.

Si su proyecto se divide en múltiples repositorios de control de versiones, también necesitará crear un mecanismo mediante el cual su interfaz de usuario pueda consultar cada repositorio dependiente e informar de su hash al usuario.

Ejemplo de experiencia personal

En un proyecto de un empleador anterior, donde tuvimos problemas con nuestro cliente (interno) que modificaba el software y lo volvía a compilar, instituí un proceso mediante el cual los hashes mercuriales se compilaron en cada aplicación y biblioteca. Cada vez que se iniciaba el software, se creaba una cadena de revisiones consultando todos los componentes del software.

Esta cadena de revisión se mostró cuando fue a la página Acerca de y se escribió en el archivo de registro cada vez que se inició la aplicación. Era de la forma:

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

A partir de esto, pude ver fácilmente que habían modificado Library3 y no habían comprometido esos cambios en el repositorio, por lo que están usando código que no está controlado. También podría comparar los hashes con mi sistema de prueba actual, por lo que podría identificar que han revertido (por ejemplo) Library1 a una versión anterior.

Esto significaba que cada vez que informaban un error, siempre podía reconstruir exactamente el código en uso en el momento en que ocurría el problema, o al menos saber con certeza que no podía reproducir la configuración.

Para obtener más detalles sobre el sistema de compilación que utilicé, cómo logré esto, qué problemas tuve y qué sugirió la gente para evitarlos, eche un vistazo a mi pregunta de desbordamiento de pila .

Nota: Este sistema solo es realmente viable si usa un sistema de control de revisión en el que se garantiza que un hash dado dará como resultado el mismo conjunto de archivos en su directorio de trabajo (por ejemplo, git y mercurial) si un directorio de trabajo dado puede contener una mezcla de archivos y directorios de varias revisiones (por ejemplo, svn), todas las apuestas están desactivadas con respecto al estado del directorio de trabajo y este método no funcionará en absoluto.