El Problema
La mayoría de los proyectos de software tienen un retraso oculto desde el momento que el equipo dice “terminado” hasta que el software está realmente listo a ser potencialmente puesto en producción.
Una de las causas principales es que la integración del trabajo de todo el equipo se realiza al final de la iteración o inclusive del proyecto, esto ocasiona toda clase de problemas: falta de visibilidad del estado real (valor y calidad), errores en etapas finales el proyecto y excesivo tiempo al integrar el trabajo.
Integración Continua
La “Integración Continua” surge como una práctica en el desarrollo e software que pretende solucionar estos problemas.
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build to detect integration errors as quickly as possible.” - Martin Fowler.
En su forma más simple esta práctica no requiere de herramientas complejas ni nada parecido, nada más se necesita constancia para integrar y verificar que se cumplen los estándares que el equipo establece.
La herramientas existen para simplificar y automatizar las tareas que son difíciles de realizar y que nos consumen mucho tiempo, siéntanse libres de utilizar las herramientas que más prefieran, por mi parte aprovechare esta serie de posts para mostrarles las que a mi me gustan.
Para esto reutilizaremos las fuentes de nuestro proyecto ASP.NET MVC “ThunderJob” que ya hemos estado avanzando anteriormente. Comenzemos!
Web.config Transformations
VS2010 trae una nueva característica que nos permite modificar nuestros archivos web.config (en general cualquier XML) de manera automática y con configuraciones diferentes para los ambientes de nuestra aplicación (desarrollo, test, producción, etc)
Lo que tenemos que hacer es crear los diferentes roles de configuración que va a tener nuestra aplicación, esto lo hacemos mediante el Configuration Manager:
Por defecto tenemos 2 roles: Debug y Release, pero podemos agregar o eliminar los que queramos. Para nuestro ejemplo vamos a modificar los roles de nuestra aplicación MVC de la siguiente manera:
Ahora lo que tenemos que hacer es producir un nuevo Web.config por cada configuración diferente.
Y nos dará como resultado
Si abrimos uno de los archivos generados (Web.Development.config) veremos que solo tiene un pequeño contenido y no todo el Web.config original.
Esto se debe a que las transformaciones del Web.config funcionan sobre un motor de transformaciones XML, el cuál toma el archivo original (Web.config), un archivo de transformación (Web.Development.config) y aplica la reglas que se encuentran en este último para generar un Web.config final.
Existen múltiples tipos transformaciones que podemos utilizar, en este artículo Web Deployment: Web.Config Transformation podremos encontrar información más detallada sobre estas.
Para probar nuestras transformaciones vamos a publicar nuestra aplicación. Para esto primero seleccionamos la configuración que queremos utilizar.
Y desde el VS publicaremos la aplicación a un directorio local.
Al dirigirnos al directorio destino y ver el contenido del archivo Web.config, nos daremos cuenta que el contenido de este ha sido modificado según la transformación correspondiente a nuestra configuración (Web.Development.config).
Resumen
Las nuevas transformaciones XML del VS2010 nos permite un mejor manejo de roles con diferentes propiedades para cada uno de los ambientes donde se vaya a desplegar nuestra aplicación.
Lo que se viene
A continuación veremos cuales son algunas de las limitaciones que tienen estas transformaciones y como podemos superarlas.
No se pierdan esta nueva serie de posts, saludos.
Angel Núñez Salazar
