Transformaciones sobre web.config: una forma de tener organizados los distintos ambientes

En el desarrollo de aplicaciones ASP.NET MVC puede haber un punto algo conflictivo si no lo tratamos con el debido cuidado: el archivo Web.config y las variantes del mismo en relación a los distintos ambientes de ejecución. Son muchos los casos donde se puede apreciar que hay problemas o confusiones asociadas a los cambios que uno debe tener sobre este archivo dependiendo del ambiente en el cual ejecutemos la aplicación.

Aquí es donde entran en juego las transformaciones sobre el Web.config, las cuales son un conjunto de reglas que podemos ir definiendo sobre el mismo. Mediante esas reglas podremos definir qué cambios se deben aplicar para cada ambiente.

Cuando hablamos de ambiente hacemos referencia al propósito del sitio donde se ejecute la aplicación, siendo los más clásicos:

  • Local: nuestra PC, ambiente de desarrollo al 100%
  • Testing: un sitio expuesto (interna o externamente) para hacer pruebas generales
  • Producción: sitio real de ejecución de nuestra aplicación

Dependiendo del proyecto podrán existir algunos más o menos (al menos tendremos el entorno local y el de producción). Para este post vamos a tomar esta configuración como la referencia.

Asumiendo que ya tenemos los perfiles de publicación necesarios para cada ambiente que no sea local, vamos a cada uno de los mismos (ubicados en Properties > PublishProfiles) y haciendo click derecho seleccionamos la opción que nos generará el archivo derivado Web.config para cada ambiente, donde se aplicarán las transformaciones particulares:

TransformacionConfig - AgregarConfig

Leer más »

AppHarbor – Configuraciones de la aplicación y ejecución de tests unitarios

Finalizando la serie de posts sobre AppHarbor, vamos a ver algunos puntos generales sobre esta herramienta, y sobre todo la ejecución de tests unitarios como parte del proceso de integración continua que nos ofrece.

Como vimos en el post inicial de esta serie, una de las cosas que debemos hacer para comenzar a trabajar con AppHarbor es enlazar nuestra aplicación con el repositorio de control de código fuente donde tengamos el código de nuestra aplicación. Esta configuración es el primer paso del proceso de integración continua, ya que luego de esto ante cada vez que se suban cambios al repositorio comenzará descargando el contenido actualizado del mismo.

Una vez finalizado esto, comenzará el proceso de compilación. En el mismo se realizará la descarga de los paquetes NuGet que estemos usando, para luego si realizar la compilación en si del código de la aplicación. Sobre esta tarea AppHarbor nos permitirá elegir dentro de la configuración de la aplicación que configuración de compilación utilizar, lo cual es muy útil cuando tenemos distintas configuraciones para distintos ambientes. Esto será teniedo en cuenta para cuestiones de compilación, pero lo más útil será para aplicar las transformaciones necesarias al archivo Web.config:

AppHarbor - ConfiguracionPublicacion
Selección del perfil de compilación a usar

Leer más »

[Microsoft-Dev-Blog] Azure Web Sites: Usar slots para hacer deploys en forma instantánea

Buenas, como es costumbre les comparto el post que escribí en el blog Microsoft-Dev-Blog.

En el mismo vemos en detalle dos funcionalidades muy interesantes de los sitios web de Azure: Slots y Swap. La verdad es que a medida que iba escribiendo el post me iba sorprendiendo por el funcionamiento que tenía y las soluciones que nos puede llegar a ofrecer.

La idea de los Slots es poder manejar más de un ambiente por sitio web, logrando una organización adecuada.

A su vez, podemos intercambiar el contenido de los slots a través de un Swap. Esto realiza un intercambio en el ruteo de los sitios, permitiendo por ejemplo poner una nueva versión productiva de nuestra aplicación de forma instantánea y sin cortes, a diferencia de los deploys clásicos donde la aplicación puede estar varios minutos abajo – créanme que realmente es así 😉 -.

Una de las nuevas funcionalidades que nos brindan actualmente los sitios web de Azure es crear distintos slots sobre el mismo. Cuando creamos nuestro sitio web en Azure, el mismo será el que ejecute la aplicación final de usuario (lo que normalmente llamamos el sitio de producción).

Si queremos tener mayor cantidad de ambientes sobre el mismo sitio, en el cual podamos realizar pruebas sin modificar la aplicación final de usuario, contamos con la posibilidad de crear distintos slots para cada uno de estos ambientes. De esta forma se produce una equivalencia slot-ambiente, para el cual tendremos tantos como nos sea necesarios; cuanto más compleja sea nuestra aplicación, más slots necesitaremos para su correcta gestión. Azure nos brinda hasta un máximo de 4 slots por sitio web.

A su vez, al tener slots sobre un determinado sitio podremos hacer “Swap” entre ellos. Esta funcionalidad es la clave del planteo de los slots, ya que nos permite realizar un intercambio directo los distintos ambientes de nuestra aplicación sin ningún corte para los usuarios. Sin dudas que esto es algo muy bueno. Dependiendo del tipo de aplicación y los usuarios que tengamos puede resultar muy difícil (y a veces costoso en el impacto que tiene) dar de baja temporalmente nuestra aplicación para realizar una actualización.

Pero, ¿cual es la diferencia entre el Swap y un deploy o publicación tradicional que nos da esta ventaja? La clave está que no Swap no se realizan copias de ningún archivo, que es lo que genera el corte en el uso de la aplicación y la demora, sino que se realiza intercambiando el ruteo en el acceso de los sitios entre los que hagamos Swap, invirtiéndolos. Esto a su vez nos da otra gran ventaja: al realizar el intercambio y poner un slot productivo (por mencionar un caso de ejemplo), en el slot de origen nos queda el sitio que anteriormente estaba en producción, teniéndolo disponible para hacer una vuelta atrás en caso de ser necesaria, con la misma facilidad y sin impacto para el usuario.

Leer el post completo..