Uso de una plantilla de proceso de compilación TFS (flujo de trabajo) para la implementación

10

Estoy pensando en usar los flujos de trabajo de TFS Build para implementaciones complejas. Tenemos algunos que pueden necesitar implementarse:

  1. Aplicaciones y servicios web
  2. Base de datos
  3. Informes SSRS
  4. Paquetes SSIS
  5. Quien sabe que mas

Me gusta el hecho de que puedo darle al flujo de trabajo algunos parámetros básicos, como qué compilación implementar y simplemente se ejecutará. Potencialmente, algunas partes pueden necesitar aprobación humana, y sé que el flujo de trabajo también puede manejar eso. Un ejemplo es que podríamos usar el flujo de trabajo para crear un script de cambio a partir de nuestros proyectos de base de datos de Visual Studio, pero el grupo DBA querrá aprobar el script antes de que se ejecute.

Me interesa saber si otros han usado "compilaciones" para esto en el pasado y qué problemas se encontraron.

deployment builds workflows team-foundation-server John Saunders
fuente
Estamos utilizando TFS 2010 para administrar nuestras compilaciones / implementaciones. No tengo respuestas rápidas para ti; pero a medida que surjan problemas, no dude en enviarme un correo electrónico y al menos podemos tratar de resolverlo.
Stephen Gross

Respuestas:

1

Hemos usado TFS para activar nuestras compilaciones pero hemos usado msbuild para construir nuestros proyectos. La principal ventaja es que tenemos un script de compilación que podemos cambiar y mantener bajo control de versión. La cuestión es con los flujos de trabajo, por ejemplo: ¿cómo va a construir una versión anterior de su proyecto? Con un script de compilación, solo obtienes la versión anterior del control de origen y listo. También es bueno poder jugar con él y activar / desactivar diferentes opciones.

Si está seguro de que tiene un ciclo de construcción fijo, entonces probablemente pueda llevarlo a cabo, de lo contrario, tener un script es probablemente la opción más segura y más flexible.

Carlo Kuip
fuente
Los flujos de trabajo son archivos .xaml almacenados en el control de origen. Necesitaré un proceso que ramifique los archivos .xaml junto con el código fuente. Sin duda, ramifica tus archivos msbuild junto con la fuente.
John Saunders el
@ JohnSaunders sí, ramificamos nuestros scripts de compilación. Es genial que la configuración de su flujo de trabajo se almacene en un archivo xml, pero ¿qué influencia tiene el cambio de configuración en los elementos que están en una versión diferente de su flujo de trabajo (elementos de trabajo, tareas, etc. dentro de su proyecto también están dentro de ese mismo flujo de trabajo)? ) Ahí es donde veo un riesgo, cambiando el comportamiento de cómo TFS maneja su proyecto sobre la marcha.
Carlo Kuip
No se a que te refieres. Cambiar la plantilla del proceso de compilación no cambiará los elementos de trabajo. ¿Qué quiere decir "elementos que están en una versión diferente de su flujo de trabajo"?
John Saunders
La plantilla de proceso que aplica al crear un proyecto TFS es crear un flujo de trabajo. Eso significa que si crea un elemento de trabajo, está vinculado a las distintas etapas de ese flujo de trabajo. ¿Su proceso de compilación va a ser una extensión en ese flujo de trabajo o es separado?
Carlo Kuip
Lo sentimos, estás confundiendo una plantilla de proceso y una plantilla de proceso de compilación. Microsoft eligió mal sus términos. Además, la plantilla de proceso que usa al crear un proyecto de equipo sí crea cualquier flujo de trabajo que conozco.
John Saunders