Compartir vía

Administración del ciclo de vida de las aplicaciones: del desarrollo a la producción

  • Artículo

Por Jason Lee

En este tema se muestra cómo una empresa ficticia administra la implementación de una aplicación web de ASP.NET a través de entornos de prueba, ensayo y producción como parte de un proceso de desarrollo continuo. A lo largo del tema, se proporcionan vínculos para obtener más información y tutoriales sobre cómo realizar tareas específicas.

El tema está diseñado a modo de resumen general de una serie de tutoriales sobre implementación web en la empresa. No se preocupe si desconoce algunos de los conceptos descritos aquí: en los tutoriales que siguen a este encontrará información detallada sobre todas estas tareas y técnicas.

Nota:

Por motivos de simplicidad, en este tema no se describe la actualización de bases de datos como parte del proceso de implementación. Sin embargo, realizar actualizaciones incrementales de las características de las bases de datos es requisito indispensable en muchos escenarios de implementación empresarial; encontrará instrucciones sobre cómo realizar esto más adelante en esta serie de tutoriales. Para obtener más información, consulte Implementar proyectos de base de datos.

Información general

El proceso de implementación que se muestra aquí se basa en el escenario de implementación de Fabrikam, Inc. descrito en Implementación web de empresa: información general del escenario. Antes de adentrarse en este tema, debe leer la información general del escenario. Básicamente, el escenario examina cómo una organización administra la implementación de una aplicación web relativamente compleja, la solución Contact Manager, a través de varias fases en un entorno empresarial típico.

En términos generales, la solución Contact Manager pasa por estas fases como parte del proceso de desarrollo e implementación:

  1. Un desarrollador comprueba código en Team Foundation Server (TFS) 2010.
  2. TFS compila el código y ejecuta las pruebas unitarias asociadas al proyecto de equipo.
  3. TFS implementa la solución en el entorno de prueba.
  4. El equipo de desarrolladores comprueba y valida la solución en el entorno de prueba.
  5. El administrador del entorno de ensayo realiza una implementación "what if" en el entorno de ensayo para averiguar si la implementación va a provocar problemas.
  6. El administrador del entorno de ensayo realiza una implementación dinámica en el entorno de ensayo.
  7. La solución se somete a pruebas de aceptación del usuario en el entorno de ensayo.
  8. Los paquetes de implementación web se importan manualmente al entorno de producción.

Estas fases forman parte de un ciclo de desarrollo continuo.

These stages form part of a continuous development cycle.

En la práctica, el proceso es algo más complicado, como podrá comprobar cuando veamos cada fase con más detalle. Fabrikam, Inc. usa un enfoque diferente para la implementación para cada entorno de destino.

Fabrikam, Inc. uses a different approach to deployment for each target environment.

En lo que resta de este tema se examinan las siguientes fases clave de este ciclo de vida de implementación:

  • Requisitos previos: cómo hay que configurar la infraestructura del servidor antes de poner en marcha la lógica de implementación.
  • Desarrollo e implementación iniciales: qué hay que hacer antes de implementar la solución por primera vez.
  • Implementación para prueba: cómo empaquetar e implementar contenido en un entorno de prueba automáticamente cuando un desarrollador registra código nuevo.
  • Implementación para ensayo: cómo implementar compilaciones específicas en un entorno de ensayo y cómo realizar implementaciones "what if" para garantizar que una implementación no va a causar ningún problema.
  • Implementación para producción: cómo importar paquetes web a un entorno de producción cuando la infraestructura de red impide la implementación remota.

Requisitos previos

La primera tarea de cualquier escenario de implementación es asegurarse de que la infraestructura del servidor cumple los requisitos de las herramientas y técnicas de implementación. En este caso, Fabrikam, Inc. ha configurado su infraestructura de servidor del siguiente modo:

Desarrollo e implementación iniciales

Antes de que el equipo de desarrollo de Fabrikam, Inc. pueda implementar la solución Contact Manager por primera vez, debe realizar estas tareas:

  • Crear un nuevo proyecto de equipo
  • Crear los archivos de proyecto de Microsoft Build Engine (MSBuild) que contienen la lógica de implementación
  • Crear las definiciones de compilación de TFS que activan los procesos de implementación

Crear un nuevo proyecto de equipo

Crear la lógica de implementación

Matt Hink crea varios archivos de proyecto de MSBuild personalizados mediante el enfoque de archivos de proyecto divididos descrito en Descripción del archivo de proyecto. Matt crea lo siguiente:

  • Un archivo de proyecto denominado Publish.proj que ejecuta el proceso de implementación. Este archivo contiene destinos de MSBuild que compilan los proyectos en la solución, crean paquetes web e implementan los paquetes en un entorno de servidor de destino.
  • Archivos de proyecto específicos del entorno denominados Env-Dev.proj y Env-Stage.proj. Contienen configuraciones específicas del entorno de prueba y del entorno de ensayo respectivamente, como las cadenas de conexión, los puntos de conexión de servicio y detalles del servicio remoto que recibirá el paquete web. Para obtener instrucciones sobre cómo elegir la configuración adecuada para entornos de destino específicos, consulte Configurar propiedades de implementación para un entorno de destino.

Para ejecutar la implementación, un usuario ejecuta el archivo Publish.proj usando MSBuild o Team Build, y especifica la ubicación del archivo de proyecto específico del entorno correspondiente (Env-Dev.proj o Env-Stage.proj) como argumento de línea de comandos. A continuación, el archivo Publish.proj importa el archivo de proyecto específico del entorno para crear un conjunto completo de instrucciones de publicación para cada entorno de destino.

Nota:

La forma en que funcionan estos archivos de proyecto personalizados es independiente del mecanismo que se usa para invocar MSBuild. Por ejemplo, puede usar directamente la línea de comandos de MSBuild, como se describe en Descripción del archivo de proyecto. Puede ejecutar los archivos de proyecto desde un archivo de comandos, como se describe en Crear y ejecutar un archivo de comandos de implementación. Como alternativa, puede ejecutar los archivos de proyecto desde una definición de compilación en TFS, como se describe en Crear una definición de compilación que admita la implementación.
En cada caso, el resultado final es el mismo: MSBuild ejecuta el archivo de proyecto combinado e implementa la solución en el entorno de destino. Esto proporciona una gran flexibilidad a la hora de activar el proceso de publicación.

Una vez creados los archivos de proyecto personalizados, Matt los agrega a una carpeta de solución y los registra en el control de código fuente.

Crear definiciones de compilación

Como última tarea de preparación, Matt y Rob trabajan juntos para crear tres definiciones de compilación para el nuevo proyecto de equipo:

  • DeployToTest. Esto compila la solución Contact Manager y la implementa en el entorno de prueba cada vez que se produce un registro.
  • DeployToStaging. Esto implementa los recursos de una compilación anterior especificada en el entorno de ensayo cuando un desarrollador pone en cola la compilación.
  • DeployToStaging-WhatIf. Esto realiza una implementación "what if" en el entorno de ensayo cuando un desarrollador pone en cola la compilación.

Las secciones siguientes contienen más detalles sobre cada una de estas definiciones de compilación.

Implementación para prueba

El equipo de desarrollo de Fabrikam, Inc. mantiene entornos de prueba para llevar a cabo diferentes actividades de pruebas de software, como comprobaciones y validaciones, pruebas de facilidad de uso, pruebas de compatibilidad y pruebas ad hoc o exploratorias.

El equipo de desarrollo ha creado una definición de compilación en TFS denominada DeployToTest. Esta definición de compilación usa un desencadenador de integración continua, lo que significa que el proceso de compilación se ejecuta cada vez que un miembro del equipo de desarrollo de Fabrikam, Inc. registra algo. Cuando se activa una compilación, la definición de compilación hará lo siguiente:

  • Compilar la solución ContactManager.sln (lo que, a su vez, compila todos los proyectos dentro de la solución)
  • Ejecutar pruebas unitarias en la estructura de carpetas de la solución (si la solución se compila correctamente)
  • Ejecutar los archivos de proyecto personalizados que controlan el proceso de implementación (si la solución se compila correctamente y supera las pruebas unitarias)

El resultado final es que si la solución se compila correctamente y supera las pruebas unitarias, los paquetes web y cualquier otro recurso de implementación se implementan en el entorno de prueba.

The end result is that if the solution builds successfully and passes unit tests, the web packages and any other deployment resources are deployed to the test environment.

¿Cómo funciona el proceso de implementación?

La definición de compilación DeployToTest proporciona estos argumentos a MSBuild:

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

Las propiedades DeployOnBuild=true y DeployTarget=package se usan cuando Team Build compila los proyectos dentro de la solución. Cuando el proyecto es un proyecto de aplicación web, estas propiedades indican a MSBuild que cree un paquete de implementación web para el proyecto. La propiedad TargetEnvPropsFile indica al archivo Publish.proj dónde buscar el archivo de proyecto específico del entorno que se va a importar.

Nota:

Para ver un tutorial detallado sobre cómo crear una definición de compilación como esta, consulte Crear una definición de compilación que admita la implementación.

El archivo Publish.proj contiene destinos que compilan cada proyecto en la solución. Sin embargo, también incluye lógica condicional que omite estos destinos de compilación si el archivo se ejecuta en Team Build. Esto permite aprovechar la funcionalidad de compilación adicional que ofrece Team Build, como la posibilidad de ejecutar pruebas unitarias. Si se produce un error en la compilación de la solución o en las pruebas unitarias, el archivo Publish.proj no se ejecutará y la aplicación no se implementará.

La lógica condicional se logra evaluando la propiedad BuildingInTeamBuild. Se trata de una propiedad de MSBuild que se establece automáticamente en true cuando se usa Team Build para compilar los proyectos.

Implementación para ensayo

Cuando una compilación cumple todos los requisitos del equipo de desarrolladores en el entorno de prueba, es posible que el equipo quiera implementar la misma compilación en un entorno de ensayo. Normalmente, los entornos de ensayo se configuran para que coincidan lo más posible con las características del entorno de producción o "activo", por ejemplo, en términos de especificaciones del servidor, sistemas operativos y software y configuración de red. Los entornos de ensayo se suelen usar para pruebas de carga, pruebas de aceptación de usuario y revisiones internas de alcance más amplio. Las compilaciones se implementan en el entorno de ensayo directamente desde el servidor de compilación.

Builds are deployed to the staging environment directly from the build server.

Las definiciones de compilación usadas para implementar la solución en el entorno de ensayo, DeployToStaging-WhatIf y DeployToStaging, tienen en común estas características:

  • No crean nada realmente. Cuando Rob implementa la solución en el entorno de ensayo, quiere implementar una compilación específica existente que ya se ha comprobado y validado en el entorno de prueba. Las definiciones de compilación solo necesitan ejecutar los archivos de proyecto personalizados que controlan el proceso de implementación.
  • Cuando Rob activa una compilación, usa los parámetros de compilación para especificar qué compilación contiene los recursos que quiere implementar desde el servidor de compilación.
  • Las definiciones de compilación no se activan automáticamente. Rob pone una compilación en cola manualmente cuando quiere implementar la solución en el entorno de ensayo.

Este es el proceso en general de una implementación en el entorno de ensayo:

  1. El administrador del entorno de ensayo, Rob Walters, pone una compilación en cola mediante la definición de compilación DeployToStaging-WhatIf. Rob usa los parámetros de definición de compilación para especificar qué compilación quiere implementar.
  2. La definición de compilación DeployToStaging-WhatIf ejecuta los archivos de proyecto personalizados en modo "what if". Esto genera archivos de registro como si Rob estuviera realizando una implementación activa, pero en realidad no se realiza ningún cambio en el entorno de destino.
  3. Rob revisa los archivos de registro para determinar los efectos de la implementación en el entorno de ensayo. En concreto, Rob quiere comprobar qué se agregará, qué se actualizará y qué se eliminará.
  4. Si Rob está convencido de que la implementación no realizará ningún cambio no deseado en los recursos o datos existentes, pone una compilación en cola mediante la definición de compilación DeployToStaging.
  5. La definición de compilación DeployToStaging ejecuta los archivos de proyecto personalizados. Estos archivos publican los recursos de implementación en el servidor web principal en el entorno de ensayo.
  6. El controlador de Web Farm Framework (WFF) sincroniza los servidores web en el entorno de ensayo. Esto hace que la aplicación esté disponible en todos los servidores web de la granja de servidores.

¿Cómo funciona el proceso de implementación?

La definición de compilación DeployToStaging proporciona estos argumentos a MSBuild:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

La propiedad TargetEnvPropsFile indica al archivo Publish.proj dónde buscar el archivo de proyecto específico del entorno que se va a importar. La propiedad OutputRoot invalida el valor integrado e indica la ubicación de la carpeta de compilación que contiene los recursos que desea implementar. Cuando Rob pone la compilación en cola, usa la pestaña Parámetros para proporcionar un valor actualizado para la propiedad OutputRoot.

When Rob queues the build, he uses the Parameters tab to provide an updated value for the OutputRoot property.

Nota:

Para obtener más información sobre cómo crear una definición de compilación como esta, consulte Implementar una compilación concreta.

La definición de compilación DeployToStaging-WhatIf contiene la misma lógica de implementación que la definición de compilación DeployToStaging, pero incluye el argumento adicional WhatIf=true:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

En el archivo Publish.proj, la propiedad WhatIf indica que todos los recursos de implementación deben publicarse en modo "what if". En otras palabras, los archivos de registro se generan como si la implementación hubiera avanzado, pero en realidad nada ha cambiado en el entorno de destino. Esto permite evaluar el impacto de una implementación propuesta (en particular, lo que se agregará, lo que se actualizará y lo que se eliminará) antes de realizar cambios.

Nota:

Para obtener más información sobre cómo configurar implementaciones "what if", consulte Realizar una implementación "what if".

Una vez implementada la aplicación en el servidor web principal en el entorno de ensayo, WFF la sincronizará automáticamente en todos los servidores de la granja de servidores.

Nota:

Para obtener más información sobre cómo configurar WFF para sincronizar servidores web, consulte Crear una granja de servidores con Web Farm Framework.

Implementación para producción

Cuando se aprueba una compilación en el entorno de ensayo, el equipo de Fabrikam, Inc. puede publicar la aplicación en el entorno de producción. El entorno de producción es donde la aplicación "se activa" y se pone a disposición de los usuarios finales objetivo.

El entorno de producción está en una red perimetral accesible desde Internet. Está aislado de la red interna que contiene el servidor de compilación. La administradora del entorno de producción, Lisa Andrews, debe copiar manualmente los paquetes de implementación web desde el servidor de compilación e importarlos a IIS en el servidor web de producción principal.

The production environment administrator must manually copy the web deployment packages from the build server and import them into I I S on the primary production web server.

Este es el proceso en general de una implementación en el entorno de producción:

  1. El equipo de desarrolladores avisa a Lisa de que hay una compilación lista para su implementación en producción. El equipo indica a Lisa la ubicación de los paquetes de implementación web dentro de la carpeta de entrega del servidor de compilación.
  2. Lisa recopila los paquetes web del servidor de compilación y los copia en el servidor web principal del entorno de producción.
  3. Lisa usa el Administrador de IIS para importar y publicar los paquetes web en el servidor web principal.
  4. El controlador de WFF sincroniza los servidores web en el entorno de producción. Esto hace que la aplicación esté disponible en todos los servidores web de la granja de servidores.

¿Cómo funciona el proceso de implementación?

El Administrador de IIS incluye un asistente para la importación de paquetes de aplicación que facilita la publicación de paquetes web en un sitio web de IIS. Para ver un tutorial sobre cómo realizar este procedimiento, consulte Instalación manual de paquetes web.

Conclusión

En este tema se ha ilustrado el ciclo de vida de implementación de una aplicación web de escala empresarial típica.

Este tema forma parte de una serie de tutoriales con instrucciones sobre diversos aspectos de la implementación de aplicaciones web. En la práctica, hay muchas tareas y consideraciones adicionales en cada fase del proceso de implementación, y no es posible cubrirlas todas en un solo tutorial. Para obtener más información, consulte los siguientes artículos:

Anterior