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

Question

Veo esto una y otra vez. El gerente de pruebas de UAT quiere que la nueva versión esté lista para la prueba para el viernes. Una de las primeras preguntas, en la reunión de prueba previa, es "¿En qué versión voy a estar probando, en contra?" (que es una pregunta justa para hacer) La sala se queda en silencio, y luego alguien volverá con: "Todos los ensamblajes tienen su propia versión, simplemente haga clic con el botón derecho y observe las propiedades ...".

Desde el punto de vista de los gerentes de prueba, esto no sirve de nada. Ellos quieren un/etiqueta/etiqueta de versión a través de todo que les dice lo que están trabajando. Quieren esta información fácilmente disponible.

He visto soluciones donde la versión de diferentes áreas de un sistema se almacena en un almacén de datos, luego se muestra en la caja principal de la aplicación principal. El problema es que esto debe mantenerse.

¿Qué soluciones se han visto que evita este problema en ir?

EDITAR. El sistema distribuido cubre VB6, ASP clásico, VB.Net, C#, Servicios Web (al otro lado de los departamentos, por lo que la versión que estamos usando?), SQL Server 2005.

Answer 1

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

Lo que tienes que hacer en tales situaciones es asignar todos tus ensambles de componentes diferentes en una versión del sistema. Usted dice algo como "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.)". Demonios, en un sistema distribuido, es posible que desee versiones diferentes para cada uno de sus servicios, que en sí mismos pueden estar compuestos por diferentes versiones de .dlls. Podría decir, por ejemplo: "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 de barra v1.9, que se compone de Baz.dll v1.8.2 y Qux.dll v1.5.2 y (etc.) ".

Hacer cosas como esta suele ser el trabajo del arquitecto de software y/o el administrador de compilación en su organización.

Hay una serie de herramientas que puede utilizar para manejar este problema que no tienen nada que ver con el idioma de su elección. Mi favorito personal es actualmente Jira, que, además del seguimiento de errores, tiene un excelente control de versión de producto y roadmapping.

Answer 2

posible que desee echar un vistazo a this page que explica algunos aspectos para integrar versiones consistentes en su proceso de compilación.

Answer 3

No se usa la numeración de versión basada en compilación para nada que no sean referencias internas. Cuando el administrador de UAT hace la pregunta, dices "Friday's *".

El único truco consiste en asegurarse de que el etiquetado se realice de forma fiable en el control de origen.

* inserte apropiada marca de fecha/etiqueta aquí

Answer 4

Utilizamos .NET y la subversión. Todos nuestros montajes de aplicaciones comparten un número de versión, que se deriva de unas mayores y menores números de revisión actualizados a mano y el número de revisiones Subversion (<major>.<minor>.<revision>). Tenemos una tarea de preconstrucción que actualiza este número de versión en un archivo compartido AssemblyVersionInfo.vb. Luego, cuando los probadores soliciten el número de versión, podemos darles el número completo de 3 partes o simplemente la revisión de subversión. Las bibliotecas que consumimos no cambian o el cambio no es relevante para el probador.

Answer 5

Hay una serie de cosas diferentes que contribuyen al problema. Fuera de mi cabeza, aquí hay uno:

Uno de los beneficios de una arquitectura distribuida es que obtenemos 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, es posible que se publique una nueva versión de una aplicación comercial que utiliza el mismo servicio confiable antiguo que ha estado usando durante un año. ¿Cómo vamos a aplicar una sola etiqueta de lanzamiento en este caso?

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