Integración Continua – Parte 2

Anteriormente vimos como podemos utilizar las transformaciones XML para manejar diferentes configuraciones en nuestras aplicaciones. Pero existe un problema con estas transformaciones: solo se realizan cuando publicamos o creamos un paquete de despliegue.

Esto impide los siguientes escenarios:

  • Aprovechar las configuraciones al momento de probar nuestra aplicación desde el mismo VS utilizando F5.
  • Utilizas las configuraciones desde diferentes proyectos para realizar pruebas de integración en diferentes ambientes utilizando alguna herramienta de testing.

Por suerte existe la capacidad de poder utilizar las transformaciones de manera independiente a una publicación, esto es posible gracias al task “TransformXML” de MsBuild.

    <TransformXml Source="{Source File}" 
                 
Transform="{Transform File}"
 
                 
Destination="{Destination File}"
/>

El inconveniente con este task es que el “source file” y el “destination file” no pueden ser el mismo archivo Web.config. Esta dificultad la podemos solucionar si organizamos nuestros archivos de una manera diferente.

Para esto copiamos el archivo Web.config y a este nuevo archivo le cambiamos de nombre a Web.Template.config.

image

Editamos nuestro archivo de proyecto.image

Y modificamos la sección donde se encuentran nuestros archivos config a lo siguiente.

  <ItemGroup>
    <
None Include="Web.Template.config"
/>
    <
Content Include="Web.config"
>
      <
DependentUpon>Web.Template.config</DependentUpon
>
    </
Content
>
    <
None Include="Web.Development.config"
>
      <
DependentUpon>Web.Template.config</DependentUpon
>
    </
None
>
    <
None Include="Web.ContinuousIntegration.config"
>
      <
DependentUpon>Web.Template.config</DependentUpon
>
    </
None
>
    <
None Include="Web.Production.config"
>
      <
DependentUpon>Web.Template.config</DependentUpon
>
    </
None
>
  </
ItemGroup
>

De esta manera le indicamos al VS que agrupe todos nuestros archivos config dentro del Web.Template.config. Asimismo utilizamos el nodo Content únicamente en el Web.config para que todos los demás archivos se borren al momento de realizar una publicación.

Para lograr que la transformación se realice siempre e inmediatamente después de la compilación, descomentamos el target “AfterBuild” e incluimos dentro el task “TransformXML”.

  <Target Name="AfterBuild">
    <
TransformXml Source="Web.Template.config"
 
                 
Transform="Web.$(Configuration).config"
 
                 
Destination="Web.config"
/>
  </
Target
>

Con esto el VS siempre que compile realizará una transformación utilizando el Web,Template.config como origen, utilizará el archivo de transformación correspondiente de acuerdo a nuestra configuración y dará como resultado un archivo Web.config.

Ahora que nuestra transformación se ejecuta al momento de compilar tenemos que evitarla al momento de publicar.

  <PropertyGroup>
    <
TransformWebConfigEnabled>False</TransformWebConfigEnabled
>
  </
PropertyGroup
>

Para finalizar y poder utilizar el task “TransformXml” lo importamos desde la instalación del VS.

  <UsingTask TaskName="TransformXml" 
            
AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"
/>

Grabamos y cargamos nuevamente nuestro proyecto.

image

Para probar la transformación simplemente cambiamos de configuración.

image

Compilamos y al finalizar veremos que el contenido del Web.config ha sido el resultado de una transformación.

image

Resumen

Las transformaciones facilitan el manejo de múltiples configuraciones, pero existen algunos escenarios en los cuales necesitamos que estas no solo se realicen al momento de publicar. Utilizando los pasos anteriores podemos aprovechar las transformaciones también al momento de compilar y sin afectar la publicación.

Lo que se viene

En los siguientes post veremos como aprovechar estas transformaciones para realizar tareas más complejas utilizando MsBuild.

Saludos
Angel Núñez Salazar

Integración Continua - Parte 1

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:

image

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:

image

Ahora lo que tenemos que hacer es producir un nuevo Web.config por cada configuración diferente.

image

Y nos dará como resultado

image

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.

image

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.image

Y desde el VS publicaremos la aplicación a un directorio local.

image

image

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).

image

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

Taller de ASP.NET MVC

Tengo el agrado de contarles la apertura del taller de ASP.NET MVC, donde podrán aprender el uso y la aplicación de esta gran tecnología.

Debido a varias sugerencias hemos decidido mover el inicio al 8 de enero ya que diciembre es un poco difícil para algunos y así nadie pueda perderse el taller.

El precio final se establecerá de acuerdo al número total de inscritos, así que inviten a sus amigos y compañeros de trabajo.

Pueden registrar su interés aquí: Taller ASP.NET MVC
No se pierdan esta gran oportunidad.

Saludos
Angel Núñez Salazar

Presentación Spring.NET

Este 27 de noviembre se realizó el Spring Community Day 2010 en el cuál estuve dando una presentación sobre Spring.NET.

El código de la presentación lo podemos descargar desde GoogleCode con nuestro cliente de subversion favorito.
https://springperu.googlecode.com/svn/trunk/scd2010/spring-net

El evento fue totalmente orientado a gente Javera así que fue una presentación difícil de dar.

La presentación fue puramente código(desarrollo casi desde cero de una aplicación web con ASP.NET MVC y Spring). Esto resultó muy beneficioso para los que tenían experiencia en esta framework y así se dieran una idea de su uso en el mundo NET, pero creo que también fue muy complicada para los recién iniciados.

spring.net

Saludos
Angel Núñez Salazar

¿Realmente sabes Refactorizar?

Primero definamos algunos conceptos:

  • Smell: Indicador de que algo podría estar mal en nuestro código ( mal diseño, responsabilidades incorrectas, etc).
    El lugar donde no queremos estar.
  • Refactoring: Cambios a la estructura interna del software con la finalidad de mejorarla y sin que se haya visto afectado su comportamiento.
    El camino hacia…
  • Pattern: Solución reutilizable a un problema que se presenta de manera común en el diseño de software.
    El lugar donde queremos estar.

Para cada uno de estos existen catálogos con listas innumerables, pero lo que no encontramos fácilmente es como aplicarlos correctamente. En este post nos vamos a enfocar en Refactoring y en algunas estrategias para su aplicación.

Las dos estrategias que veremos son: Paralell Change y Narrowed Change. Entonces, para que gastar más líneas si podemos verlo en el siguiente video:


Te recomiendo verlo en HD para una mejor calidad.

Para comprender cuál es la finalidad de todo esto les recomiendo ver “The Limited Red Society” del gran Joshua Kerievsky.

No se olviden de practicar sus refactorings y hasta el siguiente Post.
Saludos

Ágiles 2010: 3ras Jornadas Latinoamericanas sobre Metodologías Ágiles

Ágiles 2010 es una excelente oportunidad para encontrase con profesionales de IT de la región, interesados en compartir sus experiencias, debatir y capacitarse en temas relacionados con el desarrollo de software a través del uso de metodologías ágiles.

Esta tercera edición, con sede en la ciudad de Lima, Perú, contará con la presencia de especialistas locales e internacionales, quienes compartirán su conocimiento durante los cuatro días que durará el evento.

El programa incluye distintos tipos de actividades: presentaciones, sesiones interactivas, talleres y espacios abiertos de debate.

Entre los invitados internacionales se encuentran los keynote speakers Lee Devin y Joshua Kerievsky, que también estarán brindando cursos durante el evento.

Agiles 2010

¡Inscríbete y se parte de Ágiles 2010!

ASP.NET MVC y otras Yerbas – Parte 7

Como Configurar NHibernate “From Zero to Hero”

Seguramente lo que más confunde cuando alguien va a empezar con NHibernate es la gran cantidad de formas, colores y sabores que existen para integrarlo en la infraestructura y arquitectura de nuestra aplicación. A continuación solo una de ellas:

También pueden verlo en HD.

No se olviden de ver el resto de la serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos

ASP.NET MVC Series

Acá tenemos la lista de posts de la serie ASP.NET MVC y otras Yerbas

Saludos.

ASP.NET MVC y otras Yerbas – Parte 6

Es hora de hablar sobre “Inversion of Control”:

El Problema

image

Qué observamos en el código anterior:

  • La clase SmtpClient está directamente referenciada por la clase HomeController y está última controla su creación, lo que tiene como consecuencia un fuerte acoplamiento entre estas dos clases.
  • La clase HomeController es consciente de la clase SmtClient y su funcionamiento, por lo tanto si alguna vez tenemos que realizar algún cambio sobre el envió de correo: como enviarlo por una cola de mensajes o incluso cambiar por una nueva librería, la clase HomeController se verá afectada.
  • Se dificulta la realización de pruebas sobre la clase HomeController.

La Solución

Si somos capaces de cambiar el control de la creación de la clase SmtpClient a una tercera entidad, podremos ver resuelto nuestro problema. Y esa solución es: Inversion of Control.

Inversion of Control

“Is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to traditional architecture of software”
Wikipedia

Podemos implementar este patrón de 2 maneras distintas:

Dependency Inyeccion

La idea es tener un objeto en el “mundo exterior” que se encargue de proveer o inyectar la implementación adecuada (EmailSender) a la clase listener (HomeController)

image

image

Service Locator

La idea es tener una entidad “dentro de la clase” que conozca cómo obtener la implementación adecuada que esta clase podría necesitar.

image

Ahora veamos cómo estas cosas se utilizan en nuestra aplicación de ejemplo y adicionalmente veremos como podemos configurarla para que levante y ejecute.

También podemos verlo en HD

No se olviden de ver el resto de la serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos

ASP.NET MVC y otras Yerbas – Parte 5

Le llego el turno al Controlador y al Modelo ViewModel.

Para una mejor calidad también podemos verlo en HD.

Controlador.- Es el encargado de recibir y manejar las peticiones realizadas por los usuarios, y mostrar la vista adecuada.

ViewModel.- Es aquí donde viene el dilema. Comúnmente existe el problema en decidir cuál es la “M” dentro de nuestro modelo MVC. Es una entidad ?, un DTO ? , algo más ?.

Para algunos la “M” se refiere a una clase que ha sido diseñada para satisfacer las necesidades específicas de una vista en particular - “ViewModel”. Pero cuales son las razones que nos llevan a optar en utilizar una nueva clase únicamente para una vista, ya que esto supone un mayor esfuerzo (aparentemente):

  • A medida que las vistas se vuelven más complicadas es difícil mantener una sincronización entre las clases del dominio y las necesidades de la vista. Imaginemos una vista con un wizard que envía información sobre el paso al cual quiere ir el usuario, definitivamente no vamos a querer agregar esa información a una entidad del dominio ya que es únicamente de interés de la vista.
  • Muchas veces escribimos lógica innecesaria dentro de una vista, esto se puede representar en algo tan simple como: Html.Hidden(“id”,Model!=null?Model.ID:0) .Debido a que las vistas son difíciles de probar es recomendable mover esta lógica a otra clase que facilite esta tarea.
  • Al utilizar las entidades como “Model”, la vista tendrá conocimiento detallado de parte de dominio, lo cual para algunos puede significar que se daña de cierta manera la estructura y la arquitectura de la aplicación. Creo que esto no es más que otra decisión de diseño y esto lo podemos ver en varias aplicaciones antiguas, en especial aquellas que tienen a la base de datos relacional como centro de la aplicación y utilizan a las “entidades” como simples transmisores de datos. Después de vivir tantos años con estas aplicaciones podemos decir que las bases de datos relacionales no lo son todo en esta vida.

Los siguientes links tienen bastante información de los patrones que podemos utilizar para diseñar un ViewModel y las ventajas y desventajas de estos.

http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
http://blogs.msdn.com/simonince/archive/2010/01/26/view-models-in-asp-net-mvc.aspx

No se olviden de ver el resto de las serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos.