Tener una base de datos SQL Server bajo control de fuente se está convirtiendo rápidamente en la norma versus la excepción en muchos equipos de desarrollo de software. Usar cualquier modelo de desarrollo (dedicado o compartido), requiere que el equipo establezca un flujo de trabajo un conjunto de reglas. El modelo dedicado permite al desarrollador actuar como una parte independiente del proceso principalmente en el caso de que el servidor/repositorio esté abajo. En este caso, el equipo puede continuar trabajando sin obstáculos. Este artículo se enfocará en usar el modelo de desarrollo dedicado para el control de código fuente en SQL Server.
Desafío
Implementar un modelo de desarrollo de base de datos de manera que cada desarrollador tendrá una copia separada de la base de datos (copia funcional), y todos los cambios serán aplicados a la copia funcional (probada si es necesario), antes de enviar los cambios al repositorio central, es un asunto clave.
Un problema que no puede ser evadido, en este modelo, es cuando un conflicto ocurre cuando se envía un cambio al repositorio. Por lo tanto, tener un mecanismo apropiado para detectar y resolver conflictos es crucial. Los conflictos deberían ser detectados en caso de que ninguno de los miembros del equipo trabaje con la última versión de un objeto del repositorio.
En caso de que el repositorio central esté desconectado o inaccesible, el resto del equipo puede seguir trabajando localmente. Con esta habilidad para sincronizar cambios locales, una vez que el repositorio esté en línea de nuevo, la continuidad en el proceso de desarrollo puede ser mantenido.
Requerimientos
Cada desarrollador debe tener SQL Server Management Studio instalado en una máquina local. Tener una instancia separada de SQL Server en cada máquina de los desarrolladores también es recomendado.
La solución debe incluir un mecanismo de resolución de conflictos, asegurando que todos los desarrolladores están conscientes de los cambios hechos por el resto del equipo.
En adición a esto, la solución debe asegurar que cada miembro del equipo pueda trabajar independientemente, y que no sea afectado por el resto del equipo.
Solución
Implementando un enfoque de modelo dedicado
ApexSQL Source Control es un complemento para SQL Server Management Studio que ofrece la posibilidad de enlazar una base de datos al control de código fuente usando el modelo de desarrollo dedicado. Esto permitirá a los desarrolladores trabajar independientemente en máquinas separadas.
Para enlazar una base de datos, haga clic derecho en ella en Object Explorer y desde el menú de ApexSQL Source Control elija la opción Link database to source control :
En el primer paso del asistente, seleccione el sistema de control de código fuente que será usado y asegúrese que la opción Dedicated database está seleccionada:
En el paso Object filtering incluya objetos que estarán bajo control de versión . Por defecto, todos los tipos de datos soportados e instancias de objeto son incluidos en el control de versión:
El último paso es especificar las credenciales del repositorio y una ruta al proyecto donde la base de datos será enlazada:
Haciendo clic en el botón Finish ApexSQL Source Control inicializará el proceso de enlace. Todos los objetos previamente incluidos en el proceso de control de versión serán codificados y preparados para el envío inicial. En el mismo proceso (proceso de enlace), ApexSQL Source Control crea objetos adicionales enlazados al repositorio, para rastrear cambios más adelante.
Una vez que el proceso de enlace está completo, la pestaña Action center aparecerá, mostrando la diferencia entre la copia funcional y el estado actual del repositorio. El primer desarrollador que enlaza la base de datos necesitará incluir todos los objetos y enviarlos inicialmente al repositorio:
El resto del equipo puede tener una base de datos vacía en una máquina local que será enlazada al mismo repositorio, y la última versión de objetos que serán aplicados contra una base de datos vacía. En otras palabras, el resto del equipo construirá la misma base de datos localmente (crear una copia funcional) usando la última versión de los objetos enviados al repositorio usando ApexSQL Source Control:
Desde este punto, el modelo de desarrollo dedicado de base de datos es implementado, ya que el equipo entero tendrá la misma base de datos sincronizada con el repositorio y cualquier desarrollador puede comenzar a trabajar independientemente en la copia funcional en una máquina local.
Conflictos
Si un desarrollador comienza a trabajar en un objeto de diferente versión que la última versión del repositorio, un conflicto será detectado tan pronto como un desarrollador intenta enviar cambios. Para prevenir conflictos, es necesario revisar si la versión de un objeto es la misma en la copia funcional de la base de datos con la última versión en el repositorio. Obtener la última versión de un objeto desde el repositorio evitará conflictos. En el caso de un conflicto, ApexSQL Source Control lo detectará, y el panel Conflict resolution será mostrado directamente en la pestaña Action center :
ApexSQL Source Control no permite ninguna acción (en cualquier dirección) hasta que el conflicto esté resuelto. En una resolución de conflicto, un desarrollador puede elegir conservar los cambios locales, tomar los cambios remotos o unir los cambios.
Mantener los cambios locales sobrescribirá la última versión en el repositorio con cambios hechos contra una copia funcional de la base de datos.
Al unir los cambios, todos los cambios serán combinados en una sola selección (debajo de la sección Differences), y un desarrollador puede resolver los conflictos línea por línea, eligiendo aplicar cambios locales o remotos.
Al hacer clic en el botón Confirm, un desarrollador confirma que todos los conflictos son resueltos y que el cambio final puede ser aplicado.
Trabajo independiente y trabajo sin conexión
Si cada desarrollador está trabajando en una instancia separada de SQL Server (lo cual es recomendado), entonces si cualquier servidor SQL Server se desconecta, ningún otro desarrollador es impedido.
Si el repositorio central no es accesible por cualquier razón, el botón Working offline aparece en la pestaña Action center:
Los desarrolladores pueden continuar trabajando en la copia funcional actual, dado que todos los cambios serán grabados localmente en cada máquina, y tan pronto como el repositorio central se encuentra accesible, ApexSQL Source Control comparará y sincronizará localmente los cambios grabados con el último estado del repositorio. Esto aplica sólo a los sistemas de control de código fuente Git y Mercurial. Por otro lado, un desarrollador puede revisar manualmente si el repositorio está accesible iniciando la opción Go online:
Traductor: Daniel Calbimonte
agosto 16, 2016
