El control de versiones es algo que me apasiona mucho y he pasado mucho tiempo tratando de encontrar un sistema de control de versiones fácil de usar. Por lo que ya ha dicho en su pregunta, está claro que ha entendido un punto importante, los números de versión de ensamblaje no son sinónimos de la versión del producto. Uno está impulsado técnicamente y el otro está impulsado por el negocio.
Lo siguiente asume que usa alguna forma de control de origen y un servidor de compilación. Para el contexto utilizamos TeamCity y Subversion / Git. TeamCity es gratuito para un pequeño (10) número de proyectos y es un servidor de compilación muy bueno, pero hay otros, algunos de los cuales son completamente gratuitos.
Qué significa un número de versión
Lo que una versión significa para una persona puede significar algo diferente para otra, la estructura general es mayor, menor, macro, micro. La forma en que veo un número de versión es dividirlo en dos partes. La primera mitad describe la versión principal (Mayor) y cualquier actualización clave (Menor). La segunda mitad indica cuándo se creó y cuál era la versión del código fuente. Los números de versión también significan cosas diferentes según el contexto, es una API, aplicación web, etc.
Major
. Minor
. Build
.Revision
Revision
Este es el número tomado del control de origen para identificar lo que realmente se construyó.
Build
Este es un número cada vez mayor que se puede utilizar para encontrar una compilación particular en el servidor de compilación. Es un número importante porque el servidor de compilación puede haber construido la misma fuente dos veces con un conjunto diferente de parámetros. El uso del número de compilación junto con el número de origen le permite identificar qué se compiló y cómo.
Minor
Esto solo debería cambiar cuando haya un cambio significativo en la interfaz pública. Por ejemplo, si es una API, ¿el código consumidor aún podría compilarse? Este número debe restablecerse a cero cuando cambia el número mayor.
Major
indica en qué versión del producto estás. Por ejemplo, el mayor de todos los ensamblados de VisualStudio 2008 es 9 y VisualStudio 2010 es 10.
La excepción a la regla.
Siempre hay excepciones a la regla y tendrá que adaptarse a medida que las encuentre. Mi enfoque original se basaba en el uso de la subversión, pero recientemente me mudé a Git. El control de fuente como Subversion y Source Safe que usan un repositorio central tienen un número que puede usarse para identificar un conjunto particular de fuentes de un momento dado. Este no es el caso para un control de fuente distribuida como Git. Debido a que Git usa repositorios distribuidos que se encuentran en cada máquina de desarrollo, no hay un número de incremento automático que pueda usar, hay un truco que usa el número de registros pero es feo. Debido a esto, he tenido que evolucionar mi enfoque.
Major
. Minor
. Macro
.Build
El número de revisión ahora se ha ido, la compilación ha cambiado a donde solía estar la revisión y se ha insertado Macro. Puede usar la macro como mejor le parezca, pero la mayoría de las veces lo dejo solo. Debido a que usamos TeamCity, la información perdida del número de revisión se puede encontrar en la compilación, significa que hay un proceso de dos pasos, pero no hemos perdido nada y es un compromiso aceptable.
Qué configurar
Lo primero que hay que entender es que la versión de ensamblaje, la versión del archivo y la versión del producto no tienen que coincidir. No estoy abogando por tener diferentes conjuntos de números, pero hace la vida mucho más fácil al hacer pequeños cambios en un ensamblaje que no afecta a ninguna interfaz pública que no se ve obligado a recompilar ensamblados dependientes. La forma en que trato con esto es establecer solo los números mayores y menores en la versión de ensamblaje, pero establecer todos los valores en la versión del archivo. Por ejemplo:
- 1.2.0.0 (versión de ensamblaje)
- 1.2.3.4 (FileVersion)
Esto le brinda la capacidad de implementar correcciones urgentes que no romperán el código existente porque las versiones del ensamblaje no coinciden, pero le permiten ver la revisión / compilación de un ensamblaje mirando su número de versión del archivo. Este es un enfoque común y puede verse en algunos ensambles de código abierto cuando mira los detalles del ensamblaje.
Usted, como líder del equipo, deberá ser responsable de incrementar el número menor cuando se requiera un cambio importante. Una solución para implementar un cambio requerido en una interfaz pero no romper el código anterior es marcar el actual como obsoleto y crear una nueva interfaz. Significa que el código existente advierte que el método es obsoleto y podría eliminarse en cualquier momento, pero no requiere que rompa todo de inmediato. Luego puede eliminar el método obsoleto cuando todo se haya migrado.
Cómo conectarlo
Podrías hacer todo lo anterior manualmente, pero llevaría mucho tiempo, lo siguiente es cómo automatizamos el proceso. Cada paso es ejecutable.
- Elimine los atributos
AssemblyVersion
y AssemblyFileVersion
de todos los archivos AssemblyInfo.cs del proyecto.
- Cree un archivo de información de ensamblaje común (llámelo VersionInfo.cs) y agréguelo como elemento vinculado a todos sus proyectos.
- Agregar
AssemblyVersion
y AssemblyFileVersion
atributos a la versión con valores de "0.0.0.0".
- Cree un proyecto MsBuild que construya su archivo de solución.
- Agregue una tarea antes de la compilación que actualice VersionInfo.cs. Hay varias bibliotecas de código abierto MsBuild que incluyen una tarea AssemblyInfo que puede establecer el número de versión. Simplemente configúrelo en un número arbitrario y pruebe.
- Agregue un grupo de propiedades que contenga una propiedad para cada uno de los segmentos del número de compilación. Aquí es donde configuras el mayor y el menor. El número de compilación y revisión debe pasarse como argumentos.
Con subversión:
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
Espero haber sido claro pero hay mucho involucrado. Por favor haga cualquier pregunta. Usaré cualquier comentario para armar una publicación de blog más concisa.