La plataforma Windows Azure es una colección de servicios basados en la nube para crear y consumir aplicaciones y servicios en la nube. Los componentes clave de la plataforma son:

• Windows Azure – provee computo virtualizado, almacenamiento y gestión para tus aplicaciones basadas en la nube. Microsoft lo define como un sistema operativo en la nube. Provee una abstracción para el hardware repartido en múltiples servidores.
• SQL Azure – provee servicios de base de datos relacionales basados en la nube.
• Azure AppFabric – permite que los desarrolladores conecten aplicaciones y servicios en la nube o de forma interna. Esto incluye aplicaciones que se ejecutan en Windows Azure, Windows Server y una cantidad de distintas plataformas, incluso Java, Ruby, PHP, entre otras.

Nota: Windows Azure, SQL Azure y Windows Azure platform AppFabric son productos diferentes y su utilización se paga por separado. Para más información click aquí.

La plataforma Windows Azure puede ser utilizada por aplicaciones que corren tanto en un entorno local como desde la nube. Por ejemplo, se puede acceder a datos en la nube desde aplicaciones locales, o una aplicación hosteada en la nube puede acceder a las cuentas de usuarios locales.

Windows Azure

Windows Azure provee computo y almacenamiento, como también gestión a través del Windows Azure Developer Portal. Los componentes clave son:

• Servicios de Computo – pedidos de procesamiento. Son instancias de máquinas virtuales (VM) que vienen en dos tipos: Web Roles y Worker Roles. Los Web Roles incluyen Internet Information Services (IIS) y pueden aceptar pedidos HTTP y HTTPS. Worker Roles no vienen configurados con IIS y se utilizan principalmente para procesamiento en segundo plano.
• Servicios de Almacenamiento – almacena datos. Provee blobs, tables y queues. Blobs (Binary Large Object) y tables son para almacenar y leer datos, pero queues (filas) se usan principalmente para que instancias de Web Roles se comuniquen con instancias Worker Roles en forma asíncrona.
• Fabric – consiste de un (gran) grupo de máquinas. Todas las máquinas son controladas por el Fabric Controller. El Fabric Controller está encargado de monitorear todas las aplicaciones que están corriendo, gestiona las Windows Azure VMs, y decide en qué servidores correr nuevas aplicaciones, optimizando la utilización del hardware.

Al desarrollar una aplicación Windows Azure, la primer gran diferencia que se encuentra es la falta de estados (stateless). No se puede utilizar Session en una aplicación web, por ejemplo. Para guardar estados, debemos recurrir a un blob típicamente. Esto es debido a que Microsoft no garantiza en qué servidor va a estar corriendo nuestra aplicación, y tampoco garantiza que va a seguir corriendo en el servidor en el cual comenzó a correr. En cualquier momento podría caerse el servidor en el cual nuestra aplicación se ejecutaba, y automáticamente otro servidor en el Fabric levantará una VM nueva para correr la aplicación.

Además, al crear un Role (worker o web), se debe crear una clase que herede de RoleEntryPoint. Esta clase contiene 3 métodos importantes:

• OnStart(): Es llamado por el Fabric al comienzo, y te permite realizar alguna tarea de inicialización.
• OnStop(): Es llamado cuando el rol es detenido. Te permite realizar cualquier tarea final antes de detenerse el rol. Un rol puede detenerse porque el Fabric decidió cambiarlo de servidor, o fue solicitado desde el portal web manualmente.
• Run(): La lógica principal va aquí. Puede ser cualquier cosa, normalmente es un loop que nunca termina.

Depende de uno decidir nunca hacer return una vez que el rol comenzó a correr, hasta que se indique que debe detenerse. De todas formas, no es necesario manejar el evento de detención, simplemente puede “fallar” sin problemas.

Finalmente, todos los archivos de un proyecto son estáticos (read only). Si se necesita cambiar el contenido de los archivos, se debe utilizar el servicio de almacenamiento (blobs), o si es configuración, en lugar de utilizar el Web.Config, usar los archivos del Service Model (ServiceConfiguration.cscfg), los cuales pueden ser cambiados sin necesidad de re-compilar.

Para más información, ver Windows Azure Platform Whitepapers.

SQL Azure

SQL Azure provee servicios de bases de datos relacionales en la nube. El principal componente es una SQL Azure Database. Por el momento es el único componente, pero Microsoft promete otros servicios para el futuro.

• SQL Azure Database – servicio de base de datos relacional basado en Microsoft SQL Server. Una aplicación que utilice SQL Azure ve un entorno familiar al SQL Server, aunque algunos aspectos fueron omitidos en el primer release. Se puede acceder utilizando el protocolo TDS (Tabular Data Stream), lo que significa que se puede utilizar ADO.NET y otras librerías familiares.

Ver SQL Azure (MSDN) para más información.

AppFabric

El objetivo de Windows Azure platform AppFabric (antes denominado “.NET Services”), es proveer un servicio que facilite las conexiones entre aplicaciones que corren en la nube o localmente. Los componentes clave son:

• Service Bus – facilita realizar conexiones entre aplicaciones a través de internet. Un servicio puede registrar uno o más endpoints con Service Bus. Por cada uno de ellos, Service Bus expone un endpoint, y asigna a la organización una URI raíz. Cuando una aplicación desea conectarse a este servicio, contacta al registro del Service Bus para buscar el endpoint. Service Bus devuelve un documento AtomPub, y el cliente invoca las operaciones expuestas en estos endpoints. Por cada solicitud que Service Bus recibe, invoca a la correspondiente operación en el endpoint expuesto por tu servicio. Además de facilitar la comunicación, Service Bus también puede mejorar la seguridad. Debido a que ahora los clientes ven una IP de Service Bus, no hay necesidad de exponer una dirección IP desde dentro de la organización. Service Bus soporta REST, HTTP y HTTPS.
• Access Control – provee autenticación y autorización a través de tokens y claims. Actualmente, un cliente se puede identificar utilizando REST. (Microsoft dice que en el futuro ampliará el rol del servicio, agregando soporte para servicios basados en SOAP, etc)

Ver AppFabric Service Bus (MSDN) y AppFabric Access Control (MSDN) para más información.

En el tiempo que llevamos trabajando en consultoría relacionada con TFS, y en particular con lo concerniente al Source Control, nos hemos encontrado con dos tipos de casos:

• Empresas que no aprovechan los beneficios aportados por el branching.
• Empresas que hacen abuso del branching, que también pierden esos mismos beneficios y terminan siendo devorados por el monstruo.

Los primeros no quieren ni hacer mención al branching por simple temor a lo desconocido, pero en cuanto vencen ese primer miedo y obtienen los primeros buenos resultados, se convierten automáticamente en los de la segunda clase, casi sin término medio.

Los segundos vuelven a convertirse en los primeros por abandono.

Con este post me propongo  hacer una introducción a las políticas de branches, para que ambos grupos puedan lograr el equilibrio.

Branching Guidance

En gran parte de los casos con los que me he cruzado, el caos viene de la mano de la falta de políticas de branches. Casi como la planificación previa de la arquitectura de cualquier aplicación, los branches necesitan ser diagramados y consensuados de antemano.

Desde hace varios años ya, está publicada en Codeplex lo que se conoce como “Branching Guidance” sobre la cual estoy basando este post. Hoy la guía se encuentra en su versión 2.0 a raíz del feedback recibido desde la comunidad y recientemente fue publicado el Release 2010, obviamente apuntando al lanzamiento de la nueva versión de la plataforma.

En esa guía hay una frase a modo de advertencia que me gustaría transcribir:

Cada branch que se crea tiene un costo, por lo tanto asegúrese de obtener algún valor de él.

Creo que esta frase resume perfectamente el concepto de equilibrio al que hacía referencia  anteriormente, y al punto al que deberían llegar las empresas que decidan apostar por una política de branches.

Apostando a una política de branches

El uso de branching requiere ordenamiento, y por tal motivo voy a enumerar algunos principios que se deberán tener en cuenta antes de meter mano:

• El encargado de ejecutar y mantener la política de branches que se defina, deberá tener un nivel medio-avanzado en el manejo de TFS. (“Cada branch tiene un costo …”).
• La política que se defina dependerá fuertemente de los tipos de Release (release de nueva versión, de service pack, de hot fix, etc.) requeridos por el proyecto en cuestión, de lo que se desprende:
  • Se pueden definir diferentes tipos de políticas para diferentes tipos de proyecto.
  • A menor cantidad de tipos de release, un plan de branching más simple.

Los planes de branching sugeridos en la guía tienen una característica “aditiva” lo que permite elegir en primera instancia un plan simple, y en caso de que aparezcan nuevos tipos de release (conocidos como release vehicles, ver Glosario) ir “complicando” el plan agregando nuevos branches.

Un plan equilibrado – El “Standard Branch Plan”

Imaginemos un escenario con las siguientes características:

• Se desarrolla un producto del cual el cliente siempre tiene la última versión.
• Se desarrollan permanentemente nuevas versiones con nuevos features (un release vehicle por aquí).
• Se entregan además actualizaciones (services packs, bug fixes, otro release vehicle por aca).
• Cada actualización liberada sobre una determinada versión contiene todas las actualizaciones anteriores.
• Los services packs se desarrollan paralelamente a los features de la nueva versión.

Dado este escenario, un plan de branches como el que muestro a continuación permitiría soportar las necesidades del proyecto a la vez que mantendría una cantidad de branches controlada, fuera de una situación de caos.

Qué propone este plan:

• Branch Development:
  • Sobre él se desarrollan los features de la próxima versión.
  • Existe un flujo continuo desde y hacia el branch Main (merges).
  • Merge hacia Main (RI) ante cada objetivo cumplido, por ejemplo el fin de una iteración.
  • Merge desde Main (FI) cada vez que Main genera un build exitoso.
• Branch Service Pack:
  • Se crea en el mismo instante que Release, determinando en ese momento la jerarquía Main –> Service Pack –> Release.
  • Los cambios “de servicio” se hacen sobre esta rama y luego se hace merge (RI) sólo hacia Main.
• Branch Release:
  • Es hijo de Service Pack.
  • La entrega al cliente se hace desde este branch, y una vez que se libera, el branch se marca como read-only.
  • Bug fixes graves, que se hagan sobre el branch Release, deben hacer merge hacia Main pero pasando por el branch Service Pack (Release –> Service Pack –> Main)
  • Una vez que se creó este branch, los cambios que no fueron aprobados para el Release en curso sólo deberían hacerse en Main.

Herramientas de TFS

Con el lanzamiento de TFS 2010, se agregaron nuevas ventajas que facilitarán la vida del desarrollador que se encuentre con la difícil tarea de hacer los merges al momento de incorporar cambios a los diferentes branches, entre los que tenemos:

Visualización gráfica de la jerarquía de branches …

y visualización gráfica de los merges a los diferentes branches (incluye línea de tiempo …)

Con esta última mejora, podremos saber si un determinado cambio fue incorporado a un branch que lo requiera (si no se hubiera hecho el merge, el branch se vería en color rojo), y además, podemos saber en qué fecha y con qué changeset fue realizado.

Conclusión

Lograr equilibrios no es sencillo, pero los beneficios pueden ser muchos.

Invertir tiempo en la planificación y el mantenimiento de una política de branches que cubra nuestras necesidades pero que a la vez no se descontrole puede no ser fácil, pero seguramente permitirá reducir llamados de nuestros clientes enviando saludos a nuestras hermanas, madres y abuelas porque la entrega de la última versión, con aquellos fantásticos nuevos features, revivió bugs que habían sido ya solucionados.

Glosario