Aumentando la granulariad de las políticas en Team Foundation Server

Una necesidad que nos surge a menudo cuando establecemos políticas en Team Foundation Server, es establecer diferentes póliticas a diferentes proyectos o incluso a diferentes partes de un proyecto. Las motivaciones de esta necesidad pueden tener su origen en diferentes apectos, por ejemplo en partes de nuestro proyecto sometidas a fuerte investigación nos puede interesar relajar algunas de las politicas. O en partes más sensibles a seguridad por ejemplo nos puede interesar establecer unas politicas propias más fuertes.

Para aquellos que no estén familiarizados, las políticas que por defecto nos proporciona Team Foundation Server son:

Análisis de código (Code Analysis): Esta política obliga a ejecutar un análisis de código antes de poder subir las fuentes al gestor de fuentes.

Política de pruebas (Testing Policy): Asegura que las pruebas especificadas en unas determinadas listas de pruebas (asociadas a la política) se ejecutan satisfactoriamente antes de poder integrar el código en el gestor de fuentes.

Elementos de Trabajo (Work Items): Exije que los antes de subir cambios al gestor de fuentes, estos se asocien con uno o varios.

Volviendo a lo que nos ocupa, aplicar diferentes políticas a diferentes partes de nuestro proyecto, debemos saber que no es algo que Team Foundation Server nos permita por defecto, para ello debemos instalar TFS Custom Path CheckIn Policy.

La política Custom Path CheckIn Policy trabaja con las políticas existentes en Team Foundation Server y proporciona un mecanismo que permite especificar que políticas se aplican a cada carpeta del gestor de fuentes. Tambien permite filtrar a que archivos (por extensión se aplicarán las políticas), por ejemplo para forzar un Work Item relacionada cuando se haga Check In de un archivo *.vb, *.cs, o *.*proj. Además como esta pólitica se distribuye como código fuente es un excelente ejemplo de como implementar una.

En cualquier caso, mi recomendación es utilizar esta herramienta para establecer políticas más ferreas para ciertas partes y no para relajar las políticas de algunos componente del proyecto.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *