TFS 2010 y "construir una vez, desplegar muchos"

Question

Hice un montón de investigación sobre este tema, pero no pude encontrar ninguna solución de extremo a extremo para poner en práctica la "construcción de una vez y desplegar muchos" usando TFS 2010.

Básicamente, lo que estoy pensando es tener una definición de construcción que construya una solución con múltiples proyectos para implementar (aplicación web + proyecto de base de datos + servicio web + informes), coloque la salida en la carpeta desplegable y desde allí en función de la calidad y la versión decidir manualmente implementar todos los proyectos en varios entornos (qa, ua, montaje, producción).

Sé que puedo modificar la plantilla de proceso de compilación para implementar varios proyectos inmediatamente después de la compilación, como "Build Main And Deploy to QA", "Build Main and Deploy to UA", etc. probablemente basado en changeset # o etiquetas, pero esto significa construir todo el tiempo. Lo que me gustaría es más como un tablero de mandos que permita al equipo de despliegue desplegar la construcción exacta que se probó en QA, en el entorno de UA y después de obtener la luz verde para desplegarlo en producción. Por supuesto, eso significa que los archivos de configuraciones se deben actualizar en consecuencia en el momento del despliegue.

También estoy considerando la definición de algunas definiciones de compilación que en realidad no generarán nada, sino que implementarán una compilación existente (basada en la versión) en un entorno específico, pero parece un poco extraño, por decir lo menos.

Answer 1

Eso es lo suficientemente cerca de lo que usamos, tenemos plantillas de compilación para realizar construcciones reales e implementar plantillas que despliegan la salida en varias máquinas (pueden configurarse para ejecutarse a horas programadas, como caídas nocturnas a QA, etc. bajo demanda como UAT/live). Las plantillas están muy modificadas de las predeterminadas, simplemente sondeamos los detalles de las compilaciones (o en algunos casos podría tomar las últimas compilaciones, como un entorno de prueba de humo), como las ubicaciones de colocación.

Necesitará un agente en la máquina que está implementando para que pueda manejar la implementación, pero puede instalar tantos agentes como desee.

Como ejemplo, podría tener una compilación que genere su aplicación en un exe y una plantilla que tome el exe y lo ejecute en su destino (utilizando InvokeProcess). Si necesita implementar lo mismo en otro entorno, simplemente use la misma ubicación de colocación, ¡viola!

Lo que tienes no suena extraño en absoluto, tiene sentido manejarlo de esa manera.

Answer 2

La respuesta de Daniel es más o menos la forma estándar de obtener un sistema de compilación como TeamBuild para manejar implementaciones. Se siente un poco raro porque estás doblando una herramienta para otro propósito. Sin embargo, definitivamente puede funcionar.

El otro enfoque es obtener una herramienta de implementación pura que se integre con TFS/TeamBuild. La implementación en todos los entornos sería natural, pero luego tiene dos herramientas para administrar.

Answer 3

Sé que esta es una respuesta tardía, pero las cosas han cambiado desde 2012. Microsoft tiene un Release Management offering ahora que está diseñado desde cero para permitir "construir una vez, implementar muchas". La modificación de las plantillas del proceso de compilación siempre es un problema.