msbuild - dotnet - Cree una vez e impleméntela en múltiples entornos con msdeploy y Visual Studio 2012
dotnet publish ubuntu (4)
Trabajando en la centralización de configuraciones, configuraciones de aplicaciones y cadenas de conexión, para múltiples soluciones, mientras que también cambias para usar msdeploy desde la línea de comandos para implementar aplicaciones web. Idealmente, me gustaría construir los paquetes una vez y obtener configuraciones actualizadas a medida que los paquetes se implementan en cada entorno. Necesito algunos consejos sobre el mejor enfoque para tomar.
- Utilice los archivos Parameters.xml y SetParameters.xml para cambiar de forma dinámica la configuración y las cadenas de conexión. Ver http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html
- Use machine.config o los archivos web.config de nivel de servidor para almacenar las configuraciones de aplicaciones comunes y las cadenas de conexión.
- Utilice el paquete PackageWeb NuGet desde https://github.com/sayedihashimi/package-web que permite el uso de las transformaciones web.config con msdeploy.
- Use los atributos file o configSource junto con SetParameters para apuntar a diferentes archivos de configuración, pero debe ser relativo desde la raíz web.
- Use publicar perfiles Consulte Implementación de un paquete existente utilizando los perfiles de publicación
Gracias
Puedo elaborar un poco sobre las opciones # 1 / # 3 y compararlas. La respuesta anterior no era precisa al afirmar que tienes que compilar varias veces con PackageWeb, solo necesitas compilar una vez.
Opción 1: Parameters.xml y SetParameters.xml
En este enfoque, creará un archivo parameters.xml en su proyecto web que declarará parámetros adicionales de Web Deploy.
Al compilar el paquete Web Deploy, los parámetros declarados en parameters.xml se crean en el paquete. Cuando se crea este paquete de despliegue web, el archivo web.config se transformará en función de la configuración de compilación (y ahora también de una transformación específica de perfil ).
Puede usar ese paquete y un setparameters.xml para publicar el paquete especificando los valores del parámetro Web Deploy. Puede crear diferentes archivos setparameters.xml y usarlos junto con el mismo paquete para publicar en múltiples destinos. Para publicar utilizando esta técnica, puede usar deploy.cmd, que VS genera, o llamar a msdeploy.exe con el conjunto correcto de parámetros.
Opción 3: PackageWeb
PackageWeb amplía el proceso del paquete de modo que cuando crea un paquete de Web Deploy, las transformaciones web.config se incluyen en el paquete, así como también un ensamblaje que puede ejecutar las transformaciones.
Además de esto, cuando crea un paquete de implementación web, se genera un archivo publish-interactive.ps1. Puede usar este archivo para publicar su paquete. Te lo pedirá; la transformación web.config se aplicará, la web implementará valores de parámetros y la web implementará la información del punto final. Cuando se ejecuta a través de una publicación, los valores que dio se guardan en publish-configuration.ps1.readme . Puede eliminar .readme y publish-interactive.ps1 usará los valores de ese archivo para automatizar la publicación. También puede especificar el archivo que se utilizará para la configuración .
Si creó un archivo parameters.xml cuando VS crea el paquete de implementación web, se implementarán parámetros en el paquete. PackageWeb los recogerá y le pedirá que los acepte también.
Entonces, ¿cuáles son las diferencias entre estos enfoques?
Con la Opción # 1, el web.config que entra al paquete ya está transformado. No tendrás la oportunidad de transformar el archivo nuevamente. Con ambos enfoques, puede especificar valores de parámetros de implementación web, de modo que se adapten a sus necesidades. Si está modificando grandes fragmentos de XML de un env al otro, las transformaciones web.config pueden ser beneficiosas. Entonces, PackageWeb puede ser una mejor opción.
Con la Opción # 1, debe crear manualmente el archivo SetParameters.xml. Con PackageWeb puede ejecutar el proceso utilizando la opción WhatIf. Se le solicitarán los valores y creará el archivo de configuración para usted.
Puede automatizar fácilmente ambos enfoques. PackageWeb esencialmente se basa en la técnica parameters.xml / setparameters.xml y ofrece un superconjunto de la funcionalidad.
Si desea mantener las cosas lo más simples posible con el menor número de partes móviles, recomendaría la opción n. ° 1, ya que puede llamar directamente a msdeploy.exe si es necesario.
Si desea simplificar la automatización de la publicación y prefiere PowerShell a un símbolo del sistema estándar, pruebe con PackageWeb.
Tengo un video de 5 minutos en PackageWeb en http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx . Si está publicando paquetes de implementación web, les recomiendo que lo prueben. Si no satisface sus necesidades, hágamelo saber porque podemos usar lo que aprendemos en PackageWeb más adelante de una manera más formal.
Terminé resolviendo este problema con una combinación de ejecución de msbuild en TeamCity para crear paquetes NuGet que pueden ser consumidos por OctopusDeploy .
Octopus permite que una aplicación empaquetada en un paquete nuget (construido una vez) se envíe a través de múltiples entornos. La configuración puede transformarse por entorno o incluso por máquina utilizando transformaciones ms estándar. Enlaces a documentos de Octopus relevantes a continuación.
Usamos # 5 y funciona muy bien. Usar MSBuild para publicar perfiles proporciona una gran cantidad de flexibilidad (los elementos son particularmente útiles).
En nuestra cartera de implementación, solo el paquete del sitio web, los objetivos de compilación / implementación y los perfiles de publicación están disponibles para las etapas de implementación. El código fuente, incluidos los archivos del proyecto, solo se utiliza en la etapa de compilación / prueba.
FYI, fuimos con los perfiles de publicación específicamente, ya que se encontrará rápidamente con el problema de mantener los detalles / credenciales del servidor específicos del entorno, las cláusulas de omisión y los valores de los parámetros. WPP / Publish Profiles realiza un seguimiento de todas estas cosas en el archivo pubxml , y las funciones de MSBuild permiten algunos buenos "ayudantes" de convención sobre configuración para tareas comunes pero "ruidosas".
Usamos la opción n. ° 1 y funciona bastante bien. Implementamos a aproximadamente 30-40 sitios y aplicaciones utilizando este enfoque.
Creo que la opción n. ° 2 generará dolores de cabeza tanto para usted como para los desarrolladores. Deberá asegurarse de que las secciones con configuraciones se eliminen de la configuración en la implementación, o bloquearlas en el servidor para que la configuración local no pueda agregarlas.
Para la opción n. ° 3, tendrás que hacer varias compilaciones para obtener los archivos de configuración transformados. Tampoco es muy factible si tiene una gran cantidad de sitios para implementar.
La opción n. ° 4 podría funcionar, pero podría encontrarse con limitaciones aquí. O bien toda la sección está en un archivo separado o está todo en el archivo principal, por lo que no hay intermedios.
La opción n. ° 5 parece interesante, pero no la he usado, así que no puedo decir mucho al respecto.