Cómo implementar su ASP.NET aplicaciones a servidores en vivo?

Hacemos despliegues rolling a los servidores en vivo, por lo que no usamos proyectos de instalación; tenemos algo más como CI:

• compilación"en vivo": el servidor construye desde la fuente aprobada (no la "CABEZA" del repositorio)
• (después de que haya tomado una copia de seguridad; - p)
• robocopy publica en un servidor provisional ("live", pero no en el clúster F5)
• la validación final se realiza en el servidor de ensayo, a menudo con hacks de "hosts" para emular todo el proceso tan de cerca como posible
• robocopy / L se usa automáticamente para distribuir una lista de los cambios en el siguiente "push", para alertar de cualquier error
• como parte de un proceso programado, el clúster se ciclará, implementándose en los nodos del clúster a través de robocopy (mientras están fuera del clúster)

Robocopy garantiza automáticamente que solo se implementen los cambios.

Re the App Pool etc; Me encantaría que esto sea automatizado ( ver esta pregunta ), pero en el momento es manual. Realmente quiero cambiar eso, sin embargo.

(probablemente ayuda 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

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

Publico el sitio web en una carpeta local, lo comprime y luego lo subo a través de FTP. Deployer 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 el sitio web y la base de datos de IIS, pero después de eso, publicar actualizaciones es pan comido.

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 (lo cual es un requisito de SQL Compare), use https://secure.logmein.com/products/hamachi2 / para crear VPN.

Despliego sobre todo ASP.NET aplicaciones a servidores Linux y volver a implementar todo para el cambio más pequeño. Aquí está mi flujo de trabajo estándar:

• Uso un repositorio de código fuente (como Subversion)
• En el servidor, tengo un script bash que hace lo siguiente:
  • Comprueba el último código
  • Hace una compilación (crea las DLL)
  • Filtra los archivos hasta lo esencial (elimina los archivos de código, por ejemplo)
  • Hace una copia de seguridad de la base de datos
  • Despliega el archivos al 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 comprobación se realiza con la versión de línea de comandos de Subversion y la construcción se realiza con xbuild (trabajo similar a msbuild del proyecto Mono). La mayor parte de la magia se hace en ReleaseIt.

En mi servidor de desarrollo esencialmente tengo integración continua, pero en el lado de la producción en realidad SSH en el servidor e iniciar la implementación manualmente ejecutando el script. Mi script se llama inteligentemente 'deploy', así que eso es lo que escribo en el prompt de bash. Soy muy creativa. Ni.

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

El despliegue inicial tarda un par de minutos y la reversión a una versión anterior tarda unos segundos.

Ha sido una buena solución para mí y depende solo de las tres utilidades de línea de comandos (svn, xbuild y releaseit), el cliente de base de datos, 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. Zip hacia arriba, sftp al servidor, extraer en la ubicación correcta. Para el primer despliegue, configuración manual de IIS

Respondiendo a sus preguntas:

1. XCopy
2. Manualmente
3. Para los recursos estáticos, solo implementamos el recurso modificado.
   Para las DLL, implementamos las páginas DLL y ASPX modificadas.
4. Sí, y sí.

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

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

Como desarrollador de BuildMaster, esto es naturalmente lo que uso. Todas las aplicaciones se construyen 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 configura el Grupo de aplicaciones y el Directorio virtual? (¿los crea manualmente o con algunos tool)?

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 aplicaciones nuevas muy a menudo, por lo que es igual de fácil pasar el minuto 1 que se necesita para crear el sitio manualmente.

Cuando un recurso estático cambia (CSS, JS o archivo de imagen) aplicación o solo el recurso modificado? ¿Qué tal cuando cambia una página assembly / ASPX?

De forma predeterminada, el proceso de implementación de artefactos está configurado de tal manera que solo los archivos que se modifican se transfieren al servidor de destino, lo que 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 maneja todo esto por nosotros. La restauración es en su mayoría tan simple como volver a ejecutar una promoción de compilación antigua, pero a veces los cambios en la base de datos deben restaurarse manualmente, y puede ocurrir la pérdida de datos. El proceso básico de reversión se detalla aquí: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

Web setup/install projects-para que pueda desinstalarlo fácilmente si algo sale mal

Desplegar 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 para aplicaciones.net como se explica en esta entrada de blog por Rob Conery.

• viene con un buen comportamiento "predeterminado", en el sentido de que hace muchas cosas estándar para usted: obtener el código del control de código fuente, compilar, crear el grupo de aplicaciones, configurar up IIS, etc
• lanzamientos basados en lo que hay en control de código fuente
• tiene ganchos de tarea , por lo que el comportamiento predeterminado se puede extender o alterar fácilmente
• tiene reversión
• es todo powershell , por lo que no hay dependencias externas
• utiliza powershell remoting para acceder a máquinas remotas

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

Así que para responder a las preguntas arriba:

• 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 Powereshell

• Cuando se implementa una aplicación por primera vez, ¿cómo se configura el Grupo de aplicaciones y el Directorio Virtual (se crean manualmente o con alguna herramienta)?

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

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

  Yes unfold hace esto, cualquier deploy se instala junto a los demás. De esa manera podemos fácilmente rollback cuando algo sale mal. También nos permite rastrear fácilmente una versión implementada para una revisión de control de código fuente.

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

  Sí, unfold mantiene versiones antiguas. No todas las versiones, pero un número de versiones. Hace que retroceder sea casi trivial.

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

Así que al checkin, nuestra compilación "normal"hace lo siguiente:

• Jenkins realiza una actualización SVN para obtener la última versión del código
• Se realiza una restauración de paquetes NuGet ejecutándose contra nuestro propio repositorio NuGet local
• Se compila la aplicación usando MSBuild. Configurar esto es una aventura, porque necesita instalar el MSBuild correcto y luego el ASP.NET y MVC dll en su caja de compilación. (Como nota al margen, cuando tenía <MvcBuildViews>true</MvcBuildViews> entró en mi.archivos csproj para compilar las vistas, msbuild se estrelló al azar, así que tuve que desactivarlo)
• Una vez compilado el código se ejecutan las pruebas unitarias (estoy usando nunit para esto, pero puedes usar lo que quieras)
• Si pasan todas las pruebas unitarias, detengo el grupo de aplicaciones de IIS y despliego la aplicación localmente (solo unos pocos comandos básicos de XCOPY para copiar los archivos necesarios) y luego reiniciar IIS (he tenido problemas con IIS bloqueando archivos, y esto lo resolvió)
• Tengo web separada.archivos de configuración para cada entorno; dev, uat, prod. (Traté de usar el material de transformación web con poco éxito). Así que la web correcta.el archivo de configuración también se copia en
• Luego uso PhantomJS para ejecutar un montón de pruebas de interfaz de usuario. También toma un montón de capturas de pantalla en diferentes resoluciones (móvil, escritorio) y sella cada captura de pantalla con alguna 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 IU de integración pasan la compilación es exitosa

Si alguien hace clic en "Deploy to UAT":

• Si la última compilación fue exitosa, Jenkins realiza otra actualización de SVN
• La aplicación se compila usando una configuración de 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 build box 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í, construir es un éxito!

Cuando hacemos clic en "Desplegar a Prod":

• El usuario selecciona una etiqueta UAT que se creó previamente
• La etiqueta es "switched" a
• El código se compila y sincroniza con Servidor Prod
• Solicitud http al servidor Prod
• Esta revisión está etiquetada en SVN como Prod-datetime
• La liberación se comprime y se almacena

Toda una construcción completa hasta la producción toma 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 interfaz de usuario entra en producción, las capturas de pantalla con suerte mostrarán qué revisión # causó el it
• UAT y Prod se mantienen en sincronización
• Jenkins te muestra un gran historial de lanzamientos para UAT y Prod con todos los mensajes de confirmación
• Las versiones UAT y Prod se etiquetan automáticamente
• Puedes ver cuándo ocurren las liberaciones y quién las hizo

Los principales inconvenientes de esta solución son:

• Cada vez que haces un lanzamiento para Prod necesitas hacer un lanzamiento para UAT. Esta fue una decisión consciente que tomamos porque queríamos asegurarnos de que UAT siempre esté al día con Prod. Aún así, es un dolor.
• Hay bastantes archivos de configuración flotando alrededor. He intentado tenerlo todo en Jenkins, pero hay algunos archivos de soporte por lotes necesarios como parte del proceso. (Estos también se registran).
• Los scripts de actualización y degradación de la base de datos forman parte de la aplicación y se ejecutan al iniciar la aplicación. Funciona (en su mayoría), pero es un dolor.

Me encantaría escuchar cualquier otra mejora posible!

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

A partir de ahí usamos el software Smart Sync para comparar con un servidor de producción que estaba fuera del grupo de carga equilibrada, y movió 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 compañía para la que trabajé solíamos implementar usando 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. Así que excluyendo a todos nuestros .cs files, solution and project files es muy fácil, por ejemplo.

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

• En primer lugar, compruebe que el usuario tiene la última revisión. Si no es así, 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á cargando y la fecha y hora de la carga. Agregue una nueva línea para la carga actual y luego envíela al servidor junto con los archivos modificados. Esto hace que sea extremadamente fácil averiguar qué versión del sitio para retroceder en la remota posibilidad de que una carga cause problemas.

Además de esto, hay un segundo archivo por lotes que solo comprueba las diferencias de archivos 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 probable culpable y pedirles que comprometieran su trabajo.

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

Mientras que la solución se sentía un poco torpe en el momento desde entonces he llegado a apreciar mucho más cuando se trabaja en entornos donde el método de carga es mucho menos elegante o fácil (escritorio remoto, copiar y pegar todo el sitio, para instancia).

Recomiendo no solo sobrescribir los archivos de aplicación existentes, sino crear un directorio por versión y volver a asignar 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
• No hay riesgo de que los archivos antiguos causen problemas
• Tiempo de inactividad más o menos cero (generalmente solo una pausa en el nuevo appdomain inicializa)

El único problema que hemos tenido es los recursos se almacenan en caché si no reinicia el grupo de aplicaciones y confía en el conmutador automático appdomain.