Si tiene pruebas y fuente de control formal, el proceso se vuelve bastante sencillo. Comienza con una comprensión de quién puede cambiar los diferentes segmentos de números de la versión y cuándo. Los ensamblados .net tienen 4 segmentos de número (es decir, 1.0.0.1).
El primer segmento contiene el número de versión principal. Esto es establecido por la gerencia superior e indica un cambio importante en la interfaz de usuario o en la plataforma de la aplicación. Este siempre debe ser el mismo número entre la versión del ensamblaje y la versión del archivo.
El segundo segmento contiene el número de versión secundaria, también conocido como el número de función de salida. Esto es establecido por Project Management e indica que se han agregado nuevas características a la aplicación. Este siempre debe ser el mismo número entre la versión del ensamblaje y la versión del archivo.
El tercer segmento contiene el número de compilación. Esto lo establece el grupo de prueba e indica que la aplicación está lista para implementarse. Se cambia antes de que se publiquen las correcciones de errores. Al lanzar una nueva compilación, la prueba restablece el cuarto segmento a 0. Este puede ser el mismo número entre la versión de ensamblaje y la versión de archivo, pero generalmente se deja en 0 para la versión de ensamblado para simplificar el parcheo de las implementaciones existentes.
El cuarto segmento contiene el número de revisión. Esto establecido por el grupo de desarrollo cada vez que comprueban el nuevo código en el control de fuente. Este número se incluiría en la versión del archivo de la DLL compilada, pero no en la versión del ensamblado.
he encontrado que esto ayuda a los desplegados, los probadores y desarrolladores un seguimiento de las últimas versiones sin pisar los demás dedos de los pies. Desafortunadamente, también trabajé con compañías que usaban un sistema de control de versiones estático para que nadie supiera cuál era el mejor ensamblaje.
Para el despliegue, actualizamos los archivos AssemblyInfo y hacer una reconstrucción completa, pero que se está haciendo demasiado pesada, por lo que nos estamos moviendo a una acumulación gradual. El problema es determinar qué AssemblyInfo actualizar así que ahora no estamos actualizando la versión en los incrementales. – Mike
Por lo tanto, la posible solución actual que estoy buscando es actualizar la Versión de archivo de ensamblaje posterior a la compilación para que todos sepan qué compilación del código que está viendo. – Mike
¿Desea utilizar una compilación incremental para * deployment *? Yikes. ¿Cuánto tiempo tarda su construcción y con qué frecuencia se despliega? Personalmente, no me sentiría cómodo con eso, querría una versión completa (y prueba) limpia para la implementación. Mucho más fácil de reproducir de esa manera. –