En una arquitectura distribuida, ¿por qué es difícil administrar versiones?

Question

Veo esto una y otra vez. El administrador de pruebas de UAT quiere que la nueva compilación esté lista para probar antes del viernes. La primera de las preguntas formuladas, en la reunión previa a la prueba es, & Quot; ¿contra qué versión probaré? & Quot; (que es una pregunta justa para hacer). La sala queda en silencio, luego alguien volverá con & "; Todos los ensambles tienen su propia versión, simplemente haga clic derecho y mire las propiedades ... &" ;.

Desde el punto de vista de los administradores de pruebas, esto no sirve de nada. Quieren una versión / etiqueta / etiqueta en todo que les diga en qué están trabajando. Quieren esta información fácilmente disponible.

He visto soluciones en las que la versión de diferentes áreas de un sistema se almacena en un almacén de datos y luego se muestra en el cuadro Acerca de de la aplicación principal. El problema es que esto debe mantenerse.

¿Qué soluciones has visto que solucionan este problema actual?

EDITAR. El sistema distribuido cubre VB6, ASP clásico, VB.Net, C #, servicios web (entre departamentos, ¿qué versión estamos usando?), SQL Server 2005.

Answer 1

Creo que el problema es que usted y su gerente de pruebas están hablando de dos cosas diferentes. Las versiones de ensamblaje son excelentes para ensamblajes, pero su administrador de pruebas está hablando de una versión de nivel superior, una & "; Versión del sistema &"; Si lo desea. Al menos esa es mi lectura de tu publicación.

Lo que tiene que hacer en tales situaciones es asignar todos sus diferentes ensambles de componentes a una versión del sistema. Usted dice algo parecido a & Quot; La versión 1.5 del sistema está compuesta por Foo.Bar.dll v1.4.6 y Baz.Qux.dll v2.6.7 y (etc.) & Quot ;. Demonios, en un sistema distribuido, es posible que desee diferentes versiones para cada uno de sus servicios, que pueden estar compuestos de diferentes versiones de .dlls. Podría decir, por ejemplo: & Quot; La versión 1.5 del sistema está compuesta por el servicio Foo v1.3, que está compuesto por Foo.dll v1.9.3 y Bar.dll v1.6.9, y el servicio Bar v1 .9, que se compone de Baz.dll v1.8.2 y Qux.dll v1.5.2 y (etc.) & Quot ;.

Hacer cosas como esta es típicamente el trabajo del arquitecto de software y / o el administrador de compilación en su organización.

Hay varias herramientas que puede usar para manejar este problema que no tienen nada que ver con el idioma que elija. Mi favorito personal es actualmente Jira , que, además del seguimiento de errores, tiene una excelente versión del producto y soporte de hoja de ruta.

Answer 2

Puede que desee echar un vistazo a esta página que explica algunas formas para integrar versiones consistentes en su proceso de compilación.

Answer 3

Hay varias cosas diferentes que contribuyen al problema. Fuera de la parte superior de mi cabeza, aquí hay uno:

Una de las ventajas de una arquitectura distribuida es que ganamos un enorme potencial para la reutilización mediante la creación de servicios y la publicación de sus interfaces de una forma u otra. Lo que eso significa es que las versiones de una aplicación cliente no están necesariamente sincronizadas estrechamente con las versiones de los servicios subyacentes. Por lo tanto, se puede lanzar una nueva versión de una aplicación comercial que use el mismo servicio confiable que ha estado usando durante un año. ¿Cómo aplicaremos una sola etiqueta de lanzamiento en este caso?

Sin embargo, es una pregunta justa, pero que requiere una respuesta no trivial para ser significativa.

Answer 4

No utiliza la numeración de versiones basada en compilación para nada más que referencias internas. Cuando el administrador de UAT hace la pregunta, usted dice & Quot; Friday's * & Quot ;.

El único truco es asegurarse de que el etiquetado se realice de manera confiable en su control de origen.

* inserte la fecha / etiqueta apropiada aquí

Answer 5

Utilizamos .NET y Subversion. Todos nuestros conjuntos de aplicaciones comparten un número de versión, que se deriva de un número de revisión mayor y menor actualizado manualmente y el número de revisión de Subversion (<major>.<minor>.<revision>). Tenemos una tarea de precompilación que actualiza este número de versión en un archivo compartido AssemblyVersionInfo.vb. Luego, cuando los evaluadores soliciten el número de versión, podemos darles el número completo de 3 partes o solo la revisión de subversión. Las bibliotecas que consumimos no están cambiando o el cambio no es relevante para el probador.