Introducción
Microsoft ha iniciado la retirada de las políticas de check-in heredadas de Team Foundation Version Control (TFVC) en Azure DevOps. Según el anuncio publicado en el blog oficial de Azure DevOps, estas políticas antiguas se consideran obsoletas por limitaciones en la forma en que estaban implementadas y almacenadas.
El punto importante para los equipos que aún usan TFVC es operativo: durante la fase actual todavía es posible reemplazar las políticas obsoletas desde Visual Studio Team Explorer. Sin embargo, cuando finalice la transición, las políticas heredadas que sigan configuradas podrán bloquear los check-ins de todos los usuarios del repositorio y dejar de ser visibles o administrables desde Team Explorer.
Este artículo resume qué revisar, cómo planificar la sustitución y qué precauciones tomar para evitar interrupciones en los flujos de trabajo de TFVC.
Contexto: qué cambia en las políticas de check-in de TFVC
Las políticas de check-in de TFVC permiten aplicar reglas antes de aceptar un check-in en el repositorio. Se han usado tradicionalmente para reforzar prácticas como:
- exigir un comentario en el check-in;
- asociar cambios a work items;
- aplicar validaciones definidas por el equipo;
- ejecutar políticas instaladas en el cliente de Visual Studio.
La retirada anunciada no significa que desaparezca TFVC ni todas las políticas de check-in. El cambio afecta a las políticas heredadas marcadas como obsoletas. Microsoft indica que estas políticas pueden reemplazarse seleccionando la política actualizada equivalente.
La recomendación práctica es no esperar al bloqueo final: hay que revisar cuanto antes los repositorios TFVC que todavía dependan de políticas antiguas y sustituirlas mientras siguen siendo administrables desde Team Explorer.
Riesgo principal: bloqueo de check-ins
El riesgo no es solo administrativo. De acuerdo con el aviso oficial, cuando se complete la fase final de la transición:
- las políticas obsoletas restantes podrán bloquear los check-ins de los usuarios del repositorio;
- esas políticas dejarán de ser visibles o gestionables desde Visual Studio Team Explorer;
- si un repositorio queda en ese estado, será necesario recurrir a un fragmento de código C# indicado por Microsoft para retirarlas.
Por tanto, la acción recomendada es hacer la limpieza antes de que el repositorio entre en una situación en la que ya no pueda resolverse únicamente desde la interfaz habitual de Team Explorer.
Cómo identificar políticas obsoletas
La revisión debe hacerse desde el entorno en el que se gestionan las políticas de check-in de TFVC: Visual Studio Team Explorer.
Un procedimiento razonable para los administradores del proyecto es:
- Abrir Visual Studio con una cuenta que tenga permisos para administrar el proyecto o el repositorio TFVC.
- Conectarse al proyecto de Azure DevOps correspondiente desde Team Explorer.
- Revisar la configuración de Source Control y las políticas de check-in configuradas para TFVC.
- Localizar políticas marcadas como obsoletas o que muestren avisos relacionados con cumplimiento o configuración no compatible.
- Documentar qué política está configurada, en qué proyecto o rama aplica y qué regla funcional está cubriendo.
Microsoft también indica que, durante la fase actual, al intentar hacer check-in puede aparecer una notificación señalando que la configuración no cumple los requisitos porque todavía usa políticas obsoletas. Ese aviso debe tratarse como una señal de prioridad, no como un simple mensaje informativo.
Plan recomendado de sustitución
Antes de eliminar una política heredada conviene entender qué comportamiento estaba garantizando. En muchos equipos, estas reglas forman parte del proceso de calidad o trazabilidad, y quitarlas sin sustitución puede degradar el flujo de trabajo.
Una secuencia segura sería:
-
Inventariar las políticas existentes
Anotar nombre, propósito, ámbito y equipos afectados. -
Identificar la política actualizada equivalente
El anuncio de Microsoft indica que las políticas obsoletas pueden reemplazarse seleccionando la política actualizada equivalente desde Team Explorer. -
Validar el comportamiento esperado
Probar que la nueva política mantiene la regla funcional necesaria: comentario obligatorio, work item asociado u otra validación definida por el equipo. -
Comunicar la ventana de cambio
Informar a los equipos que trabajan con TFVC, especialmente si usan Visual Studio y procesos de check-in integrados. -
Retirar la política obsoleta
Una vez confirmada la política equivalente, eliminar la configuración heredada. -
Hacer pruebas de check-in
Probar escenarios válidos e inválidos para confirmar que el repositorio acepta y rechaza cambios según lo esperado.
Ejemplo de revisión: política de comentario obligatorio
Supongamos que un equipo tiene configurada una política que exige comentario en cada check-in.
La revisión debería centrarse en estas preguntas:
- ¿La política actual aparece marcada como obsoleta?
- ¿Existe una política actualizada equivalente disponible en Team Explorer?
- ¿La política nueva exige el comentario con el mismo criterio que la anterior?
- ¿Los usuarios reciben mensajes comprensibles cuando intentan hacer check-in sin comentario?
- ¿Hay automatizaciones o documentación interna que mencionen la política antigua?
El objetivo no es cambiar la regla de proceso, sino moverla desde la implementación heredada a la versión soportada.
Ejemplo de revisión: asociación con work items
Otro caso habitual es exigir que los cambios estén relacionados con work items para mantener trazabilidad entre código y planificación.
Antes de eliminar una política heredada de este tipo, conviene comprobar:
- si la política actual está marcada como obsoleta;
- qué política equivalente está disponible;
- si el check-in se bloquea correctamente cuando no hay work item asociado;
- si el equipo necesita ajustar su guía de trabajo para desarrolladores;
- si hay ramas o proyectos TFVC con configuraciones distintas.
La prueba mínima debería incluir dos check-ins controlados:
- Un check-in que cumpla la regla, para validar que no se bloquea indebidamente.
- Un check-in que incumpla la regla, para confirmar que la política se aplica correctamente.
Qué hacer si las políticas ya no son administrables desde Team Explorer
Microsoft advierte que, tras la fase final, las políticas obsoletas que queden configuradas dejarán de ser visibles o administrables mediante Visual Studio Team Explorer. En ese escenario, el repositorio puede quedar bloqueando check-ins y requerir una eliminación mediante un fragmento de código C# proporcionado por Microsoft.
La recomendación es:
- no improvisar código propio para modificar configuraciones de TFVC;
- seguir el procedimiento oficial publicado por Microsoft;
- ejecutar la acción con una cuenta con permisos adecuados;
- probar primero en un entorno o proyecto controlado si es posible;
- documentar qué políticas se han eliminado y por qué.
Si todavía es posible gestionarlas desde Team Explorer, es preferible resolverlo por esa vía antes de llegar al escenario de recuperación.
Lista de comprobación para administradores
Antes de dar por cerrada la migración, revisa estos puntos:
- Se han identificado todos los proyectos que usan TFVC.
- Se han revisado las políticas de check-in desde Visual Studio Team Explorer.
- Se han localizado políticas marcadas como obsoletas.
- Cada política obsoleta tiene una política actualizada equivalente o una decisión documentada.
- Se han realizado pruebas de check-in con escenarios válidos e inválidos.
- Los equipos afectados han sido informados del cambio.
- Se ha documentado la configuración final.
- No quedan avisos de configuración no compatible al hacer check-in.
Recomendaciones prácticas
Para reducir riesgos, conviene tratar esta retirada como una pequeña migración de configuración, no como una simple tarea de limpieza.
Algunas recomendaciones:
- Prioriza los repositorios activos: empieza por los proyectos TFVC con actividad diaria.
- Coordina con los responsables de proceso: algunas políticas reflejan requisitos de auditoría o trazabilidad.
- Evita eliminar sin sustituir: si una política garantizaba una regla importante, configura primero la alternativa soportada.
- Prueba con usuarios reales: valida el comportamiento desde Visual Studio, que es donde se ejecutan estas políticas de check-in.
- Documenta la configuración final: facilitará futuras revisiones y soporte.
Conclusión
La retirada de políticas de check-in obsoletas en TFVC es un cambio relevante para organizaciones que aún mantienen repositorios TFVC en Azure DevOps. El impacto puede ser directo: si las políticas heredadas permanecen configuradas cuando finalice la transición, los usuarios podrían quedar bloqueados al intentar hacer check-in.
La mejor estrategia es revisar ahora la configuración desde Visual Studio Team Explorer, sustituir cada política obsoleta por su equivalente actualizado y validar el comportamiento antes de eliminar la versión heredada.