enable - Publicación de un sitio ASP.NET MVC2 con Web Deploy

web deploy iis 7 (9)

¿Por qué no usar Dropbox? Seriamente....

ADVERTENCIA: ESTO NO HA SIDO PROBADO POR MI, SÓLO UNA RESPUESTA HIPOTÉTICA

Solución 1: de una manera no profesional, instalaría Dropbox en todos los servidores, incluido el servidor de pruebas. Y solo despliegue web desde Visual studio a la puesta en escena.

Dropbox sincroniza los archivos muy rápidamente, especialmente cuando habilitas la "Descarga de red", ¡donde los archivos se descargan desde servidores locales en lugar de Dropbox!

Solución 2: cree un paquete de implementación desde Visual Studio y guárdelo en una carpeta local que se sincronice con Dropbox. Luego, cree una tarea programada que ejecute deploy.cmd automáticamente y borre el contenido de la carpeta de implementación una vez que haya terminado para evitar que se vuelva a implementar una y otra vez.

Problemas con el uso de Dropbox

ACL no se sincronizará :(
La sesión de escritorio remoto siempre debe estar activa cuando Dropbox se ejecuta en la bandeja (no es un servicio)
Las carpetas no deben contener ningún archivo de "datos" que se modifique o se producirán conflictos

Actualmente utilizo Web Deploy, http://learn.iis.net/page.aspx/346/web-deploy/ para publicar mi aplicación MVC2. Solía funcionar bien, pero ahora ha llegado al punto en que no puedo seguir usándolo:

Cuando la aplicación MVC era pequeña y tenía pocos usuarios, era fácil de publicar. Simplemente haga clic derecho en el proyecto en Visual Studio y elija "Publicar". Y como solo había unos pocos usuarios, fue fácil encontrar un momento en el que nadie utilizara el sitio para realizar una actualización rápida.

Entonces la aplicación se hizo más grande y tuvo algunos usuarios más. La acción "Publicar" comenzó a tomar más y más tiempo y ocasionalmente se agotó el tiempo. Incluso cuando reciclé el grupo de aplicaciones antes de implementarlo, tomó mucho tiempo.

Además, se hizo más difícil encontrar un momento en el que nadie estuviera usando el sitio, por lo que la actualización podría realizarse sin afectar a nadie.

Luego, la acción "Publicar" comenzó a caducar cada vez, y tuve que cambiar a la implementación manual de acuerdo con esta pregunta anterior sin respuesta: Visual Studio 2010: la implementación web se agota. ¿Qué hacer?

Ahora el despliegue manual está tomando más y más tiempo, de 5 a 20 minutos. Y el número de usuarios ha aumentado significativamente, por lo que la implementación siempre afecta a alguien (tiempos de respuesta lentos, tiempos de espera, sitio no disponible, etc.)

¿Entonces Que puedo hacer? ¿Hay alguna alternativa mejor al uso de despliegue web?

Editar:

La implementación de hoy tomó 18 minutos para publicar solo 49 archivos modificados. La situación es simplemente ridícula y es una de las mayores debilidades de nuestro sitio en este momento. Así que estoy empezando una recompensa de tamaño decente con la esperanza de resolver esto.

Algunas preguntas más que pueden conducir a una solución:

¿Por qué tomaría tanto tiempo cuando solo se han cambiado unos pocos archivos?
¿Por qué la implementación web zip incluye siempre la base de código completa y no solo los archivos modificados?
¿Por qué no copio manualmente los archivos modificados y omito toda la implementación web? Pero es difícil averiguar manualmente qué archivos han cambiado. Uso SVN: ¿tiene una forma de generar solo archivos que han cambiado entre dos ramas?
¿Qué otras preguntas debo hacer pero no he pensado todavía?

En respuesta a las respuestas:

Re: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html Esto es exactamente cómo estaba haciendo la implementación, y sería un método ideal. La implementación web identifica correctamente qué archivos han cambiado, sin embargo, el tiempo de espera se agota y no se produce ninguna publicación. Hay alrededor de 2500 archivos en la solución, ¿tal vez se está demorando mucho en identificar cuáles han cambiado? O podría ser que la publicación tenga un valor de tiempo de espera corto y que la carga del archivo zip de 15 mb use todo ese tiempo.

Tengo control total sobre el servidor y es compatible con la implementación web. En realidad, hay 2 servidores: el servidor principal en vivo y un servidor redundante que mantenemos listos en caso de que se caiga el primero. Por lo tanto, cualquier solución debe ser fácil de implementar en más de un servidor (la implementación web fue ideal hasta que dejó de funcionar).

La sugerencia de crear una nueva carpeta para cada versión y luego simplemente cambiar IIS para apuntar a esa nueva carpeta suena como que resultará en un menor tiempo de inactividad / inactividad cuando se realiza la publicación. Pero es un proceso muy manual y preferiría algo más automatizado.

Editar # 2

Me las arreglé para reducirlo y encontré exactamente dónde es lento, pero no por qué. Esto es del registro de despliegue:

[9/02/2011 12:11:56 a.m.] Performing synchronization pass #1. [9/02/2011 12:11:56 a.m.] Parameter entry ''IIS Web Application Name/1'' is applicable to ''iisApp/C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp'' because of its scope. [9/02/2011 12:11:56 a.m.] Parameter entry ''IIS Web Application Name/2'' is applicable to ''setAcl/C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp'' because of its scope. [9/02/2011 12:11:56 a.m.] Parameter entry ''IIS Web Application Name/2'' is applicable to ''setAcl/C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp'' because of its scope. [9/02/2011 12:11:56 a.m.] Parameter entry ''Add write permission to App_Data Folder/1'' is applicable to ''setAcl/C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp/App_Data'' because of its scope. [9/02/2011 12:11:56 a.m.] Source createApp (C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest[''False'',''True'']). Update pending. [9/02/2011 12:11:56 a.m.] Update operation on createApp (C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp) skipped because of rule CreateApplicationRule. [9/02/2011 12:11:56 a.m.] Source filePath (C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp/App_Data/Create.sql) does not match destination (Default Web Site/virtual-dir/App_Data/Create.sql) differing in attributes (size[''259691'',''259697''],lastWriteTime[''02/08/2011 10:45:20'',''02/06/2011 03:48:16'']). Update pending. [400 lines of file updates skipped, time expired 2 seconds ....] [9/02/2011 12:11:58 a.m.] Delete operation on filePath (Default Web Site/v2/zzz_app_offline.htm) skipped because of rule DoNotDeleteRule. [9/02/2011 12:11:58 a.m.] Source setAcl (C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest[''False'',''True''],setAclUser,setAclAccess). Update pending. [9/02/2011 12:11:58 a.m.] Updating setAcl (Default Web Site/virtual-dir/). [9/02/2011 12:13:47 a.m.] Source setAcl (C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest[''False'',''True''],setAclUser,setAclAccess). Update pending. [9/02/2011 12:13:47 a.m.] Updating setAcl (Default Web Site/virtual-dir/). [9/02/2011 12:17:11 a.m.] Source setAcl (C:/src/Site.2010/Site.UI/obj/Release/Package/PackageTmp/App_Data) does not match destination (Default Web Site/virtual-dir//App_Data) differing in attributes (isDest[''False'',''True''],setAclUser,setAclAccess). Update pending. [9/02/2011 12:17:11 a.m.] Updating setAcl (Default Web Site/virtual-dir//App_Data). [9/02/2011 12:17:11 a.m.] The dependency check ''DependencyCheckInUse'' found no issues. [9/02/2011 12:17:11 a.m.] The synchronization completed in 1 pass(es).

La causa de la lentitud es el componente "Updating setAcl" . Estoy examinando las ACL de la caja de desarrollo y la caja del servidor para ver qué es diferente. Sin embargo, parece una idea extremadamente mala copiar la ACL de una caja de desarrollo a una caja de servidor. Ya tenía la ACL configurada bien en el servidor.

@JK de la información que proporcionó se siente como un problema de tiempo de espera. Estoy de acuerdo con @TroyHunt Los archivos de 2500 en 15 megas deberían implementarse rápidamente. En particular, la salida muestra un retraso al aplicar las ACL (ya sea que se deban cambiar o no). Si fuera yo, empezaría a realizar algunas comprobaciones de estado de implementación no web. Algunos pensamientos vienen a la mente

¿Están los servidores web en un dominio o grupo de trabajo?
¿ dcdiag muestra dcdiag ?
¿Qué muestra netdiag ?
¿Están las cajas dev y las cajas prod en el mismo dominio?

¿Hay alguna posibilidad de que esté intentando aplicar usuarios o grupos que ya no existen, están deshabilitados o provienen de dominios que no sean el dominio del servidor web? Es posible que su organización tenga una jerarquía de dominios con dominios secundarios o confianzas de dominio que sean válidos, pero la comunicación esté bloqueada en el centro de datos de producción.

Creo que también miraría manualmente las ACL y vería si hay entradas que no se pueden resolver (aparecen como SIDS antes de la resolución).

HTH, -eric

Acabo de tener un problema similar en el que el despliegue web comenzó a demorar mucho tiempo, especialmente cuando llegó a "Updating setAcl" . Me resistía a deshabilitar la actualización de la ACL como lo sugirieron algunas de las respuestas anteriores, especialmente cuando funcionó bien implementando el mismo proyecto en un servidor diferente.

Así que miré qué era diferente entre las dos máquinas objetivo y la solución fue bastante obvia en retrospectiva. En la máquina de producción teníamos muchos archivos locales temporales que se estaban creando y almacenando durante un mes (por diseño). Reduje la cantidad de archivos y el tiempo de publicación pasó de 30 minutos a unos 15 segundos.

Algunas otras opciones que podría considerar:

1) Implementar en un directorio nuevo cada vez y luego cambiar entre directorios usando IIS.

2) Utilice un repositorio de Subversion separado para sus binarios. svn-load-dirs.pl puede cargar los archivos binarios en subversion y puede marcar correctamente los archivos que se han agregado, eliminado o cambiado. Puede ejecutar svn load-dirs al final de su proceso de compilación automatizado. El proceso de compilación es el único ''usuario'' que ingresa en este repositorio y el servidor de producción es el único lugar que lo verifica para que no haya conflictos de versiones.

Para implementar, simplemente svn actualizar el directorio de trabajo desde el repositorio de subversión binario. Copia de manera eficiente solo los archivos modificados de forma atómica (es decir, si la descarga falla, no reemplaza ningún archivo). Si encuentra un problema justo después de la implementación, puede volver rápidamente a la versión anterior. Si desea actualizar un solo archivo aspx, puede hacer una actualización svn dirigida a ese único archivo.

Si tiene TortoiseSVN instalado en el servidor, también puede ver de inmediato si alguien ha cambiado algún archivo en el servidor sin pasar por la compilación correcta-> registrar-> implementar la ruta.

La única advertencia es que Subversion no maneja diferencias binarias, por lo que su repositorio crecerá rápidamente, pero simplemente puede borrarlo y comenzar de nuevo ocasionalmente, si alguna vez se convierte en un problema.

Otra ventaja es que tienes un registro completo de cada versión que hayas implementado.

He utilizado esta técnica para varios proyectos y desearía que todos los sistemas de implementación funcionaran de forma parecida: por ejemplo, actualización atómica, fácil de revertir, actualización específica de un solo archivo, historial de versiones completo, ...

Así es como estoy haciendo la publicación:

Tengo un gancho en teamcity y cada vez que hago un commit con svn usa un rakefile para copiar archivos a una carpeta de dropbox donde también tengo un repositorio git.
Haz un commit / push para los archivos que han sido cambiados (para este repositorio git). También tengo instalado Dropbox en el servidor.
Tire de los cambios de Dropbox (con git) a una aplicación de prueba para verificar las cosas nuevamente.
Una vez que todo está bien para la aplicación de pruebas, lo cambio por el de producción de iis
Cuando quiero volver a publicar, una vez que todo está sincronizado con Dropbox, hago un tirón de nuevo, en la producción anterior que ahora se convierte en la de ensayo, y cambio de nuevo las aplicaciones.

Resultado-> Los usuarios obtienen 0 segundos de inactividad.

Si quieres cortar algunas esquinas. Puedes hacer un git pull directamente en el sitio de producción. Resultado-> 1 2 segundos de inactividad para los usuarios

Si realmente quieres cortar algunas esquinas. Puede instalar la carpeta de Dropbox directamente en su carpeta de producción y Dropbox sincronizará todo. Resultado 5 6 o más segundos de inactividad para los usuarios.

El hecho de que esté implementando desde VS y no desde un servidor de integración / compilación continuo es el problema aquí.

Empezaría por aislar dónde está ocurriendo el tiempo de espera. Has mencionado un archivo zip de 15MB con 2,500 archivos que no me parece particularmente grande. ¿Ha intentado crear un paquete de implementación en Visual Studio y luego ejecutarlo directamente en el servidor? Esto eliminará la latencia de la red de la imagen, que es una variable bastante fundamental cuando se trata de tiempos de espera.

En cuanto a por qué debe cargarse un archivo zip con la aplicación completa, debe recordar la identificación real de lo que ha cambiado y la implementación posterior en IIS, todo esto sucede en el servidor. No es Visual Studio o msdeploy en su máquina local, lo que está haciendo las cosas bien.

En cuanto a por qué no solo copia los archivos modificados manualmente, se resume en la publicación de mi blog a la que hace referencia, pero en resumen, es laborioso y propenso a errores. Significa que debe trabajar conscientemente a través del proceso de pensamiento de "cuál de mis 2.500 archivos acaba de cambiar" en lugar de simplemente decir "hacer que mi sitio de destino coincida con mi versión de desarrollo". No ha mencionado si está publicando web.config o no, pero obviamente las transformaciones de configuración son otra razón importante por la que el simple enfoque de CTRL-C y CTRL-V es engorroso.

Tratar de tomar un cambio directamente de SVN también es arriesgado. Su primer problema es que necesita tener plena confianza en la integridad y la precisión de la revisión que está actualizando si desea obtener los cambios apropiados publicados. Luego se deja de intentar sincronizar estos con el objetivo y vuelve a los mismos problemas planteados en el párrafo anterior. El otro gran problema es la versión del código objeto siempre es desagradable; estará en un estado de conflicto perpetuo con cualquier otra persona en el proyecto y VCS simplemente no tiene la intención de funcionar de esta manera.

Mi consejo sería centrarse en resolver la causa raíz del problema, ya que el Web Deploy está agotando el tiempo de espera, en lugar de simplemente tratar de solucionar los síntomas. La publicación manual de solo los cambios o la confusión con los enlaces de IIS solo creará más problemas para usted a largo plazo y mucho más trabajo en el plazo inmediato. Vea cómo va a compartir los resultados de crear un paquete, copiarlo en el servidor y luego ejecutarlo localmente y lo tomaremos desde allí. Una vez que esté funcionando como se diseñó, debería ver las implementaciones no más de unos pocos minutos y la interrupción del sitio medida en segundos.

Por cierto, es posible que también desee agregar el tipo de latencia que tiene entre su PC y el servidor y el tiempo que normalmente tomaría transferir un archivo de 15 MB a través de HTTP.

En el cuadro build / dev, use MSBuild de la línea de comandos para compilar el SLN (o wdproj) del proyecto. Asegúrate de precompilar todo. Utilice una ruta de salida separada que limpie antes de la construcción. Obtenga los resultados comprimidos y transfiéralos al servidor web fuera de banda (mediante la ruta UNC o el servidor FTP, o lo que sea). En el servidor, descomprima y haga un despliegue de xcopy.

Para minimizar el tiempo de transferencia, use rsync (hay versiones para Windows), o use 7-zip con la configuración máxima para comprimir archivos binarios.

El tiempo de inactividad del servidor se minimiza, ya que solo se copiaría del disco local al disco local. Aunque es rápido, el grupo de aplicaciones IIS se reciclará, para compensar eso, necesitará dos máquinas detrás de un equilibrador de carga, de modo que pueda actualizar una mientras la otra atiende las solicitudes. (Tal vez una exageración, investigar utilizando los jardines web de IIS)

Para automatizar el proceso, use Powershell, o incluso más simple, con archivos por lotes y PSExec para ejecutar comandos remotos.

Si tiene control sobre el servidor, una buena opción es cargar manualmente el archivo zip. Descomprímalo y luego use el administrador IIS para apuntar al nuevo código base. De esta manera el tiempo de inactividad debe ser mínimo. Y si algo sale mal, tiene intacta su última versión y puede volver a apuntar a IIS a esa carpeta.

Sin embargo, en un servidor compartido esto no funcionará tan bien. Tal vez haya alguna forma de adaptar la misma estrategia cargando el código y luego cambiando el nombre de las carpetas para que apunte a los nuevos archivos.

De todos modos, parece que la implementación web debería permitir enviar solo contenido modificado. Pero creo que es necesario que el host admita la implementación web en ese caso: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html

Si no tienes eso, supongo que podrías usar un script para detectar modificaciones en SVN. Aquí hay información sobre cómo encontrar archivos modificados: http://blog.lysender.com/2010/11/svn-list-modified-files-between-revisions/ recordar que los archivos de código se compilan en archivos dll. Así que me imagino algo como esto:

Publique el sitio web (o use los archivos de un servidor de pruebas que tenga más sentido en su caso)
Haga que el script cree una lista de archivos para modificar (traducir los archivos de código a su dll)
Use un ftp que se pueda controlar a través de la línea de comando para impulsar los cambios.