Al igual que Glennular, los estamos utilizando para controlar la versión de nuestro esquema y s'procs.
Aunque tenemos una estructura de control de versiones bastante avanzada (CI, implementaciones automáticas para desarrollo, despliegues de un solo clic en el escenario y prod); no incluimos ninguno de los proyectos de DB en esa estructura. Simplemente no confiamos todavía.
ACTUALIZACIÓN: (para Out In Space)
Tenemos proyectos TFS separados para las áreas funcionales de la empresa (ventas, marketing, etc.). Dentro de cada proyecto TFS tenemos una carpeta Principal y de Producción. También tenemos un proyecto TFS que contiene los proyectos de la base de datos y otro que contiene ensambles comunes/proyectos de estudio visual.
Al momento de la publicación, pasamos de Principal a Producción. No tenemos una rama de etapas ya que nos movemos demasiado rápido para lidiar con eso.Correcto o incorrecto, nuestra productividad se mide en parte por la cantidad de lanzamientos de nivel de producción que hacemos por semana; correcciones de errores, nuevas características, etc.
CI se configura en la rama Principal de forma tal que cada verificación provoca que el servidor de compilación se despliegue en nuestros entornos DEV. Las pruebas de unidad y web se ejecutan y la calidad de construcción se establece automáticamente en "Desarrollo" si se completa con éxito. Cuando alguien cambia la Calidad de compilación a "En etapas" Esto hace que las compilaciones anteriores "En etapas" se configuren como "Rechazadas" y hace que esa compilación se envíe a nuestros servidores de transición mientras se actualizan los archivos de configuración para apuntar a los servidores correctos. (Utilicé scripts de TFS Deployer y PowerShell para esto).
QA hace pruebas en nuestros servidores de almacenamiento intermedio. Una vez que están contentos, el equipo de producción cambia la calidad de construcción a "producción". Esto hace que la construcción se envíe a un área de producción que luego se copia manualmente en la ubicación correcta. Una vez completada, la producción notifica al desarrollo quién luego ramifica esa versión en la carpeta de Producción. También se notifica a QA quién realiza una batería de pruebas de producción para verificar que todo funcione correctamente.
Tenemos informes configurados para mostrarnos los cambios que existen entre lanzamientos de producción para que sepamos cada control que se está implementando. Eso evita que aparezcan incógnitas, como un cambio de base de datos, etc. o algún otro código de interrupción.
Además, nuestros BA's están rastreando elementos de trabajo a través de Team System Web Access y saben cuándo están en producción.
Aunque nuestros DBA están utilizando Database Edition (GDR), no les ha impresionado el nivel de control de las implementaciones automáticas. Espero que Rosario traiga un mejor control de implementación a la línea de productos; pero hasta entonces tenemos TFS Deployer y powershell.
Shog deberías retroceder en el comentario sobre la comparación de los esquemas, esta es una pieza clave de datos y decirme que no está usando VS Data Dude. – JoshBerke
Se ve mejor gracias ;-) – JoshBerke