Hace unas semanas comencé una serie de artículos sobre ALM y SharePoint 2010. Después de haber realizado tres eventos presenciales al respecto y de haber recogido vuestro feedback en relación a los puntos que más os interesaban sigo con la lista de artículos que tenía prevista.
Como os decía en la primera entrada introductoria, dos de los elementos fundamentales a tener en cuenta a la hora de plantearnos la gestión del ciclo de vida de nuestras aplicaciones son los procesos que llevaremos a cabo y las herramientas que utilizaremos para hacerlo. En este segundo artículo quiero reflexionar, precisamente, de las herramientas que nos pueden ayudar en el camino para mejorar la calidad de nuestros proyectos sobre SharePoint 2010.
El primer nombre de nos tiene que venir a la cabeza cuando hablamos de ALM y de SharePoint 2010 es Team Foundation Server. Es un producto de Microsoft, al igual que SharePoint, y seguramente será el que mejor se integre con esta plataforma. Además es una suite completa que nos va a ayudar en todas las fases del desarrollo, desde la gestión inicial de los requerimientos a la gestión de las incidencias que aparezcan. Por otro lado, tenemos que tener en cuenta que es una herramienta con un coste elevado, que no quiere decir que sea un producto caro. Como siempre dependerá de si necesitamos o no todo lo que el producto nos ofrece y de si el producto cubre o no todas nuestras necesidades. Tened también en cuenta que cada criterio que escojamos para elegir una herramienta u otra tendrá una importancia determinada y una valoración relativa. Un ejemplo ilustrativo es el coste. No podemos centrarnos únicamente en lo que cuestan las licencias del software que vamos a utilizar, sino el tiempo que vamos a invertir en implementarla y lo que nos va a costar encontrar gente capacitada para hacerlo.
En mi opinión, la herramienta que escojamos será lo de menos, siempre y cuando cumplamos el objetivo de gestionar adecuadamente el ciclo de vida de nuestras aplicaciones. No hay una verdad absoluta que indique que tienes que elegir una herramienta determinada cuando se cumplen ciertas condiciones. En nuestro caso particular, tuvimos en cuenta los conocimientos del equipo técnico de diferentes herramientas y al final decidimos no utilizar TFS por las siguientes razones:
- Nuestro equipo técnico tenía más experiencia en otras herramientas
- El coste de la herramienta era demasiado elevado para asumirlo
- Necesitamos desarrollar aplicaciones para otros dispositivos como iPhone o Blackberry
- Necesitabamos tener todo montado en un corto espacio de tiempo
A partir de este momento hablaré, por lo tanto, de otras herramientas. En cualquier caso, en ningún momento desaconsejo el uso de TFS. Es más, si no conocéis otra alternativa que os satisfaga, siempre sería una opción recomendable. De hecho, si estáis interesados, os recomiento unos artículos de Chris o’Brien que os darán muchas pistas sobre cómo comenzar ()
Dicho esto, y para daros algún nombre, antes de descartar TFS tuvimos que buscar alternativas que nos permitieran gestionar el ciclo de vida de nuestras aplicaciones. Según el area de actuación, escogimos estas herramientas:
- Pruebas unitarias y de aceptación: NUnit y NCover
- Pruebas de aceptación: Cucumber y Capybara
- Build Server: Jenkins y MSBuild
- Gestión de requerimientos y de incidencias: Beezy
Como tampoco pretendo escribir la biblia del ALM, sino incidir en aquellos puntos de dolor a la hora de trabajar con SharePoint 2010, los siguientes artículos los destinaré a cubrir aquellas áreas que más nos van a ayudar a mejorar la calidad de nuestros proyectos SharePoint. De aquí a final de año escribiré sobre los siguientes temas:
- Pruebas unitarias
- Pruebas de aceptación
- Automatización del despliegue
Si, además de estos tres puntos, estáis interesados en algo concreto sobre lo que habéis visto en las sesiones que he ido haciendo, no dudéis en ponerme un comentario y haré todo lo posible por escribir también algo al respecto.
