Introducción

Otra de las características que ofrece TFVC y que no ofrecen otros repositorios son las políticas y notas de protección (chek-in policies / check-in notes). Estas políticas son una serie de reglas que se definen a nivel de Team Project y que son de obligado cumplimiento antes de depositar código en el repositorio. De esta forma se puede asegurar un nivel de calidad mínimo en el código que existe en el repositorio.

Configuración

La forma de activar las check-in policies y las check-in notes para un Team Project es sencilla, el único problema que puede surgirnos es que a nivel de permisos no pudiésemos hacerlo. Aun no hemos tocado el tema referente a la administración de seguridad en Team Foundation Server, pero solo para que lo tengáis en cuenta, para ser capaz de habilitar/deshabilitar políticas y las notas de protección para un Team Project debéis tener el permiso "Edit project-level información", que normalmente suelen tener los administradores de Team Projects y los administradores de TFS. Bueno, salvando este tema relacionado con la seguridad, estas reglas se administran de forma visual desde el IDE de Visual Studio y es necesario tener el Team Explorer instalado.

Accedemos al menú Team que nos aparece en Visual Studio y desde ahí, Team Project Settings >> Source Control. Una vez hayamos abierto la ventana de configuración de control de código fuente tenemos tres pestañas, la primera nos permite establecer la configuración de las desprotecciones, pero hablaré de los modos de trabajo contra el repositorio que nos ofrece TFS mas adelante en esta serie de posts dedicados al control de versiones.

Para el ámbito en el que nos encontramos las opciones que nos interesan son las dos siguientes, Check-In Policy y Check-In Notes. Desde Check-In Polcies podemos realizar varias acciones administrativas sobre las políticas de nuestro Team Project como añadir, editar, quitar, habilitar y  deshabilitar políticas de protección.

Las políticas que vienen acompañando a Team Foundation Server 2005 son tres, Code Analysis, Testing Policy y Work Items, y en la versión 2008 se ha añadido una politica nueva llamada Builds. Ahora veremos más en detalle para que sirve cada una de ellas, aunque los nombres no dejan muchas dudas acerca de para qué sirven.

• Code Analysis: Permite configurar una gran cantidad de normas de análisis estático de código. Esta política se basa en la versión de FxCop que va integrado en Visual Studio desde la versión 2005 y de esta forma se asegura que el código cumple una serie de reglas.

• Testing Policy: Obliga a que se hayan pasado las pruebas unitarias antes de proteger el código fuente en el repositorio.

• Work Items Policy: Hace que sea necesario asociar el changeset a un Work Item cuando se está protegiendo el código fuente.

• Builds: Detiene el check-in de ficheros si la ultima build lanzada en el servidor falló. Esta politica solo aplica si se tiene configurado el entorno con integración continua.

A pesar de ser solo tres las políticas que vienen con TFS (cuatro en el caso de TFS2008) aportan un gran valor a la hora de tener un repositorio de código homogéneo y con un nivel de calidad mínimo. Por otro lado una de las ventajas de Team Foundation Server no solo es que posee estas políticas Out-of-the-box sino que dado por como está hecho tiene unas capacidades de extensión increíbles y existen más políticas de protección creadas por el propio Microsoft y por gente que contribuye a la comunidad.

En cuanto a las check-in notes, no hay muchas diferencias con las check-in policies, solo que estas no están tan enfocadas al código en sí, sino a ofrecer información sobre el mismo. Por defecto existen también tres notas de protección que deberían ser rellenadas por los revisores de código, seguridad y rendimiento en caso de que se marquen como requeridas y existe la posibilidad de crear cuantas notas de protección queramos de una forma visual y sencilla sin necesidad de programar.

Uso de las políticas

Las políticas no requieren de ninguna acción adicional por parte de cada integrante del equipo para ser usadas, solo que el administrador las haya configurado y habilitado. Esta serie de reglas que debemos cumplir son comprobadas de forma automática cuando nos disponemos a proteger código en el repositorio. En caso de que no se cumpla alguna de las reglas establecidas por las políticas se muestra una lista indicando porque no se ha pasado para que revise el fallo y se corrija.

En definitiva, las políticas y las notas de protección nos ayudan a tener un repositorio de código con unos mínimos de calidad que definamos.