Frecuentemente, luego de codificar en Visual Studio y efectuar el check-in correspondiente empleando Team Foundation Server (TFS) para el control de versiones, necesitamos hacer un rollback de los cambios realizados. El propósito de este post es el de presentar distintas alternativas para realizar un rollback de un changeset completo en Visual Studio.
La extensión de Visual Studio Team Foundation Server Power Tools añade un nodo en la ventana de Team Explorer que nos permite identificar a las personas que participan en un Team Project y por ejemplo organizarlos en sub equipos.
Desde este nodo, se puede colaborar con otros miembros del equipo por medio de mensajería instantánea y correo electrónico, además de contar con otras funciones relacionadas con el Team Foundation Source Control como ver historial, archivos en estado de checkout y shelveset.
En este post veremos como configurar Lync como proveedor de mensajería instantanea en el nodo de Team Member.
Las bases de datos son un componente crítico para la mayoría de las aplicaciones que solemos construir. Históricamente se han administrado con herramientas y/o procesos distintos a las que se utilizan para el desarrollo de software. Esto, en mayor o menor medida, siempre ha sido un problema en el ciclo de vida de una aplicación.
Durante la construcción de una aplicación, un desarrollador se encuentra más de una vez con la situación de tener que hacer cambios en la base de datos por alguna modificación que se realiza en el código. Obviamente que la importancia de esta situación cambia significativamente si la aplicación ya está implementada en un entorno productivo.
Soluciones a estos problemas las hay de las más variadas, desde las menos elegantes hasta las que más se asemejan a algo organizado, simple, prolijo y eficiente.
¿Quién no soñó alguna vez con estar trabajando en un proyecto de desarrollo de software donde el código fuente nunca esté roto en el repositorio de código? Y nunca tener que pasar por el feo momento de ver que el proyecto no compila y al buscar qué fue lo que pasó darse cuenta que un check-in propio fue el que lo rompió, teniendo así que soportar la mala cara del resto de los integrantes del equipo. Y digo “mala cara” en el mejor de los casos, porque nos pueden tocar equipos hostiles con prendas realmente complicadas para el “rompedor del build”. En mi caso con una torta de ricota o un par de docenas de facturas para el equipo es suficiente. Por suerte, entre las varias nuevas características de Team Foundation Server 2010 existe una muy buena para no tener que pasar por este problemita nuevamente y así evitarnos muchos dolores de cabeza.