VEMN Team Blog

Introducción: tipos de entidades en Entity Framework

Desde la salida de Entity Framework, al generar modelos de entidades, las clases generadas derivan de EntityObject.
Con la salida de la versión 4 de Entity Framework, se incorpora soporte para seleccionar el tipo de entidad de la cual van a derivar nuestras entidades de negocio: a los clásicos EntityObject se agregan como novedad POCO, POCO Proxies y Self-Tracking entities.
Antes de desarrollar las entidades de tipo Self-Tracking (el objetivo de este artículo), es conveniente dar un panorama de estos diferentes tipos de entidades, para poder decidir cual utilizar, dependiendo de la arquitectura de la aplicación a realizar:

• EntityObject

Por defecto, las herramientas de ADO.NET Entity Data Model generan tipos de entidades que derivan de EntityObject. En este caso, el ObjectContext administra las relaciones entre los objetos, mantiene el historial de los cambios que ocurren (Change-Tracking) y soporta Lazy Loading.

Sin embargo, este tipo de entidades dependen fuertemente del Entity Framework. Si se desea trabajar con arquitecturas que no conocen la forma de persistencia (por ejemplo: TDD, Test-Driven Development), lo más deseable es utilizar entidades de tipo POCO o POCO Proxy.

• POCO

Entity Framework permite utilizar objetos del dominio existentes junto con el modelo de datos, sin hacer cambios a las clases de datos. Estas clases POCO ("Plain-Old" CLR Objects), son conocidas como objetos que ignoran la persistencia y soportan las mismas funcionalidades de Query, Insert, Update y Delete que los objetos EntityObject.

Al trabajar con entidades POCO, los cambios que se realicen al grafo de objetos no son mantenidos automáticamente por Entity Framework a medida que ocurren, sino que se utiliza un mecanismo de snapshots para detectarlos: se debe llamar a DetectChanges para sincronizar el ObjectContext con el grafo actualizado (por defecto, el ObjectContext llama a este método antes de grabar los datos).

Este mecanismo utiliza mas memoria que el anterior y puede afectar la performance, especialmente si la aplicación requiere la detección de cambios frecuentemente. Para poder tener una notificación instantánea de los cambios, se debe activar la creación de objetos Change-Tracking Proxy, y para activar Lazy Loading se debe activar la creación de Proxies de Lazy Loading.

• POCO Proxy

Se debe utilizar en los casos en los que se requiera detección de cambios instantánea y Lazy Loading. Al utilizarlo, se tiene la misma funcionalidad que con entidades tipo EntityObject, pero con las clases del dominio separadas del Entity Framework. Los proxies se crean en tiempo de ejecución, lo que implica que las entidades generadas difieren del tipo POCO, introduciendo algunas complicaciones con la serialización. Por otra parte, la creación de proxies consume mas recursos que los objetos POCO.

• Self-Tracking Entities

Los tres tipos definidos anteriormente funcionan correctamente en aplicaciones donde los objetos pueden ser agregados (Attach) al ObjectContext que maneja el historial de cambios. Sin embargo, cuando se desea transferir un grafo de entidades a una capa donde el ObjectContext no está disponible, se debe decidir como mantener el historial de cambios y reportar esos cambios de vuelta al ObjectContext (por ejemplo: arquitectura en capas, ambientes desconectados, arquitecturas SOA, etc.).

A partir de la versión 4 de Entity Framework, las entidades del tipo Self-Tracking pueden grabar cambios a las propiedades escalares, complejas o de navegación. Este tipo de entidades no dependen del Entity Framework, y son generadas con el template de ADO.NET Self-Tracking Entity Generator.

Self-Tracking Entities

En arquitecturas en capas, el ObjectContext puede no estar disponible en la capa que modifica las entidades. A partir de Visual Studio 2010 (con Entity Framework 4), está disponible el template ADO.NET Self-Tracking Entity Generator. Este template genera dos archivos .tt (text template):

El archivo <nombreModelo>.tt genera los tipos de entidades y una clase helper que contiene la lógica de mantenimiento de cambios, mas los métodos de extensión que permiten establecer el estado de las entidades.

El archivo <nombreModelo>.Context.tt genera un ObjectContext tipado y una clase de extensión que contiene los métodos ApplyChanges para las clases ObjectContext y ObjectSet. Estos métodos examinan la información del historial de cambios para inferir las operaciones a realizar para grabar los cambios en la base de datos.

Para acceder al template se debe hacer click derecho sobre la superficie del diseñador de entidades, y seleccionar “Add Code Generation Item”:

En la ventana que aparece, seleccionar “ADO.NET Self-Tracking Entity Generator”:

Al presionar “Add”, se ejecutarán los templates que crearán las clases necesarias, las cuales contendrán los métodos de extensión necesarios para trabajar con Self-Tracking:

Métodos de extensión de Self-Tracking Entities

• StartTracking

Este método se utiliza para comenzar el Change-Tracking (rastrear cualquier cambio que ocurra en la entidad). Esto incluye propiedades escalares, colecciones y referencias a otras entidades. Las entidades de tipo Self-Tracking inician el Change-Tracking automáticamente cuando son deserializadas en un cliente a través de WCF. También se activa para nuevas entidades creadas en los siguientes escenarios:

1. Una relación es creada entre la nueva entidad y una entidad que actualmente tiene Change-Tracking activado.
2. Se llama al método MarkAs o AcceptChanges en una entidad.

• StopTracking

Este método finaliza el Change-Tracking en una entidad.

• MarkAs

Todos los métodos que comienzan con “MarkAs” activan el Change-Tracking. Estos métodos permiten cambiar el estado de una entidad a Added, Modified, Deleted, o Unchanged, y además retornan la misma entidad a la cual son aplicados, con el estado modificado:

MarkAsAdded cambia el estado de una entidad a Added. Las nuevas entidades Self-Tracking son creadas en este estado y con Change-Tracking desactivado.

MarkAsDeleted cambia el estado de una entidad a Deleted.

MarkAsModified cambia el estado de una entidad a Modified. Este estado también se obtiene al cambiar el valor de una propiedad en una entidad con Change-Tracking activado.

MarkAsUnchanged cambia el estado de una entidad a Unchanged. También se obtiene este estado al llamar al método AcceptChanges.

• AcceptChanges

Este método elimina la información de Change-Tracking para una entidad y coloca el estado en Unchanged (es decir, la entidad acepta los cambios que se le realizaron).

Métodos de extensión de ObjectContext

• ApplyChanges

Examina la información del historial de cambios contenida en el grafo de entidades e infiere el conjunto de operaciones que deben realizarse para reflejar los cambios en la base de datos. Hay dos métodos ApplyChanges, uno para el ObjectContext y otro para el ObjectSet.

Consideraciones para trabajar con entidades Self-Tracking

Finalmente, para cerrar, les dejo algunas consideraciones a tener muy en cuenta antes de utilizar este tipo de entidades:

• Al enviar un grafo modificado a un servicio, y luego intentar continuar trabajando con el el grafo modificado en el cliente, se debe iterar manualmente por el grafo en el cliente y llamar a AcceptChanges en cada objeto para resetear el Change-Tracking.

• Las entidades Self-Tracking no permiten realizar Lazy Loading.

• La serialización Binaria y la serialización a objetos de administración de estados ASP.NET no es soportada por el código generado por los templates de ADO.NET Self-Tracking Entity Generator, para soportala se debe agregar el código necesario al template.

Fuentes:

• http://msdn.microsoft.com/en-us/library/bb738470.aspx
• http://msdn.microsoft.com/en-us/library/ff407090.aspx
• http://msdn.microsoft.com/en-us/library/ee789839.aspx

ADO.NET, Entity Framework, Visual Studio ado.net, ef

Dónde quedan los reportes de TFS2008 cuando se realiza la migración a TFS 2010?

A no preocuparse si acceden a los viejos reportes y ven que la fecha de actualización del cubo quedó congelada a la fecha de la migración, porque los reportes están ahora en una nueva locación

Por los cambios producidos en los modelos en la nueva version 2010, el proceso de actualización que realiza TFS hace que se instalen las nuevas bases de datos y cubos siguiendo el concepto de Project Collections (ver http://www.vemn.com.ar/Blog/post/Nuevos-conceptos-en-TFS-2010.aspx)

Las bases anteriores TFSWarehouse y al cubo también llamado de la misma manera siguen existiendo y los reportes en Reporting Services (SSRS) siguen apuntando a esta base .

Pero los reportes para los templates basados en MSF for Agile y MSF for CMMI en la versión 4.2 son migrados a un nuevo directorio en Reporting Services. Este directorio se llama TFSReports y dentro de él está el directorio DefaultCollections (esto dependiendo del nombre de la collection que fué creada en la migración). Dentro de este último directorio vamos a encontrar todos los reportes de los proyectos anteriores migrados a la nueva versión 2010 de TFS.

Por supuesto, que todos los proyectos abiertos desde Visual Studio, apuntan ahora a la nueva ubicación. Esta ubicación es sacada desde la consola de configuración de TFS.

En el gráfico siguiente, está un esquema de como quedan ahora las bases de datos y los Data Sources de Reporting Services

Tambien tenemos nuevos Data Sources

Aquí les dejo una serie de link sobre información puntual sobre el tema de reportes (algunos extraidos del blog de Buck Hodges:

Sunder Raman, Program Manager para TFS, ha escrito una serie de post (en inglés) sobre los cambios en el almacenamiento y en los cubos para 2010.

Reporting

• Reporting in Team Foundation Server 2010 – Part 1: Introduction
• Reporting in Team Foundation Server 2010 – Part 2: SharePoint Dashboards: SharePoint Server dashboard
• Reporting in Team Foundation Server 2010 – Part 3: SharePoint Dashboards: SharePoint Server dashboard customization
• Reporting in Team Foundation Server 2010 – Part 4: SharePoint Dashboards: Creating a team dashboard
• Reporting in Team Foundation Server 2010 - Part 5: SharePoint Foundation Dashboard
• Reporting in Team Foundation Server 2010 - Part 6: Rich SQL Reporting Services Reports
• Reporting in Team Foundation Server – Part 7: Excel Reports from Work Item Queries
• Reporting in Team Foundation Server 2010 – Part 8: Custom Reports: Options & Tools

Customizing Reports for Team Foundation Server 2010 (en MSDN)

Cube

• Team Foundation Server 2010 – Cube Schema Changes in Beta 2
• Team Foundation Server 2010 – Cube Schema Changes in RTM

John Socha-Leialoha, escribió una serie de post sobre la actualización de reportes en TFS

• Upgrading Team Foundation Server 2008 Reports to 2010, Part I (originally written for beta 1 - part 2 describes changes between beta 1 and beta 2)
• Upgrading Team Foundation Server 2008 Reports to 2010, Part II
• Upgrading Team Foundation Server 2008 Reports to 2010, Part III

ALM, Gestión de Proyectos, TFS alm, Team Foundation Server, Gestión de Proyectos

Si es necesario hacer backup o restore de las bases de datos, o mover una instalación o hacer cambios importantes, es útil contar un algo que nos permita con un solo comando parar o arrancar todos los servicios que usa Team Foundation Server.

Hay una herramienta de linea de comandos  que se llama TFSServiceControl que permite realizar esas operaciones con todos los servicios,  y los Application Pools que usa el Team Foundation Server.

El comando se usa:

TFSServiceControl [quiesce|unquiesce]

TFSServiceControl quiesce Detiene los servicios

TFSServiceControl unquiesce Inicia los servicios

Fuente (en inglés) : http://msdn.microsoft.com/en-us/library/ff470382.aspx

ALM, Gestión de Proyectos, TFS Team Foundation Server, TFS 2010

Siguiendo con nuestra idea de mostrar novedades que exceden la calificación de “nueva característica”, y que nos ponen en situación de repensar algunas situaciones, quisiera comentar sobre las Categorías de Work Items.

Ahora, con TFS 2010, podemos categorizar Work Items, pero … ¿por qué querríamos o necesitaríamos hacer esto?.

Porque tendríamos la posibilidad de tratar de la misma manera a aquellos work items que son diferentes pero parecidos, teniendo en cuenta que cuando hablo de “tratar” estoy apuntando al seguimiento de esos work items. Con este nuevo agrupamiento podríamos por ejemplo:

• Construir queries, con una sintaxis mucho más simple e intuitiva, que devuelvan work items de más de un tipo. ¿O acaso una “User Story” y un “Quality of Service Requirement” no son en definitiva requerimientos del usuario?
• Construir reportes de manera más simple apuntando a obtener resultados más “macro” sin resignarnos a perder el detalle de lo que hay debajo (… o ver el bosque y también ver los árboles). Cada work item tendrá su propia estructura de datos, con el nivel de detalle que requiera cada uno, pero aquella información que tengan en común podría ser explotada en reportes utilizando estas nuevas categorías.
• Construir Test Suites utilizando Microsoft Test Manager (el nuevo integrante de la familia TFS, del que estaremos posteando/presentando novedades muy pronto)

Para crear queries que respondan a este nuevo agrupamiento, tenemos disponible el comando “In Group”. Aquí tienen un ejemplo de una query utilizada por el Microsoft Test Manager que se vale de este nuevo operador.

Estas categorías están definidas en el template con el cual fue creado el proyecto. Es por este motivo que no encontraremos (al menos por ahora) ningún botón que diga “Add New Category”.

Pero no todo está perdido, si nos damos un poco de maña, nos prometen que podemos categorizar work items en proyectos que no tenían esa facilidad.

Hasta la próxima !

Gestión de Proyectos, TFS, ALM Categorias, Work Items, TFS 2010, Template, Query

Si deseamos que nuestro software siga beneficiándose de las capacidades futuras de hoy y mañana de los procesadores debemos empezar a cambiar nuestra manera de desarrollar. La razón de esto es que las aplicaciones de negocio van tener que ejecutarse en máquinas multi-core o con varios procesadores. Hasta hace pocos años una máquina con varios procesadores estaba prácticamente reservada a la supercomputación, pero hoy en día ya son comunes en cualquier PC de escritorio.

La programación concurrente y el paralelismo no son una materia trivial, la sincronización entre procesos no lo es y dividir el trabajo, asignarlo a varios procesadores, recoger los resultados y mezclarlos para reconstruir la solución final tampoco.

En el pasado, la paralelización requería manipulación de bajo nivel de los subprocesos y bloqueos. Hoy en día, los desarrolladores no tendrían que luchar contra esta complejidad, porque sería dar un paso atrás en productividad. Su tarea es seguir dedicando sus esfuerzos a lo que mejor saben hacer que es desarrollar aplicaciones de alto nivel que resuelven problemas de negocio sin controlar la ejecución concurrente de sus procesos.

Para ello, debemos acostumbrarnos a usar el término task en lugar del thread como seguramente la mayoría de nosotros veníamos haciendo y aprovechar las nuevas capacidades que ofrece las APIs de .NET Framework 4, así como también las del Visual Studio 2010.

.NET Framework 4, proporciona un nuevo runtime, nuevos tipos de biblioteca de clases y nuevas herramientas de diagnóstico para la programación paralela y concurrente. Es aquí donde hace su aparición Parallel Extensions, simplificando el desarrollo en paralelo, de modo de poder escribir código paralelo eficaz, específico y escalable de forma natural sin tener que trabajar directamente con subprocesos. Sin embargo, no todo código se presta para la paralelización por ejemplo, si un bucle realiza solo una cantidad reducida de trabajo en cada iteración o no se ejecuta para un gran número de iteraciones, la sobrecarga de la paralelización puede dar lugar a una ejecución más lenta del código. Además, al igual que cualquier código multiproceso, la paralelización hace que la ejecución del programa sea más compleja.

Parallel Extensions se compone de dos partes: Parallel Linq (PLINQ) y Task Parallel Library (TPL). También consta de un conjunto de estructuras de datos de coordinación (CDS) utilizada para sincronizar y coordinar la ejecución de tareas concurrentes. La siguiente ilustración proporciona información general de alto nivel de la arquitectura de programación paralela en .NET Framework 4.

A continuación explicaré cada uno de sus componentes. PLINQ implementa el conjunto completo de operadores de consulta estándar de LINQ  e incluye otros adicionales para las operaciones paralelas. Combina la simplicidad y legibilidad de la sintaxis de LINQ con la eficacia de la programación paralela. En muchos escenarios, PLINQ puede aumentar significativamente la velocidad de las consultas LINQ  to Objects utilizando todos los núcleos disponibles en el equipo host de una forma más eficaz. Para hacer esto divide el origen de datos en segmentos y, a continuación, ejecuta la consulta en cada segmento en subprocesos de trabajo independientes en paralelo en varios procesadores. La clase System.Linq.ParallelEnumerable expone casi toda la funcionalidad de PLINQ.  Les mostraré un ejemplo en el que invoco el método de extensión ParallelEnumerableAsParallel() para indicarle que la query debe ejecutarse en forma paralela.

for (var i = 0; i < data.Length; i++)

{

    data[i] = i;

}

data[1000] = -1;

data[14000] = -2;

data[15000] = -3;

data[676000] = -4;

data[8024540] = -5;

data[9908000] = -6;

var negativos = from valor in data.AsParallel()

                where valor < 0

                select valor;

Al ejecutarse la query en paralelo los resultados de cada subproceso de trabajo deben volver a combinarse en el subproceso principal por ejemplo para la inserción en una lista. El tipo de combinación que  PLINQ realiza depende de los operadores que se encuentran en la consulta. Con el método WithParallelMergeOptions(), puede indicarse a PLINQ una sugerencia de que tipo de combinación se va a realizar.

La biblioteca TPL es un conjunto de API que tiene como propósito lograr que los desarrolladores aumenten la productividad simplificando el proceso de agregar paralelismo y simultaneidad a las aplicaciones, utilizando eficazmente todos los procesadores que están disponibles. Además, se encarga de la división del trabajo, la programación de los subprocesos y otros detalles de bajo nivel.

El concepto principal de Parallel Extensions es una tarea, que es una pequeña unidad de código, de forma independiente. Se encarga de dividir el trabajo y lanzar un número óptimo de threads basándose en el número de CPUs o cores que tenemos.

Yendo aun mas allá, sin llegar al nivel de granularidad de una task, podemos trabajar a más alto nivel aún con la clase estática Parallel y escribir código como el siguiente:

static void Main()

{

    Parallel.For(from, to, i=> )

    {

    });

}

Mediante un ciclo como el anterior, dejamos que el runtime de Parallel Extensions se encargue de paralelizar el trabajo creando las tasks y encargándose de  todo el proceso. A continuación les mostraré las mejoras de rendimiento al paralelizar un programa muy sencillo. El método SumaRaicesNesimaDeX devuelve la suma de las raíces n-énesima de todos los enteros entre 1 y un 10 millones donde n es una variable recibida como parámetro. La forma de resolución de la raíz contiene pasos de procesamiento adicionales que aumentan el tiempo de ejecución total de la consulta. Además, en el main utilizo la clase Stopwatch para determinar cuantos milisegundos tarda el programa en ejecutarse.

static void Main()

{

    var tiempo = Stopwatch.StartNew();

    for (var i = 2; i < 20; i++)

    {

        var resultado = SumaRaicesNesimaDeX(i);

        Console.WriteLine("Raiz {0} = {1} ", i, resultado);

    }

    Console.WriteLine(tiempo.ElapsedMilliseconds);

    Console.ReadLine();

}

public static double SumaRaicesNesimaDeX(int n)

{

    double resultado = 0;

    for (var x = 1; x < 10000000; x++)

    {

        //Raíz n-ésima de x

        resultado += Math.Exp(Math.Log(x) / n);

    }

    return resultado;

}

El programa lo ejecute en AMD Phenom II X4 810 de 64 bits con 4 GB de memoria RAM y tardó aproximadamente 16 segundos.

Ahora si remplazo el ciclo:

for (var i = 2; i < 20; i++)

{

    var resultado = SumaRaicesNesimaDeX(i);

    Console.WriteLine("Raiz {0} = {1} ", i, resultado);

}

por el siguiente código añadiéndole paralelismo:

Parallel.For(2, 20, (i) =>

{

    var resultado = SumaRaicesNesimaDeX(i);

    Console.WriteLine("Raiz {0} = {1} ", i, resultado);

});

Mediante pequeñas modificaciones del código como son un índice de inicio y de fin y la llamada a través de un delegate, la ejecución del programa solo tarda aproximadamente 4 segundos y medio.

Visual Studio 2010 incluye nuevas herramientas de profiling y debugging para la ejecución concurrente. Un ejemplo de esto es el visualizador de concurrencia. Esta herramienta ayuda  a analizar nuestras aplicaciones secuenciales para descubrir las oportunidades de paralelismo. El visualizador de concurrencia incluye visualización y herramientas de reporte. Hay tres puntos de vista principales: utilización de CPU, subprocesos y núcleos.

El eje X muestra el tiempo transcurrido desde el inicio de la traza hasta el final de la actividad de la aplicación. El eje Y muestra el número de núcleos de procesadores lógicos en el sistema. La zona verde representa el número medio de cores lógicos que se analiza en la aplicación en un momento dado en la ejecución del profiling. El resto de los núcleos por otros procesos que se ejecutan en el sistema (que se muestra en amarillo).

Si queremos paralelizar nuestra aplicación, debemos buscar áreas de ejecución que presentan largas regiones verdes a nivel de un solo núcleo en el eje Y o regiones donde no hay mucha utilización de la CPU, donde el verde no demuestra ni es considerablemente menos de 1 en promedio. Ambas circunstancias podrían indicar una oportunidad para la paralelización. En segundo lugar, si estamos tratando de afinar la aplicación paralela, esta vista le permite confirmar el grado de paralelismo que existe cuando la aplicación se ejecuta.

Este cambio de paradigma nos exige una nueva manera de pensar. Los threads son una abstracción demasiado débil. Debemos empezar a pensar en tareas no en threads y en relaciones entre esas tareas y su concurrencia en lugar de sincronización de threads. Seremos los desarrolladores quienes de un modo u otro tendremos que empezar a pensar en paralelización.

.NET, Entity Framework, Visual Studio

Flexibilidad como opuesto a rigidez, agilidad como enemigo de proceso, gestión adaptativa versus gestión predictiva, cumplir el plan o responder al cambio. Estas opciones evolucionan como búsqueda de mejora a resultados poco satisfactorios (ya lo estudia estadísticamente Standish Group desde hace años) para los proyectos de desarrollo de software.

Entre aferrarnos totalmente a lo establecido o innovar sin más, vale no perder de vista la ser realistas y considerar:

· Que la relación de procesos-tecnología-personas es la clave del éxito para obtener ventajas competitivas, aunque la proporción depende del tipo de producción y características de cada empresa, su cultura, misión y el tipo de proyectos que desarrolla.

· Que un cliente puede preferir ceñirse al triángulo “producto-fecha-costo planificados”, y no se encuentre preparado para adoptar una visión que proponga que “no existe el producto terminado, sino que el producto está en constante evolución”.

· Que el proyecto aplique sin problemas para la ejecución de un plan controlado. Puede no necesitar disponer de un producto en lo inmediato, contar con requisitos claros, detallados e inamovibles, por lo que no exista un escenario de incertidumbre. Que la innovación no sea el factor determinante para el proyecto.

· Que en cada situación se evaluará la relación costo /beneficio en función de los riesgos.

Y mientras tanto seguir discutiendo las siguientes premisas:

· Que a más documentos menos contacto con el producto real.

· Que a más adherencia a procesos menos lugar a creatividad e innovación.

· Que no siempre se verifica que “la forma más eficiente de desarrollar un trabajo es hacerlo bien a la primera”.

· Que productividad y calidad no se dan necesariamente de manera homogénea.

· Que pueden convivir en un mismo equipo personas del negocio con las de desarrollo y hacer de la comunicación directa una fortaleza.

· Que los procesos y la tecnología son dueños de los conocimientos explícitos pero que la innovación siempre estará en las personas.

Ser flexibles es poder ir incorporando cambios para mejorar, si adherimos a que “El cuestionamiento de lo conocido es el motor de la evolución del conocimiento”.

El documento http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf , es una interesante guía para la transición.

Metodologías y Procesos

El proceso de migración a TFS 2010 siempre es complejo. TFS hace uso de varias tecnologías demas del propio servidor, por ej: usa SQLServer para almacenamiento, Sharepoint para repositorio de documentos y trabajo colaborativo y IIS para alojar los servicios.

En resumen siempre es bueno leer las guías y estar preparados para esta tarea.

En http://vs2010upgradeguide.codeplex.com/ hay una guía que preparan los ALM Rangers que es un grupo de gente que adiciona información a las guias que publica MS.

Aqui les dejo un listado de los temas que están resueltos en esta guía (en Inglés):

ALM, Javascript, TFS Team Foundation Server

Días pasados, en el proceso de upgrade de un servidor a TFS 2010, comenzamos con la actualización del motor de base de datos a su versión 2008, uno de los prerrequisitos exigidos.

Si bien el servidor estaba virtualizado y ante algún imprevisto podríamos restaurar rápidamente un backup reciente de esa VM, decidimos tomar una precaución adicional que fue esperar un par de días luego de ese upgrade antes de encarar la instalación de la nueva versión de TFS, para ver si algún usuario informaba de inconvenientes.

Ya decididos a instalar TFS 2010, un PM nos informa que los reportes de los diferentes proyectos estaban mostrando datos viejos. La espera no había sido en vano.

Lo primero que hicimos fue forzar la actualización del Datawarehouse (aquí hemos descripto cómo hacerlo), pero sin éxito.

SQL Management Studio por su parte, informaba las bases de datos de Analysis Services estaban funcionando correctamente, pero los datos aún no se actualizaban.

Sin mensajes de error, la búsqueda de ayuda en Internet se complicaba. No aparecían casos similares en los buscadores, hasta que mirando en el Log de Eventos del SO dimos con algunas palabras claves que nos condujeron a un artículo de Bill Wang.

Básicamente el problema era que, luego del upgrade a SQL Server 2008, TFS seguía intentando conectarse a Analisys Services pero de la versión 2005, y allí se producía el fallo.

Para solucionar el inconveniente, hay que reemplazar una entrada del Web Config del WS de TFS como a continuación se detalla:

Reemplazar …

   1: <dependentAssembly>

   2:         <assemblyIdentity name="Microsoft.AnalysisServices"

   3:                           publicKeyToken="89845dcd8080cc91"

   4:                           culture="neutral" />

   5:         <bindingRedirect oldVersion="9.0.242.0" newVersion="9.0.242.0"/>

   6: </dependentAssembly>

… por …

   1: <dependentAssembly>

   2:         <assemblyIdentity name="Microsoft.AnalysisServices"

   3:                           publicKeyToken="89845dcd8080cc91"

   4:                           culture="neutral" />

   5:         <bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0"/>

   6: </dependentAssembly>

Tener en cuenta que además, la herramienta “SetupWarehouse.exe” también accede al cubo de la misma forma, con lo cual deberá modificarse el archivo “SetupWarehouse.exe.config”.

TFS, Gestión de Proyectos, SQL Server Team Foundation Server, Gestión de Proyectos, Datawharehouse

Como es de esperarse a estas alturas, existe infinidad de blogs que enumeran las características que vienen con la nueva versión de Team Foundation Server.

Para no caer en la misma situación, la idea de este post es que nos enfoquemos solamente en algunas pocas de esas nuevas características a las que el nombre de “feature” le queda un poco chico, ya que implican un cambio más de fondo y que va un  poco más allá de una simple “nueva funcionalidad”.

Project Collections

Las colecciones de proyectos brindan una capa adicional de indirección que permite el agrupamiento de proyectos según el criterio que a nosotros más nos convenga. Esta agrupación podría ser por tipo de arquitectura, por equipo o área de la empresa, o por ejemplo, separando proyectos de desarrollo de aquellos otros de consultoría.

Lo interesante de este agrupamiento es que no es solamente a nivel lógico, sino que también lo es a nivel físico. Esto permite lograr un mejor nivel de aislamiento entre proyectos, y ese aislamiento impacta en el aspecto de seguridad, ya que cada colección equivale a una nueva instancia de TFS en términos de sus versiones 2005/2008.

El lector atento dirá a esta altura “… pero ojo… acá la cosa se complica …”.

Y si, como en cualquier otro caso, nos encontraremos con ventajas y desventajas en la implementación de colecciones de proyectos. Vamos a enumerar las más importantes:

Ventajas:

• Aunque parezca obvio, no deja de ser una ventaja el hecho de poder seguir trabajando como en las versiones anteriores de TFS si no tenemos ganas de complicarnos la vida con estas colecciones, con la única salvedad de que nuestros proyectos estarán ahora dentro de una “Default Collection”.
• Como cada colección maneja su propia base de datos, tenemos muchas más opciones a la hora de escalar y manejar balanceo de carga.
• En grandes organizaciones (y no tanto), este nivel de aislamiento permite una administración de seguridad mucho más granular.
• Tenemos la posibilidad de hacer respaldo/restauración de grupos de proyectos de manera independiente.

Desventajas:

• Lo que para algunos pueda ser una ventaja, es lo contrario para otros, ya que se podrá argumentar que ante una gran cantidad de colecciones se complicará seguramente la tarea del administrador al momento de configurar permisos de acceso a cada uno de los proyectos.
• A raíz de que cada colección usa su propia base de datos, nos encontraremos con una tarea más ardua al momento de administrar copias de resguardo de toda esa información adicional.

En el blog de Steve Lange podrán encontrar un diagrama de flujo muy interesante que les ayudará a decidir si necesitan o no manejar Project Collections.

Nuevos templates de Proyectos

Al momento de crear un nuevo proyecto en TFS en la versión 2010, nos encontraremos con un par de nuevos templates, entre ellos la versión 5.0 de MSF for Agile (aquí podrán encontrar una comparativa con la versión anterior).

No quisiera centrarme en describir el proceso que intenta implementar, sino en la funcionalidad que aportan sus nuevos tipos de Work Item, Workflows y por sobre todo, las nuevas relaciones que se pueden establecer entre ellos.

Cabe recordar que TFS 2010 permite establecer jerarquías de work items y además crear relaciones mucho más ricas que una simple dependencia de ida y vuelta entre uno y otro. Valiéndose de esto último, el nuevo template permitirá documentar por ejemplo “Historias de Usuario” y “Casos de Test” vinculados por una relación de tipo “Testea a …” o “Testeado por …” entre otras.

Este es, indudablemente, un modelo mucho más rico que el anterior, ya que permite ser explotado por queries mucho más intuitivas, muchas de las cuales ya vienen incluidas en el propio template.

Podríamos consultar, por ejemplo, Historias de Usuario que no cuentan con casos de test asociados para tener rápidamente un acceso a partes de nuestra aplicación que no tienen las pruebas mínimas necesarias.

Dashboards

Gracias a su integración con las últimas versiones de Sharepoint, los portales de proyectos creados con TFS 2010 mejoran su capacidad de reporting incluyendo Dashboards.

La idea de un Dashboard (o tablero de control) es contar con una consola que incluya diferentes indicadores que muestren rápidamente la situación actual del proyecto en un único lugar pero a un nivel más “macro” y que, además, permita a las áreas gerenciales determinar que tan en línea está un determinado proyecto con las políticas de su negocio.

Los Sharepoint Dashboard son la materialización de lo que se conoce como Balance Scorecards, es decir, sistemas de gestión y planificación estratégica que intentan alinear las actividades diarias del desarrollo con la visión de la empresa.

Obviamente estos Dashboards son altamente personalizables, pero de manera inmediata podremos contar con la siguiente información:

• Reporte de Task Burndown
• Lista de cantidades de Work Items en sus diferentes posibles estados (Activos, Cerrados, Resolved, etc.)
• Lista de fechas importantes
• Lista de los últimos Builds
• Lista de los últimos checkins realizados y sus comentarios
• Vista rápida del Product backlog donde se ve el estados de sus items

Cada uno de estos indicadores no es más que un wepbart embebido en el portal Sharepoint, por lo que contando con MOSS podremos personalizarlos y/o extenderlos de una manera muy flexible.

Hasta la próxima.

Gestión de Proyectos, Sharepoint, TFS Gestión de Proyectos, Team Foundation Server, Dashboard

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.

Cloud Computing, Tecnología