asp.net - tag - web forms c# ejemplos

¿Cómo despliega sus aplicaciones ASP.NET en servidores activos? (13)

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

Estoy particularmente interesado en el flujo de trabajo que ocurre entre el momento en que su servidor de Integración de compilación continua descarta los binarios en alguna ubicación y el momento en que la primera solicitud de usuario acierta estos binarios.

¿Estás usando algunas herramientas específicas o simplemente XCOPY? ¿Cómo está empaquetada la aplicación (ZIP, MSI, ...)?
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 alguna herramienta)?
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é tal cuando cambia una página de ensamblaje / ASPX?
¿Mantiene un registro de todas las versiones desplegadas para una aplicación determinada y, en caso de que algo vaya 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 utilizamos para implementar nuestras aplicaciones ASP.NET:

Agregamos un Proyecto de Despliegue Web a la solución y lo configuramos para construir la aplicación web ASP.NET
Agregamos un Proyecto de Configuración ( NO Proyecto de Configuración Web) a la solución y lo configuramos para tomar el resultado del Proyecto de Implementación Web
Agregamos una acción de instalación personalizada y en el evento OnInstall ejecutamos un ensamblaje .NET personalizado que crea un Pool 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 varios sitios web en IIS, Autenticación para directorios virtuales e identificación de identidades para grupos de aplicaciones.
Agregamos una tarea personalizada en TFS para construir el Proyecto de Configuración (TFS no es compatible con los Proyectos de Configuración, así que tuvimos que usar devenv.exe para construir el MSI)
El MSI está instalado en el servidor en vivo (si hay una versión anterior del MSI, primero se desinstala)

¿Estás usando algunas herramientas específicas o simplemente XCOPY? ¿Cómo está empaquetada 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 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 para realizar en entornos futuros a medida que la aplicación se mueve a través de sus entornos de prueba. Esto también se puede automatizar con un simple script de PowerShell, pero no agregamos nuevas aplicaciones con mucha frecuencia, así que es tan fácil pasar 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é tal cuando cambia una página de ensamblaje / ASPX?

De forma predeterminada, el proceso de despliegue de artefactos se configura de manera tal 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 ensamblajes vinculados.

¿Mantiene un registro de todas las versiones desplegadas para una aplicación determinada y, en caso de que algo vaya mal, tiene procedimientos para restaurar la aplicación a un estado de trabajo conocido anterior?

Sí, BuildMaster maneja todo esto por nosotros. Restaurar 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 ser restaurados manualmente y la pérdida de datos puede ocurrir. El proceso básico de reversión se detalla aquí: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

Contestando tus preguntas:

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

Mantenerlo bien y simple nos ha ahorrado muchos dolores de cabeza hasta el momento.

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

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

Finalmente, después de validar el lanzamiento, ejecutamos un script DOS que usaba principalmente RoboCopy para sincronizar el código con los servidores activos, 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 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 agradable poder escribir en varios comandos SVN para lograr lo siguiente:

Primero, verifique que el usuario tenga la última revisión. De lo contrario, solicíteles que actualicen o ejecuten la actualización allí mismo.
Descargue un archivo de texto del servidor llamado "synclog.txt" que detalla quién es el usuario 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 al servidor junto con los archivos modificados. Esto hace que sea extremadamente fácil averiguar a qué versión del sitio 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 archivos en el servidor en vivo. Esto puede resaltar el problema común en el que alguien cargaría pero no comprometería sus cambios a SVN. En combinación con el registro de sincronización mencionado anteriormente, podríamos averiguar quién era el culpable y pedirles que comenten su trabajo.

Y, por último, rSync le permite tomar una copia de seguridad de los archivos que fueron reemplazados durante la carga. Hicimos que se movieran a una carpeta de respaldo Entonces, si de repente se daba cuenta de que algunos de los archivos no deberían haber sido sobrescritos, puede encontrar la última copia de respaldo de cada archivo en esa carpeta.

Si bien la solución me pareció un poco torpe en el momento, desde entonces he llegado a apreciarla 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) .

Hacemos implementaciones continuas en los servidores activos, por lo que no usamos proyectos instaladores; tenemos algo más como CI:

construcciones del servidor de compilación "en vivo" a partir de la fuente aprobada (no la "CABEZA" del repositorio)
(después de haber tomado una copia de seguridad ;-p)
robocopy publica en un servidor intermedio ("en vivo", pero no en el clúster F5)
validación final realizada en el servidor de etapas, a menudo con "hosts" hacks para emular todo lo más cerca 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 recicla y se implementa en los nodos del clúster mediante robocopy (mientras están fuera del clúster)

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

Re the App Pool, etc; Me encantaría que fuera automático ( ver esta pregunta ), pero por el momento es manual. Realmente quiero cambiar eso, sin embargo.

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

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

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

Jenkins hace una actualización de SVN para buscar la última versión del código
Se realiza una restauración del paquete NuGet ejecutándose en nuestro propio repositorio NuGet local
La aplicación se compila utilizando MsBuild. Configurar esto es una aventura, porque necesita instalar el MsBuild correcto y luego el dll ASP.NET y MVC en su caja de compilación. (Como nota al margen, cuando tenía <MvcBuildViews>true</MvcBuildViews> ingresado en mis archivos .csproj para compilar las vistas, msbuild se bloqueaba 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 de unidad pasan, dejo el grupo de aplicaciones IIS, despliegue la aplicación localmente (solo unos pocos comandos XCOPY básicos para copiar los archivos necesarios) y luego reinicio IIS (he tenido problemas con los archivos de bloqueo de IIS, y esto solucionó 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 UI. También toma un montón de capturas de pantalla con diferentes resoluciones (móvil, escritorio) y marca cada captura de pantalla con 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 integración de interfaz de usuario pasan la compilación tiene éxito

Si alguien hace clic en "Implementar a UAT":

Si la última compilación fue exitosa, Jenkins hace 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 llegamos hasta aquí, ¡construir es exitoso!

Cuando hacemos clic en "Implementar a Prod":

El usuario selecciona una etiqueta UAT que se creó previamente
La etiqueta está "cambiada" a
El código se compila y sincroniza con el servidor Prod
Http solicitud al servidor Prod
Esta revisión está etiquetada en SVN como Prod-datetime
La versión está comprimida y almacenada

Todo un desarrollo completo de la producción lleva unos 30 segundos, con lo que estoy muy, muy contento.

Upsides a esta solución:

Es rápido
Las pruebas unitarias deben detectar errores de lógica
Cuando un error de UI entre en producción, las capturas de pantalla mostrarán con un poco de suerte qué revisión lo causó.
UAT y Prod se mantienen sincronizados
Jenkins le muestra un excelente historial de versiones de UAT y Prod con todos los mensajes de confirmación
Las versiones de UAT y Prod están todas etiquetadas automáticamente
Puedes ver cuándo se producen los lanzamientos y quién los hizo

Las principales desventajas de esta solución son:

Cada vez que hagas un lanzamiento a Prod necesitas hacer un lanzamiento a UAT. Esta fue una decisión consciente que tomamos porque queríamos garantizar siempre 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 respaldo como parte del proceso. (Estos también se registran).
Los scripts de actualización y bajada de DB son parte de la aplicación y se ejecutan al inicio de la aplicación. Funciona (principalmente), pero es un dolor.

¡Me encantaría escuchar cualquier otra mejora posible!

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

Yo 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 a lo esencial (elimina los archivos de código, por ejemplo)
- Realiza copias de seguridad de la base de datos
- Despliega los 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 el próximo golpe

El proceso de pago se realiza con la versión de línea de comando de Subversion y la compilación se realiza con xbuild (trabajo similar a un trabajo de construcción del proyecto Mono). La mayor parte de la magia se realiza en ReleaseIt.

En mi servidor de desarrollo, esencialmente tengo integración continua, pero en lo que respecta a la producción, de hecho, SSH en el servidor e inicio la implementación de forma manual ejecutando el script. Mi script se llama inteligentemente ''deploy'', así que eso es lo que escribo en el prompt bash. Soy muy creativo No.

En producción, tengo que escribir ''implementar'' dos veces: una para extraer, compilar e implementar en un directorio fechado y otra para convertir ese directorio en la instancia predeterminada. Dado que los directorios están fechados, puedo volver a cualquier implementación anterior simplemente escribiendo ''deploy'' 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 solo se basa en 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 alguna vez:

http://releaseit.codeplex.com/

Recomiendo NO sobrescribir los archivos de las aplicaciones existentes, sino crear un directorio por versión y redefinir la aplicación IIS en 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 nulo (generalmente solo se inicia una pausa en el nuevo dominio de aplicación)

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

Simple XCopy para ASP.NET. Zip it up, sftp al servidor, extraer en el lugar correcto. Para la primera implementación, configuración manual de IIS

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

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

Sitio web

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

Publico el sitio web en una carpeta local, lo comprime y luego lo carga 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 necesita conectarse al servidor y configurar IIS WebSite, la base de datos, 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 (que es un requisito de SQL Compare), use https://secure.logmein.com/products/hamachi2/ para crear VPN.

Unfold es una solución de implementación tipo 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 para usted: obtener el código del control de origen, crear, crear el grupo de aplicaciones, configurar IIS, etc.
lanzamientos basados en lo que está en control de fuente
tiene ganchos de tarea , por lo que el comportamiento predeterminado puede ampliarse o modificarse fácilmente
tiene retroceso
es todo Powershell , entonces no hay dependencias externas
usa powershell remoting para acceder a máquinas remotas

Aquí hay una introduction y algunas otras publicaciones en el blog.

Para responder a las preguntas anteriores:

¿Cómo está empaquetada la aplicación (ZIP, MSI, ...)?
Git (u otra scm) es la forma predeterminada de obtener la aplicación en la máquina de destino. Alternativamente, puede realizar una construcció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 configura el grupo de aplicaciones y el directorio virtual (¿los crea manualmente o con alguna herramienta)?
Desdoble configura el grupo de aplicaciones y la aplicación web mediante el Módulo de administración web de Powershell. Nos permite (y usted) modificar cualquier aspecto del grupo de aplicaciones o 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é tal cuando cambia una página de ensamblaje / ASPX?
Sí desplegar hace esto, cualquier despliegue se instala al lado de los demás. De esta forma, podemos retroceder fácilmente cuando algo falla. También nos permite rastrear fácilmente una versión implementada a una revisión de control de origen.
¿Mantiene un registro de todas las versiones implementadas para una aplicación determinada?
Sí, desplegar mantiene viejas versiones. No todas las versiones, sino varias versiones. Hace que el retroceso sea casi trivial.