Obtención de MSDeploy en nuestro servidor de compilación/integración: ¿es necesaria una actualización de MSBuild?

Question

Tenemos lo que creo que es un proceso de compilación bastante estándar: 1. Desarrollador: código de entrada 2. compilación: Encuesta repo, ve el cambio y comienza la compilación que: 3. compilación: actualizaciones de repo, compila w/MSBuild, Ejecuta pruebas unitarias con nunidad, 4. Compilación: crea el paquete instalador

Nuestro equipo de seguridad nos permite extraer del servidor de compilación, pero no permite que el servidor de compilación lo presione. Así que generalmente ingresamos, d/l los instaladores, y los ejecutamos, lo que descarta los servicios de implementación ingeniosos, por lo que tendría que generar paquetes en su lugar. Me gustaría utilizar MSDeploy, excepto que tenemos las siguientes cuestiones:

1. Estamos en .NET 3.5, y el objetivo de MSBuild (paquete) que utiliza MSDeploy requiere 4.0. ¿Hay algo que necesite instalar aparte de .net 4.0 RC para esto? (¿Sería MSBuild parte de esa actualización?)
2. Cuando genero paquetes con MSDeploy, veo que no tengo solo 1 archivo. Hay un zip, deploy.cmd, SourceManifest.xml y SetParameters.xml. ¿Para qué están todos los otros archivos y por qué no estarían todos en el 'paquete'?
3. Parece que puede crear paquetes al decirle al sistema que mire un sitio de IIS en funcionamiento. Pero si los paquetes están compilados a partir de un entorno de CI, ¿no tienes básicamente mala suerte aquí? Parece que diseñaron algo de esto para desarrolladores de pequeña escala que se implementan desde su entorno de desarrollo. Es un buen caso de uso, pero estoy interesado en ver cuál es la experiencia empresarial de todos con la herramienta

¿Alguna sugerencia?

Answer 1

Si no está utilizando Visual Studio 2010 para su aplicación, entonces yo sugeriría que elegir uno de los siguientes:

1. Uso msdeploy.exe
2. Instalar Visual Studio 2010 en el servidor de compilación y nos las tareas de MSDeploy en sí

Déjenme explicarlo un poco más.

Opción 1

MSDeploy en sí no tiene dependencia de MSBuild por lo que podría instalarlo por sí mismo en su servidor de compilación para crear los paquetes para usted. Puede descargarlo desde here. Después de eso, puede crear una secuencia de comandos de implementación de MSBuild utilizando la tarea Exec para llamar a msdeploy.exe con el comando para crear su paquete.

Sobre la segunda opción Archivos

Los .targets, así como las tareas para MSDeploy no se despliegan con el marco .NET, pero con Visual Studio 2010 en sí. Por lo tanto, si desea aprovechar cualquiera de ellos, deberá instalar VS 2010 en su servidor de compilación.

Usted mencionó usando el paquete target en su publicación. No podrá usar eso porque ese objetivo forma parte de un proceso de compilación más grande para proyectos .NET 4.Lo que podría hacer es crear un archivo separado de MSBuild (por separado como no en su archivo de proyecto) que usa MSBuild 4 para llamar a las tareas que se entregan con VS 2010 for Web Deployment.

Aquí responde a su lista numerada específicamente

1. Usted tendría que instalar Visual Studio 2010 ya que esas tareas se envían con VS en sí y no el marco.
2. Estos archivos se utilizan para interactuar con su paquete. Su paquete presenta su aplicación como un todo. Deploy.cmd invocará msdeploy.exe para realizar la implementación por usted. SourceManifest.xml y SetParameters.xml se utilizan para personalizar la implementación de su aplicación. deploy.cmd usará esos archivos cuando invoque msdeploy.exe. En otras palabras, si desea personalizar la ruta de acceso a la ubicación de la aplicación web, debe configurarla en SetParameters.xml junto con otras opciones.
3. Su derecho la configuración puede provenir de IIS, pero muchos desarrolladores prefieren usar el servidor de aplicaciones VS en lugar de IIS. Esa es mi preferencia. Lo que sugeriría en este caso es implementar su aplicación en un entorno que usará como plantilla. Realice todas las configuraciones de IIS que necesite, cree su paquete MSDeploy y luego tome el archivo archive.xml del paquete y úselo cuando cree su propio paquete. Otra opción es configurar un servidor IIS en el que se pueda implementar su proceso de compilación, luego usar MSDeploy para sincronizar los archivos que componen su aplicación y luego, una vez más, generar el paquete desde ese servidor IIS.