Implementación de tfs 2010 en entornos complejos (cómo y por qué) v03
•Transferir como PPTX, PDF•
0 gostou•2,036 visualizações
I gave this presentation in a Microsoft Webcast. This presentation is focused on presenting TFS on scenarios that have some level of complexity. The first one is scaling TFS for distributed teams or for high availability, the second for using TFS 2010 in a JAVA development team, the third one describes de integration with Project Server and the fourth talks about how to customize the process templates in TFS.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (19)
Semelhante a Implementación de tfs 2010 en entornos complejos (cómo y por qué) v03
Semelhante a Implementación de tfs 2010 en entornos complejos (cómo y por qué) v03 (20)
Mais de Diego Ferreyra
Mais de Diego Ferreyra (9)
Último
Último (20)
Implementación de tfs 2010 en entornos complejos (cómo y por qué) v03
- 1. Sesión Audio Preguntas • La presentación • Por favor ponga en • Por favor use el comenzará en Mudo su Q&A manager breve. micrófono. durante la sesión. • La charla será • El audio estará • Hay una sesión de grabada. disponible a través Preguntas y de LiveMeeting. Respuestas al final de la sesión.
- 6. Visual Studio 2010 Cliente Microsoft Test Manager Command Line / PowerShell Office, SharePoint Portal TFS Web Services Aplicación SharePoint Services SQL Server Reporting Services SQL Server Analysis Services Datos Operational Store Data Warehouse Cubo
- 7. App Tier Data Tier Sharepoint TFS Application Data Store Tier
- 8. App Tier Data Tier TFS AT Data store Clustered SQL SharePoint Server Farm Clustered Sharepoint
- 11. Number of users Configuration CPU Memory Hard disk Fewer than 250 Single-server (Team Foundation 1 single core 2 GB 1 disk at 7.2k rpm users Server and the Database Engine processor at 2.13 GHz (125 GB) on the same server). 250 to 500 users Single-server. 1 dual core processor 4 GB 1 disk at 10k rpm at 2.13 GHz (300 GB) 500 to 2,200 users Dual-server (Team Foundation 1 dual core Intel Xeon 4 GB 1 disk at 7.2k rpm Server and the Database Engine processor at 2.13 GHz (500 GB) on different servers). This row is for Team Foundation Server. This row is for the Database 1 quad core Intel 8 GB SAS disk array at Engine with 500 to 2,200 users. Xeon processor at 10k rpm (2 TB) 2.33 GHz 2,200 to 3,600 Dual-server. 1 quad core Intel 8 GB 1 disk at 7.2k rpm users This row is for Team Foundation Xeon processor at (500 GB) Server. 2.13 GHz This row is for the Database 2 quad core Intel 16 GB SAS disk array at Engine with 2,200 to 3,600 Xeon processors at 10k rpm (3 TB) users. 2.33 GHz
- 14. Team Explorer Everywhere Visual Studio Team Explorer CMMI and Agile Iteration Planning Project reporting Atomic check-in Check-in Policies Work item linking Work item hierarchy Synchronize in Eclipse Visual Branching Shelve / Unshelve Team Build Java builds .NET builds Continuous integration Gated Check-in
- 32. • Escalando TFS 2010 • Topologías de TFS 2010 • Requerimientos de Team Foundation Server • Integración TFS – Project Server • System and Setup Requirements to Support Integration of Team Foundation Server and Project Server • Microsoft® Team Foundation Server® 2010 and Microsoft Project Server® 2010 Integration Hyper-V Virtual Machine • Trabajando con equipos JAVA • Microsoft Visual Studio Team Explorer Everywhere 2010 with SP1 • Adaptando la metodología • Modificación de Process Templates
- 33. Q&A MUCHAS GRACIAS! Diego Fidel Ferreyra Development Center Manager Huddle Group http://ferreyra.wordpress.com/
Notas do Editor
- Hola a todos, mi nombre es DiegoFerreyra y trabajo en la empresa argentina HuddleGroup, coordinando equipos de desarrollo. Además de ejecutar proyectos de consultoría en TFS, internamente estamos usando TFS desde hace varios años y esto nos brinda experiencia de haber usado la herramienta en escenarios reales. Nuestro principal negocio son los proyectos de desarrollo a medida. Tenemos equipos de desarrollo distribuidos en Buenos Aires, Bahía Blanca, Mendoza y Santiago de Chile, por lo que nos encontramos con múltiples escenarios en los que utilizamos la herramienta.Durante esta presentación, hablaré sobre algunos de los escenarios más interesantes que hemos trabajado, de manera de poder compartir con ustedes la experiencia en cada uno de ellos.El primer escenario comentado será sobre las diversas alternativas para implementar TFS con alta disponibilidad y con equipos distribuidos.Luego comentaré sobre la posibilidad de que se trabaje con equipos en diversas plataformas, más allá de .NET y Visual Studio.En el tercer escenario, comentaré la experiencia de haber trabajado en la integración de TFS 2010 con Project Server.Y para cerrar, hablaré sobre cómo adaptar los templates de procesos para escenarios en que difieren de los artefactos por default provistos por TFS.
- El primer escenario que voy a comentar es aquel en que es necesario considerar cómo escalar TFS 2010.En nuestro caso, las principales causas bajo las cuales tuvimos que pensar en esquemas de este tipo, son las siguientes:Contamos con equipos distribuidos. Actualmente en Huddle tenemos oficinas con equipos de desarrollo en Buenos Aires, Bahía Blanca, Mendoza y Santiago de Chile. Esto implica que las velocidades de conexión en algunos casos no son tan buenas, y por lo tanto debemos contar con formas que optimicen esto.Trabajamos con clientes distribuidos geográficamente. Nuestros clientes están distribuidos principalmente en Estados Unidos, en la costa este y oeste, en Argentina y Latinoamérica. Incluso para los clientes que tenemos en Buenos Aires o Bahía Blanca, trabajamos con equipos off-site en la mayoría de los casos, lo que nos obliga a considerar cómo utilizar la herramienta en estos escenarios.Necesitamos adaptarnos a la forma de trabajo de nuestros clientes. Tenemos clientes que ya venían trabajando con TFS 2010 y deseaban que nuestros equipos de desarrollo trabajen con su propio servidor de TFS en lugar del propio servidor de TFS de Huddle. Para esto, tuvimos que pensar alternativas para lograr conexiones seguras y lograr un buen tiempo de respuesta para los equipos de desarrollo, considerando que los servidores de TFS están en diversas zonas de Estados Unidos.
- En cuanto a las estrategias para escalar TFS, es necesario primero comprender cuales son los principales servicios y funciones que cumple, junto con las distintas capas que componen su arquitectura. Conocer bien estos puntos es muy útil para poder identificar más fácilmente los posibles cuellos de botella, de manera de poder luego tomar decisiones para poder escalar los componentes o servicios correctos.Por otro lado, más allá de los componentes, existen distintas topologías de instalación de TFS. Por topologías entendemos las distintas formas en que puede ser instalado cada uno de sus componentes y la integración necesaria con otros productos. Esto también es bueno conocer para que se pueda realizar una correcta instalación en base al escenario en que se encuentre inicialmente.Pasamos entonces a ver las principales funciones y servicios de TFS 2010
- Desde un punto de vista de alto nivel, es importante remarcar que TFS es una plataforma que provee múltiples servicios para que puedan ser consumidos por diversos tipos de clientes.<CLICK>Lascaracterísitcas principales que provee, son las que se muestran aquí.Se brindan herramientas para poder trabajar en la planificación y seguimiento de los proyectos, logrando una gran trazabilidad hasta el código mismo. Esto permite que se pueda relacionar un requerimiento con las tareas, test cases, bugs, builds y hasta los checkins de código correspondientes. Esto es contenido dentro de los llamados TeamProjects. A su vez, existen colecciones de proyectos llamadas TeamCollections.Se puede también administrar el versionado del código fuente, junto con la posibilidad de poder aplicar políticas de checkin, generar alertas o poder relacionar un checkin con un requerimiento, bug o tarea.También se provee infraestructura para administrar los casos de prueba definidos por los testers del equipo, como así también automatizar su ejecución y generar reportes automáticos con los resultados.Adicionalmente, se cuenta con la infraestructura necesaria para definir servidores de builds. Estos servidores se conectan con diversos “BuildAgents” que son los servidores encargados de compilar las soluciones. También es posible obtener a partir de los builds generados, reportes automáticos con los resultados y generar alertas o enviar mails con los mismos.Sobre la información generada durante el proyecto, tanto requerimientos como métricas de código o resultados de los builds, es posible obtener reportes por medio de consultas o accediendo a un cubo contenido en SQL Server AnalysisServices.<CLICK>A su vez, es posible definir un template de proceso que englobe las definiciones en cuanto a artefactos que se utilizan (llamados Workitems), templates de sitios de proyecto, etc. Este template es utilizado luego para generar nuevos proyectos y será un punto importante cuando veamos cómo adaptar la metodología.<CLICK>Se provee también la infraestructura para poder administrar las VM para la ejecución de los tests automáticos. Esto tiene integración con System Center Virtual Machine Manager, de manera de poder generar las VMs ante la generación de un build para que luego sea instalado allí el nuevo build.<CLICK>Luego se cuenta con una serie de clientes para poder acceder a la plataforma. El más conocido y habitual es Visual Studio en sus diferentes veresiones, pero también se cuenta con el Team Explorer que se integra con Excel y Project para poder acceder desde estos productos. También se cuenta con una aplicación web llamada Team Web Access que permite utilizar las funcionalidades de TFS desde la web. Otro cliente muy importante es Sharepoint, que permite tener un teamsite de colaboración asociado al teamproject, y que de esta manera el equipo pueda utilizar todas las funcionalidades de Sharepoint desde el teamsite. Allí se pueden publicar reportes y dashboards, que proveen información al instante sobre aspectos tales como el avance del proyecto o la calidad de los entregables.
- Si consideramos otro enfoque de los distintos componentes de TFS, podemos dividirlo en estas tres principales capas.En la capa de Cliente se cuenta con múltiples productos que pueden consumir la plataforma. Visual Studio, Excel y Sharepoint quizás son los más utilizados normalmente por los miembros del equipo. De esta manera, ya empezamos a ver que uno de los componentes con que se integra TFS es con Sharepoint, por lo tanto allí se puede encontrar un punto para escalar la solución.Debajo se encuentra una capa de Aplicación, en la que se proveen una serie de web services por parte de TFS, como así también los servicios provistos por SQL Server y Sharepoint. Aquí vemos también que SQL es otro importante componente para pensar en cómo escalar la solución.Adicionalmente, a nivel de datos, TFS cuenta con 3 principales repositorios: una base de datos SQL en la que persiste toda la información operacional; un data warehouse que periódicamente es actualizado con la información de las diversas bases operacionales que se encuentren definidas y un cubo generado a partir de este datawarehouse, de manera de poder contar con información analítica sumarizada.Con esto hemos visto los principales componentes que nos permitirán definir diversos esquemas para escalar nuestra implementación de TFS.
- En cuanto a topologías de instalación de TFS 2010, la más sencilla es la llamada Single Server. En esta topología se instala en un único servidor todos los componentes de TFS. Esto es, Sharepoint (que puede ser Windows SharepointServices 3.0 o superior), SQL Server y TeamFoundation Server. Esta instalación pequeña incluso soporta ambientes de workgroups que quizás está siendo utilizado. También es importante mencionar que puede ser instalado en una máquina con sistema operativo cliente, tal como Windows Vista con Service Pack 2 o Windows 7.Pero aquí vemos que si consideramos que 100 usuarios por ejemplo estarán accediendo al mismo servidor de Sharepoint, quizás sea necesario pensar en algún modelo de escalamiento de alguna de las capas del servidor.
- Un escalón mayor, es aquel en que se puede instalar TeamFoundation Server para interactuar con SQL Server y Sharepoint en servidores distintos. Esto es muy útil ya que por un lado permite mayor escalabilidad y por otro, permite reutilizar la infraestructura existene en la empresa. De esta manera, puede por ejemplo integrarse con un cluster de SQL Server o Sharepoint. En general es conveniente crear una nueva Web Application en Sharepoint específica para TFS, para poder ejecutar en ella los teamsites de proyectos. En el servidor de Sharepoint se deben instalar unas extensiones para Sharepoint de TeamFoundation Server, que proveen templates de teamsites para los templates de proyecto default, como así también una serie de componentes específicos tales como librerías, dashboards y web parts para la visualización de consultas.
- El paso mayor de escalamiento de TFS, se da cuando se deben instalar múltiples servidores de TFS con un servidor de NLB. Esto permite alta disponibilidad para todos los servicios provistos por la plataforma.Por otro lado, en cuanto a distribución de las bases de datos, es factible contar con múltiples bases de datos que contengan colecciones de proyectos. De esta manera, puede distribuirse aún más la carga entre los servidores, por ejemplo para las diversas áreas dentro de la empresa.A su vez, con respecto a los servidores de Builds, es posible generar una granja con ellos, donde cada uno de ellos administra los llamados BuildAgents, que se encargan de compilar el código, ejecutar las pruebas y enviar los resultados a los servidores de Build. De esta manera, a la hora de configurar la integración continua, es posible que se distribuya mejor la carga entre varios servidores en lugar de sobrecargar uno.A su vez, es posible configurar como vimos antes, la integración con clusters de SQL o Sharepoint.Un componente interesante aquí es el TFS Proxy, que veremos en la siguiente diapositiva.
- TFS Proxy es un componente que ayuda a mejorar la experiencia del desarrollador a la hora de trabajar con el repositorio de código. Es utilizado cuando se trabaja con equipos distribuidos geográficamente, en los cuales la velocidad de conexión entre las sedes quizás no sea tan buena como la local.Este componente se instala en las sedes remotas y se encarga de guardar una copia en caché del código fuente. Se encarga luego de sincronizarse con el servidor central de TFS enviando y recibiendo sólo las diferencias en el código. Esto permite entonces a los equipos distribuidos geográficamente interactuar con un servidor local a velocidad de la red local, para que luego el TFS Proxy se encargue automáticamente de replicar los cambios con el servidor central.
- Como referencia respecto a las necesidades de hardware, comparto una tabla publicada en el sitio de Microsoft que comenta diversas configuraciones en base a la cantidad de usuarios que estarán interactuando con TeamFoundation Server.Esta tabla resulta útil para poder dimensionar el hardware necesario para poder instalar TeamFoundation Server
- Como conclusiones entonces, podemos ver que existen múltiples variantes a la hora de pensar cómo escalar TeamFoundation Server. Para escenarios con equipos pequeños y colocalizados pueden bien instalarse con muy pocos requerimientos de hardware, y a la hora de pensar en equipos mayores existen varias alternativas.Puede a su vez aprovecharse la infraestructura existente en la empresa y de esta manera aprovechar lo que ya se dispone.Para equipos remotos, es interesante tener en cuenta el TFS Proxy para mejorar la experiencia de trabajo de los desarrolladores.También es importante tener en cuenta el modelo distribuido de los servidores de builds, para poder contar con un escenario de integración continua realmente performante.
- El siguiente escenario es el de la integración con equipos que no trabajan en .NET.Este es un escenario común en muchas empresas, en las que cuentan con equipos de trabajo que utilizan JAVA y .NET como plataformas principales. En estos casos, suele suceder que existe una pared entre estos equipos, que impide que interactúen porque ya de por sí las plataformas son distintas. Esto, a nivel de gestión, puede causar múltiples inconvenientes, debido a que se utilizan quizás distintas herramientas para el seguimiento de los proyectos, distintos procesos dependientes de la plataforma, etcétera. Entonces es realmente importante poder contar con una plataforma unificada para la gestión de proyectos, más allá de la plataforma en que se encuentre.Para esto, Microsoft provee el Team Explorer Everywhere, que es un addin para Eclipse que permite a los desarrolladores poder integrarse con TeamFoundation Server
- Para poder interactuar con TFS 2010 desde otras plataformas, Microsoft provee Team ExplorerEverywhere. Esta herramienta, es un plugin para Eclipse hecho en Java, que por medio del uso de los web services que publica la plataforma de TFS, permite utilizar las funcionalidades del mismo. En esta tabla, vemos cuáles características son provistas por el Team Explorer Everywhere, en comparación con el Visual Studio Team Explorer.Como verán, se proveen casi las mismas funcionalidades que se pueden obtener desde Visual Studio por medio del Team Explorer. Esto implica que para los desarrolladores JAVA, el interactuar con TFS será casi exactamente igual que para los desarrolladores que utilizan Visual Studio. Adicionalmente, podrán contar con herramientas propias de la plataforma tales como los build servers, que permitirán definir los builds y obtener reportes y métricas de cada uno de ellos.
- Un aspecto importante, es que este Addin para Eclipse abre la puerta a que múltiples sistemas operativos puedan ser utilizados para la integración con TFS. De esta manera, es factible que se mantengan las plataformas originales de trabajo de los equipos, sin necesidad de migrar a Windows sus estaciones de trabajo.
- Adicionalmente, como múltiples IDEs están basados en Eclipse, esto posibilita que distintos equipos puedan a su vez utilizar las ventajas de TFS. Esto es importante para poder lograr una mayor uniformidad dentro de los equipos de desarrollo, incluso entre diversos perfiles tales como desarrolladores y diseñadores Web.
- Otro punto ventajoso para los equipos JAVA, es que el build server permite la integración con 2 herramientas de automatización de builds muy usadas. Esto, además de permitir que puedan reutilizarse para la compilación de los bits de cada proyecto, brinda la ventaja de que la información obtenida de la ejecución de los builds, tales como el éxito o fracaso, el resultado de la ejecución de los tests unitarios, el copiar los bits a un directorio específico o ejecutar acciones custom tales como el envío de notificaciones o la creación de bugs a partir de builds fallidos, puede ser aprovechado ya que Teamfoundation Server lo provee. Adicionalmente, esta información puede ser luego enviada y procesada en el cubo de TFS, permitiendo así obtener métricas interesantes para definir indicadores de calidad del equipo.Por otro lado, pueden utilizarse las características de servidor de build de TFS para poder implementar integración continua o la compilación periódica en base a variados criterios.
- Como conclusiones podemos decir entonces que el uso de Team Explorer Everywhere permite una mayor integración entre los equipos, unificar los procesos de trabajo y aprovechar las ventajas de la plataforma de manera unificada para todos.
- A continuación presentaré el escenario de integración de TFS 2010 con Project Server. Este es un escenario que se presenta en los casos en que es necesario manejar un gran portfolio de proyectos, en los que se administran pool de personas para asignar a los proyectos (no me gusta decirle Recursos a las personas), presupuestos, planificación, etcétera.Suele suceder que en estos escenarios, los Project Manangers puedan estar muy acostumbrados a utilizar Project Server para la gestión macro de los proyectos. Esta herramienta les permite planificar el uso de las personas, los presupuestos e ir viendo el avance en cada uno de ellos. Estas herramientas quizás no sean las mismas que utilice el equipo de proyecto, o quizás a un nivel de detalle distinto. Por lo tanto, se contempla en estos casos la forma en que se pueden integrar ambos productos para lograr que todos trabajen con la misma información, desde las herramientas que les resultan más cómodas.Por otro lado, es posible lograr un alto grado de trazabilidad, desde el momento en que se genera el requerimiento de alto nivel, hasta el build en que se compiló la funcionalidad que implementa el requerimiento. Esto es algo muy interesante, especialmente en escenarios con certificaciones CMMI.
- Para comenzar, querría aclarar un punto que muchas veces suele confundirse. Este escenario no es el uso del Team Explorer desde Microsoft Project. En ese caso, se pueden abrir consultas de TFS desde esta herramienta, y trabajar con los workitems como si fueran tareas desde Microsoft Project. Pero en ese caso, no se hace uso de pool de recursos, budgets, etc.El escenario que estoy planteando, es aquel en que se encuentra funcionando Project Server, con los project managers trabajando con Enterprise Plans abiertos desde Microsoft Project. Esta información es centralizada en Project Server, y a partir de él pueden obtenerse múltiples reportes y métricas de gestión.Por otro lado, ya entrando en la integración, para poder lograrla es importante entender cómo funciona la integración entre ambos productos. En primera instancia, se genera un Enterprise Plan en Project server con una serie de requerimientos o tareas que el Project Mananger desea comunicar al equipo. Estos requerimientos son publicados a Project Server y procesados en él. La herramienta de sincronización entonces, tomará estos cambios y los replicará a TFS para poder generar en él los workitems necesarios para su seguimiento en esta herramienta. Una vez en TFS, estos requerimientos convertidos en workitems, son analizados por el equipo de desarrollo y define las diversas tareas necesarias para su implementación. Estas tareas son asignadas y luego la herramienta de sincronización toma estas modificaciones para publicarlas en Project Server. Envía las actualizaciones de estado a Project Server, y éste las aplica a los Enterprise Plan correspondientes, previa autorización de los Project Managers. Luego se recalculan en Project Server las fechas, esfuerzos, etcétera y se publican los cambios al plan.Por lo tanto, la sincronización es bidireccional ya que se envía información desde Project Server a TFS y desde TFS a Project Server.
- Para realizar la integración entre los productos, es primero necesario instalar determinados componentes en los servidores de Project y TFS. Es importante notar, que para poder contar con el componente de integración entre Project Server y TFS, es necesario contar con una subscripción de MSDN para Visual Studio Ultimate. De no ser así, no se podrá bajar el componente desde el sitio de descargas de partners.
- El proceso en general para lograr la integración es el que se muestra en la figura.Primero es necesario tener los productos instalados y actualizados según las versiones que comenté anteriormente, para poder luego dar los permisos necesarios. Luego, es necesario registrar las instancias de Project Web Access con TeamFoundation. Después se define el mapeo de los campos que se sincronizarán, indicando los tipos de workitems y los campos a sincronizar. Luego se deben asociar los Proyectos con los TeamProjects que estarán sincronizados. Y para finalizar, es necesario que los usuarios que estarán trabajando estén definidos como recursos de Project Server y que a sus vez sean Contributors en TFS
- El mapeo entre Project Server y TFS es realizado en 4 niveles. Estos mapeos son realizados por medio de una aplicación de consola.<CLICK>Primero se debe mapear una instancia de Project Web Access con un TeamFoundation Server. Si la instalación de Project Server tuviera más de una instancia de PWA, se pueden mapear múltiples instancias con un único TeamFoundation Server<CLICK>Luego se deben mapear las instancias de PWA con una o más Team Project Collections. No es posible mapear una Team Project Collection con más de una PWA.<CLICK> Después cada proyecto dentro de la PWA, puede ser mapeado con un Team Project. Es importante destacar que más de un proyecto en PWA puede ser mapeado con un Team Project, pero no un mismo proyecto con varios TeamProjects.<CLICK>Luego es necesario mapear los tipos de workitems y campos que se estarán sincronizando. Para esto, se utiliza un archivo XML que contiene la definición del mapeo de los campos. Puede indicarse cómo un campo es sincronizado, qué campos se muestran en el tab Project Server del workitem. Por default el componente de integración ya trae definidos mapeos de campos de esfuerzo, tipo de workitem, asignaciones, etc. Pero es posible definir campos custom para el mapeo entre los productos.
- Una vez que la integración está realizada, algunos cambios ocurren en los productos. En Project, al abrir un proyecto que está integrado, se podrán ver columnas que definen la integración. Por ejemplo la columna “PublishtoTeam Project” indica si la tarea en particular será sincronizada con TFS. Si este atributo está negado, no se enviará a TFS y sólo podrá ser visible en Project. Adicionalmente, se puede indicar qué tipo de workitem corresponderá a la tarea en TFS. Esto es importante, porque por ejemplo una tarea en Project de alto nivel, puede ser considerada como un Requerimiento en TFS, del cual se desglosarán luego tareas. De esta manera, en project se mapean como Requerimientos y luego en TFS el equipo de desarrollo asignará las tareas correspondientes para cada uno de los requerimientos. Y si estuviera mapeado el workitem de tipo Task con Project Server, al crear las tareas en TFS se sincronizarán con Project y se mostrarán en el cronograma. <CLICK>Mientras tanto, en TFS, en el formulario del workitem se agrega un tab adicional para los workitems que están mapeados. En este tab se muestra la información relativa a la sincronización y al estado de la sincronización. También puede indicarse si el workitem será enviado a Project Server, de manera que pueda ser sincronizado por el motor. Este tab es importante a la hora de detectar errores de sincronización. Los campos de Status indican datos importantes para saber si el workitem fue correctamente sincronizado o no.
- Como conclusiones entonces, podemos decir que el uso integrado de estos 2 productos resulta muy útil para los escenarios en que se manejan grandes portfolios de proyectos. Ayuda a tener una mejor visualización del uso de los recursos, como así también permite que cada perfil pueda trabajar con las herramientas más convenientes. Adicionalmente, se cuenta con la suficiente flexibilidad como para poder ser selectivo a la hora de elegir qué proyectos trabajarán de esta manera y qué cosas se sincronizarán.Como punto importante, está la necesidad de contar con una licencia específica para poder bajar el conector.
- El escenario que sigue es el caso en que quizás ya se encuentra definida una forma de trabajo, con artefactos, workflows, procesos, etc. y queremos lograr la adaptación de TFS a este escenario. También es posible que ya se haya venido trabajando con alguno de los templates de procesos que vienen por defecto en la herramienta, pero el equipo de trabajo va madurando su metodología y esto implica que deba ir cambiando algunos de sus artefactos.
- En TFS, un proyecto es creado a partir de lo que se llama un Template de Procesos. Este template, define los artefactos que se utilizarán, grupos y permisos, template del sitio de Sharepoint asociado al proyecto, reportes, consultas, etc. Es factible contar con múltiples templates, por lo tanto, si trabajamos con distintos tipos de proyectos y para cada uno de ellos necesitamos contar con artefactos distintos, es posible crear distintos templates de procesos. Esto por ejemplo es útil, cuando estamos en escenarios en que se manejan proyectos de tipo llave en mano y de mantenimiento. En estos tipos, quizás se utilicen artefactos distintos, con workflows distintos. Por lo tanto es útil poder contar con la flexibilidad de definir qué tipo de proceso se usará en el proyecto.
- Por otro lado, TFS nos provee flexibilidad a la hora de definir los templates de procesos con los cuales se crean los teamprojects. Por medio de la edición de un template de procesos, podemos definir y crear nuevos templates para los distintos tipos de proyectos que tenemos en nuestra organización.Los puntos que pueden ser adaptados en el template se muestran en esta imagen. Como verán, podemos adaptar por ejemplo las áreas e iteraciones que se definen de manera default para un proyecto, el mapeo de los campos default con Project Server, tal como vimos anteriormente. También se pueden definir los grupos default que existirán a la hora de crear un nuevo proyecto y qué permisos tiene cada uno de ellos. Se pueden definir los distintos tipos de workitems como UserStories, Tareas, Bugs, etc., junto con las consultas sobre ellos que aparecerán por default en el Team Explorer. Es posible también definir algunos workitems iniciales, por ejemplo para los casos en que por los procesos definidos ya se sabe que se tienen que realizar determinadas tareas tales como la creación un projectcharter, un plan de configuración, plan de testing, reunión de kickoff, etc. Esto es de mucha ayuda para brindar la orientación inicial en el comienzo del proyecto a todo el equipo.En cuanto al portal de Sharepoint, es posible definir cuál será el template de sitio que se generará, incluyendo cuales son las documentlibraries que se crearán, los grupos de usuarios, dashboards que se mostrarán, etc. Esto es útil para poder contar rápidamente con un sitio de proyecto totalmente funcional desde el minuto cero del comienzo del proyecto.Para realizar todas estas adaptaciones, se cuenta con un editor de procesos que puede ser utilizado desde Visual Studio. Por medio de esta herramienta, se pueden adaptar todos estos artefactos que he mencionado.En la siguiente demo, veremos algunos de estas herramientas para que pueda verse más claramente qué cosas pueden ser modificadas.
- Como conclusiones entonces, hemos visto que se cuenta con herramientas para poder ajustar la metodología a emplear. Esto luego es utilizado para generar los proyectos en que trabajarán los equipos, que a su vez pueden modificar los artefactos que utilizarán.Este template permite definir múltiples aspectos, tales como los artefactos a utilizar, templates de sitios de proyecto, grupos de usuarios y permitos, e incluso definir tareas por default que podrán ser luego utilizadas por el equipo. Esto es muy útil para definir inicialmente la forma de trabajo unificada de los equipos y que luego los equipos puedan ir adaptando en base a la evolución de su trabajo.