¿Cómo implementa sus aplicaciones ASP.NET en servidores activos?

Estoy buscando diferentes técnicas / herramientas que utiliza para implementar un proyecto de aplicación web ASP.NET ( NO un sitio web ASP.NET) en producción.

Estoy particularmente interesado en el flujo de trabajo que ocurre entre el momento en que su servidor Continuous Integration Build suelta los binarios en alguna ubicación y el momento en que la primera solicitud del usuario llega a estos binarios.

1. ¿Está utilizando algunas herramientas específicas o simplemente XCOPY? ¿Cómo se empaqueta la aplicación (ZIP, MSI, ...)?

2. Cuando se implementa una aplicación por primera vez, ¿cómo se configura el grupo de aplicaciones y el directorio virtual (los crea manualmente o con alguna herramienta)?

3. Cuando cambia un recurso estático (CSS, JS o archivo de imagen), ¿vuelve a implementar toda la aplicación o solo el recurso modificado? ¿Qué pasa cuando cambia una página ASPX / ensamblado?

4. ¿Realiza un seguimiento de todas las versiones implementadas para una aplicación determinada y, en caso de que algo salga mal, tiene procedimientos para restaurar la aplicación a un estado de trabajo conocido anterior?

Siéntase libre de completar la lista anterior.

Y esto es lo que usamos para implementar nuestras aplicaciones ASP.NET:

1. Agregamos un proyecto de implementación web a la solución y lo configuramos para construir la aplicación web ASP.NET
2. Agregamos un proyecto de instalación ( NO un proyecto de instalación web) a la solución y lo configuramos para que tome la salida del proyecto de implementación web.
3. Agregamos una acción de instalación personalizada y en el evento OnInstall ejecutamos un ensamblado .NET de compilación personalizado que crea un grupo de aplicaciones y un directorio virtual en IIS usando System.DirectoryServices.DirectoryEntry (esta tarea se realiza solo la primera vez que se implementa una aplicación) . Admitimos múltiples sitios web en IIS, autenticación para directorios virtuales y configuración de identidades para grupos de aplicaciones.
4. Agregamos una tarea personalizada en TFS para construir el proyecto de instalación (TFS no admite proyectos de instalación, por lo que tuvimos que usar devenv.exe para construir el MSI)
5. El MSI está instalado en el servidor en vivo (si hay una versión anterior del MSI, primero se desinstala)

Hemos implementado todo nuestro código en MSI mediante Setup Factory. Si algo tiene que cambiar, volvemos a implementar toda la solución. Esto suena exagerado para un archivo css, pero mantiene absolutamente todos los entornos sincronizados y sabemos exactamente qué está en producción (implementamos en todos los entornos de prueba y uat de la misma manera).

Realizamos una implementación continua en los servidores activos, por lo que no usamos proyectos de instalación; tenemos algo más parecido a CI:

• El servidor de compilación "en vivo" se compila a partir de la fuente aprobada (no el "HEAD" del repositorio)
• (después de haber realizado una copia de seguridad ;-p)
• robocopy publica en un servidor de ensayo ("en vivo", pero no en el clúster F5)
• validación final realizada en el servidor de ensayo, a menudo con trucos de "hosts" para emular todo lo más fielmente posible
• robocopy / L se utiliza automáticamente para distribuir una lista de los cambios en el próximo "empuje", para alertar de cualquier error
• como parte de un proceso programado, el clúster se cicla y se implementa en los nodos del clúster a través de robocopy (mientras están fuera del clúster)

robocopy asegura automáticamente que solo se implementen los cambios.

Re el grupo de aplicaciones, etc; Me encantaría que esto fuera automático ( ver esta pregunta ), pero por el momento es manual. Sin embargo, realmente quiero cambiar eso.

(Probablemente ayude que tengamos nuestro propio centro de datos y granja de servidores "en el sitio", por lo que no tenemos que cruzar muchos obstáculos)

Sitio web

Implementador: http://www.codeproject.com/KB/install/deployer.aspx

Publico el sitio web en una carpeta local, lo comprimo y luego lo subo a través de FTP. El implementador en el servidor luego extrae zip, reemplaza los valores de configuración (en Web.Config y otros archivos), y eso es todo.

Por supuesto, para la primera ejecución, debe conectarse al servidor y configurar IIS WebSite, la base de datos, pero después de eso, la publicación de actualizaciones es muy fácil.

Base de datos

Para mantener las bases de datos sincronizadas, utilizo http://www.red-gate.com/products/sql-development/sql-compare/

Si el servidor está detrás de un montón de enrutadores y no puede conectarse directamente (que es un requisito de SQL Compare), use https://secure.logmein.com/products/hamachi2/ para crear VPN.

Implemento principalmente aplicaciones ASP.NET en servidores Linux y vuelvo a implementar todo, incluso para el cambio más pequeño. Aquí está mi flujo de trabajo estándar:

• Utilizo un repositorio de código fuente (como Subversion)
• En el servidor, tengo un script bash que hace lo siguiente:
  • Consulta el último código
  • Hace una compilación (crea las DLL)
  • Filtra los archivos hasta lo esencial (elimina archivos de código, por ejemplo)
  • Realiza una copia de seguridad de la base de datos
  • Implementa los archivos en el servidor web en un directorio nombrado con la fecha actual
  • Actualiza la base de datos si se incluye un nuevo esquema en la implementación.
  • Hace que la nueva instalación sea la predeterminada, por lo que se servirá con la próxima visita

La verificación se realiza con la versión de línea de comandos de Subversion y la construcción se realiza con xbuild (msbuild funciona igual que el proyecto Mono). La mayor parte de la magia se realiza en ReleaseIt.

En mi servidor de desarrollo, básicamente tengo una integración continua, pero en el lado de la producción, en realidad, SSH en el servidor e inicio la implementación manualmente ejecutando el script. Mi script se llama inteligentemente 'implementar', por lo que es lo que escribo en el indicador de bash. Soy muy creativo No.

En producción, tengo que escribir 'implementar' dos veces: una vez para realizar el check-out, compilar e implementar en un directorio con fecha y una vez para convertir ese directorio en la instancia predeterminada. Dado que los directorios están fechados, puedo volver a cualquier implementación anterior simplemente escribiendo 'implementar' desde el directorio correspondiente.

La implementación inicial toma un par de minutos y la reversión a una versión anterior toma unos segundos.

Ha sido una buena solución para mí y se basa solo en las tres utilidades de la línea de comandos (svn, xbuild y releaseit), el cliente DB, SSH y Bash.

Realmente necesito actualizar la copia de ReleaseIt en CodePlex en algún momento:

http://releaseit.codeplex.com/

XCopy simple para ASP.NET. Ciérrelo, sftp al servidor, extráigalo en la ubicación correcta. Para la primera implementación, configuración manual de IIS

Contestando tus preguntas:

1. XCopy
2. A mano
3. Para los recursos estáticos, solo implementamos el recurso modificado.
   Para las DLL, implementamos las páginas DLL y ASPX modificadas.
4. Si y si.

Mantenerlo agradable y simple nos ha ahorrado muchos dolores de cabeza hasta ahora.

¿Está utilizando algunas herramientas específicas o simplemente XCOPY? ¿Cómo se empaqueta la aplicación (ZIP, MSI, ...)?

Como desarrollador de BuildMaster , esto es, naturalmente, lo que uso. Todas las aplicaciones se crean y empaquetan dentro de la herramienta como artefactos, que se almacenan internamente como archivos ZIP.

Cuando se implementa una aplicación por primera vez, ¿cómo se configura el grupo de aplicaciones y el directorio virtual (los crea manualmente o con alguna herramienta)?

Manualmente: creamos un control de cambios dentro de la herramienta que nos recuerda los pasos exactos a realizar en entornos futuros a medida que la aplicación se mueve a través de sus entornos de prueba. Esto también podría automatizarse con un simple script de PowerShell, pero no agregamos nuevas aplicaciones con mucha frecuencia, por lo que es igual de fácil dedicar el minuto que lleva crear el sitio manualmente.

Cuando cambia un recurso estático (CSS, JS o archivo de imagen), ¿vuelve a implementar toda la aplicación o solo el recurso modificado? ¿Qué pasa cuando cambia una página ASPX / ensamblado?

De forma predeterminada, el proceso de implementación de artefactos está configurado de manera que solo los archivos que se modifican se transfieren al servidor de destino; esto incluye todo, desde archivos CSS, archivos JavaScript, páginas ASPX y ensamblados vinculados.

¿Realiza un seguimiento de todas las versiones implementadas para una aplicación determinada y, en caso de que algo salga mal, tiene procedimientos para restaurar la aplicación a un estado de trabajo conocido anterior?

Sí, BuildMaster se encarga de todo esto por nosotros. La restauración es principalmente tan simple como volver a ejecutar una promoción de compilación anterior, pero a veces los cambios en la base de datos deben restaurarse manualmente y se pueden producir pérdidas de datos. El proceso de reversión básico se detalla aquí: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

proyectos de instalación / configuración web, para que pueda desinstalarlo fácilmente si algo sale mal

Unfold es una solución de implementación similar a capistrano que escribí para aplicaciones .net. Es lo que usamos en todos nuestros proyectos y es una solución muy flexible. Resuelve la mayoría de los problemas típicos de las aplicaciones .net, como se explica en esta publicación de blog de Rob Conery.

• viene con un buen comportamiento "predeterminado", en el sentido de que hace muchas cosas estándar por usted: obtener el código del control de fuente, compilar, crear el grupo de aplicaciones, configurar IIS, etc.
• lanzamientos basados ​​en lo que hay en el control de fuente
• tiene ganchos de tareas , por lo que el comportamiento predeterminado se puede ampliar o modificar fácilmente
• tiene retroceso
• es todo PowerShell , por lo que no hay dependencias externas
• utiliza la comunicación remota de PowerShell para acceder a máquinas remotas

Aquí hay una introducción y algunas otras publicaciones de blog.

Entonces, para responder a las preguntas anteriores:

• ¿Cómo se empaqueta la aplicación (ZIP, MSI, ...)?

  Git (u otro scm) es la forma predeterminada de obtener la aplicación en la máquina de destino. Alternativamente, puede realizar una compilación local y copiar el resultado a través de la conexión remota de Powereshell

• Cuando se implementa una aplicación por primera vez, ¿cómo se configura el grupo de aplicaciones y el directorio virtual (los crea manualmente o con alguna herramienta)?

  Unfold configura el grupo de aplicaciones y la aplicación del sitio web mediante el módulo de administración web de Powershell. Nos permite (y a usted) modificar cualquier aspecto del grupo de aplicaciones o del sitio web.

• Cuando cambia un recurso estático (CSS, JS o archivo de imagen), ¿vuelve a implementar toda la aplicación o solo el recurso modificado? ¿Qué pasa cuando cambia una página ASPX / ensamblado?

  Sí, desplegar hace esto, cualquier despliegue se instala junto a los demás. De esa manera, podemos revertir fácilmente cuando algo sale mal. También nos permite rastrear fácilmente una versión implementada a una revisión de control de fuente.

• ¿Realiza un seguimiento de todas las versiones implementadas para una aplicación determinada?

  Sí, desplegar mantiene las versiones antiguas. No todas las versiones, pero sí varias. Hace que retroceder sea casi trivial.

Hemos estado mejorando nuestro proceso de lanzamiento durante el año pasado y ahora lo tenemos controlado. Estoy usando Jenkins para administrar todas nuestras compilaciones y lanzamientos automatizados, pero estoy seguro de que podrías usar TeamCity o CruiseControl.

Entonces, al registrarse, nuestra compilación "normal" hace lo siguiente:

• Jenkins realiza una actualización de SVN para obtener la última versión del código
• La restauración de un paquete NuGet se ejecuta en nuestro propio repositorio NuGet local.
• La aplicación se compila con MsBuild. Configurar esto es una aventura, porque necesita instalar el MsBuild correcto y luego los dll de ASP.NET y MVC en su caja de compilación. (Como nota al margen, cuando <MvcBuildViews>true</MvcBuildViews>ingresé en mis archivos .csproj para compilar las vistas, msbuild fallaba aleatoriamente, así que tuve que deshabilitarlo)
• Una vez que se compila el código, se ejecutan las pruebas unitarias (estoy usando nunit para esto, pero puedes usar lo que quieras)
• Si todas las pruebas unitarias pasan, detengo el grupo de aplicaciones de IIS, implemento la aplicación localmente (solo algunos comandos básicos de XCOPY para copiar los archivos necesarios) y luego reinicio IIS (he tenido problemas con los archivos de bloqueo de IIS, y esto resuelto eso)
• Tengo archivos web.config separados para cada entorno; dev, uat, prod. (Intenté usar las cosas de transformación web con poco éxito). Entonces, el archivo web.config correcto también se copia en
• Luego uso PhantomJS para ejecutar un montón de pruebas de IU. También toma un montón de capturas de pantalla en diferentes resoluciones (móvil, escritorio) y marca cada captura de pantalla con algo de información (título de la página, resolución). Jenkins tiene un gran soporte para manejar estas capturas de pantalla y se guardan como parte de la compilación.
• Una vez que las pruebas de la interfaz de usuario de integración pasan, la compilación es exitosa

Si alguien hace clic en "Implementar en UAT":

• Si la última compilación fue exitosa, Jenkins realiza otra actualización de SVN
• La aplicación se compila utilizando una configuración RELEASE
• Se crea un directorio "www" y la aplicación se copia en él.
• Luego uso winscp para sincronizar el sistema de archivos entre el cuadro de compilación y UAT
• Envío una solicitud HTTP al servidor UAT y me aseguro de obtener un 200
• Esta revisión está etiquetada en SVN como UAT-datetime
• Si hemos llegado hasta aquí, ¡la compilación es exitosa!

Cuando hacemos clic en "Implementar en producción":

• El usuario selecciona una etiqueta UAT que fue creada previamente
• La etiqueta se "cambia" a
• El código se compila y sincroniza con el servidor Prod
• Solicitud HTTP al servidor de producción
• Esta revisión está etiquetada en SVN como Prod-datetime
• El comunicado está comprimido y almacenado.

Toda una construcción completa para la producción lleva unos 30 segundos, con lo que estoy muy, muy contento.

Ventajas de esta solución:

• Es rápido
• Las pruebas unitarias deben detectar errores lógicos
• Cuando un error de IU entra en producción, las capturas de pantalla mostrarán qué revisión # causó el
• UAT y Prod se mantienen sincronizados
• Jenkins le muestra un gran historial de versiones para UAT y Prod con todos los mensajes de confirmación
• Las versiones de UAT y Prod se etiquetan automáticamente
• Puede ver cuándo ocurren los lanzamientos y quién los hizo

Las principales desventajas de esta solución son:

• Siempre que haga un lanzamiento a Prod, debe hacerlo a UAT. Esta fue una decisión consciente que tomamos porque queríamos asegurarnos siempre de que UAT esté siempre actualizado con Prod. Aún así, es un dolor.
• Hay bastantes archivos de configuración flotando. Intenté tenerlo todo en Jenkins, pero se necesitan algunos archivos por lotes de soporte como parte del proceso. (Estos también están registrados).
• Los scripts de actualización y degradación de la base de datos son parte de la aplicación y se ejecutan al iniciar la aplicación. Funciona (principalmente), pero es un fastidio.

¡Me encantaría escuchar otras posibles mejoras!

En 2009, de donde proviene esta respuesta, usamos CruiseControl.net para nuestras compilaciones de Integración Continua, que también produjeron Release Media.

A partir de ahí, usamos el software Smart Sync para compararlo con un servidor de producción que estaba fuera del grupo de equilibrio de carga y movimos los cambios hacia arriba.

Finalmente, después de validar la versión, ejecutamos un script de DOS que usaba principalmente RoboCopy para sincronizar el código con los servidores en vivo, deteniendo / iniciando IIS a medida que avanzaba.

En la última empresa para la que trabajé, solíamos implementar utilizando un archivo por lotes rSync para cargar solo los cambios desde la última carga. La belleza de rSync es que puede agregar listas de exclusión para excluir archivos específicos o patrones de nombre de archivo. Por lo tanto, excluir todos nuestros archivos .cs, archivos de soluciones y proyectos es realmente fácil, por ejemplo.

Estábamos usando TortoiseSVN para el control de versiones, por lo que fue bueno poder escribir varios comandos SVN para lograr lo siguiente:

• En primer lugar, compruebe que el usuario tiene la última revisión. De lo contrario, pídales que actualicen o ejecute la actualización allí mismo.
• Descargue un archivo de texto del servidor llamado "synclog.txt" que detalla quién es el usuario de SVN, qué número de revisión están cargando y la fecha y hora de la carga. Agregue una nueva línea para la carga actual y luego envíela de regreso al servidor junto con los archivos modificados. Esto hace que sea extremadamente fácil averiguar a qué versión del sitio se debe revertir en caso de que una carga cause problemas.

Además de esto, hay un segundo archivo por lotes que solo verifica las diferencias de archivo en el servidor en vivo. Esto puede resaltar el problema común en el que alguien cargaría pero no confirmaría sus cambios en SVN. Combinado con el registro de sincronización mencionado anteriormente, podríamos averiguar quién era el posible culpable y pedirles que comprometieran su trabajo.

Y, por último, rSync le permite realizar una copia de seguridad de los archivos que fueron reemplazados durante la carga. Hicimos que los moviera a una carpeta de respaldo. Entonces, si de repente se dio cuenta de que algunos de los archivos no deberían haberse sobrescrito, puede encontrar la última versión de respaldo de cada archivo en esa carpeta.

Si bien la solución se sintió un poco torpe en ese momento, desde entonces la aprecio mucho más cuando trabajo en entornos donde el método de carga es mucho menos elegante o fácil (escritorio remoto, copiar y pegar todo el sitio, por ejemplo) .

Recomendaría NO solo sobrescribir los archivos de la aplicación existente, sino crear un directorio por versión y volver a apuntar la aplicación IIS a la nueva ruta. Esto tiene varios beneficios:

• Rápido para revertir si es necesario
• No es necesario detener IIS o el grupo de aplicaciones para evitar problemas de bloqueo
• Sin riesgo de que los archivos antiguos causen problemas
• Tiempo de inactividad más o menos cero (por lo general, solo una pausa cuando se inicia el nuevo dominio de aplicación)

El único problema que hemos tenido es que los recursos se almacenan en caché si no reinicia el grupo de aplicaciones y confía en el cambio automático del dominio de la aplicación.