Recientemente, un cliente nos comenta la decisión de incorporar TFS en la empresa como solución ALM.
El desafío que se planteaba era interesante, tenían un proceso medianamente ordenado pero cada uno de los roles involucrados utilizaba sus propias herramientas (algunas de ellas manuales) para administrar los documentos que se generaban, por lo que además de la diversidad de formatos, no existía sincronización entre esos documentos. Mucho menos pensar en algún tipo de versionamiento o workflow de aprobación.
Por su parte, el equipo de desarrollo recibía quejas constantes originadas en el cliente/usuario que apuntaban a la baja calidad del producto entregado. ¿Cómo era esto posible si el equipo contaba con recursos altamente capacitados?. Claramente el problema venía del lado de la mala administración del código fuente.
Con estas limitaciones en la gestión de los diferentes proyectos quedaba claro que no se podía contar con casi ningún tipo de métrica, gráfico o reporte que mostrara el grado de avance (o retroceso…). Tampoco existía la posibilidad de obtener algún indicador que permitiera la detección temprana de desviaciones.
Si bien la decisión estaba tomada, se reconocía asimismo la existencia de algún temor ante la imposibilidad de adaptarse a esta nueva herramienta que se presentaba como un gigante indomable frente a aquellas otras a las que conocían desde hace mucho tiempo. Iríamos por una cambio gradual.
En resumen, se requería una incorporación gradual de TFS al proceso de la empresa, pero con una visión de mediano/largo plazo que escale correctamente a medida que se vayan obteniendo resultados y que se vayan incorporando otras áreas y recursos de la empresa a esta nueva forma de integración. Por lo tanto, teníamos que lograr resultados rápidamente para convencer a los grupos más escépticos y a la vez estar preparados para cuando éstos decidan subirse al nuevo barco.
Arquitectura de servidores
Estaba claro que tanto las bases de datos (Data Services), como los reportes (Reporting Services, Analysis Services), serían instalados en un servidor dedicado distinto al que se usaría como Application Tier. En caso de detectar problemas de performance originados en el Data Tier, podríamos escalar utilizando SQL Server clusters.
Lo nuevo de todo esto es que con la versión 2010 de TFS también podemos escalar el Application Tier. Aparece aquí el nuevo concepto de TFS Farm.
Con esta nueva posibilidad, podemos agregar un nuevo servidor a nuestra Application Tier si se diera alguna de estas situaciones:
- Necesidad de redundancia en la instalación de TFS
- Necesidad de mejora de performance
- Necesidad de restaurar un servidor que ha fallado
- Necesidad de mover una instalación a otro servidor
Con esta arquitectura obtendríamos estos dos importantes beneficios:
- Soporte de NLB (Network Load Balancing) en Application Tiers: Además de la mejora en performance, obtendremos alta disponibilidad, ya que podría caerse uno de los servidores sin que el usuario se entere. También podríamos aplicar parches individualmente a cada servidor poniéndolo offline sin desconectar a los usuarios.
- Escalabilidad en Data Tiers: Teniendo más de un servidor SQL, tendremos más flexibilidad, ya que como cada Team Project Collection está en una base de datos independiente, podremos hostearlo como mejor nos convenga.
Un tema resuelto.
Organización de los proyectos
Habiendo relevado poco y nada a nivel global, no estaba del todo claro cómo íbamos a organizar los proyectos, y como el cliente no conocía TFS, no podía colaborar demasiado en determinar si usaríamos un sólo Team Project a nivel global y nos manejaríamos con áreas de proyecto para separar sectores (lo que implicaba un trabajo importante de personalización de templates de proyecto) o un Team Project por sector.
Finalmente nos decidimos por esta última opción, ya que si bien no estaba perfectamente delimitado, cada sector de la empresa se dedicaba casi exclusivamente a un sólo producto de software. Con esto, más algunos toques a las queries de work items, podríamos resolver las cuestiones más urgentes y en caso de necesitar un nivel de agrupamiento más alto, tendríamos la posibilidad de armar otras Project Collections.
Otro tema resuelto.
Final abierto (o no tanto …)
Al ser una instalación limpia, fue bastante sencilla y rápida la instalación de los diferentes componentes y la creación del Team Project que utilizaría, inicialmente, el sector que planteó los requerimientos.
Terminada la instalación, y habiendo logrado que los diferentes roles de ese sector pudieran …
… manejar documentos versionados utilizando el Project Portal como punto de acceso y que además, registren requerimientos en un repositorio común,
… que los desarrolladores puedan asociar el código fuente a cada uno de esos nuevos requerimientos y que además tengan la posibilidad de corregir bugs de versiones en producción al mismo tiempo que se desarrollan features de la nueva versión sin que eso implique un riesgo de regresión (gracias a un plan sencillo de branching),
… que se empiecen a generar los primeros reportes de trabajo pendiente y de estado de bugs,
todo esto con una solución (relativamente) sencilla y a la vez escalable, no es difícil imaginar cuál va a ser la reacción de los otros sectores de la empresa.
Hasta la próxima.