Tener un equipo de desarrolladores trabajando en la misma base de datos (compartida) puede ser desafiante por muchas razones. Es crítico asegurar que todos los cambios están apropiadamente rastreados y que cada desarrollador está informado acerca del estado de los objetos actualmente usados por el resto del equipo. Cuando se usa una base de datos compartida, todos los cambios serán aplicados contra la base de datos antes que sean enviados al repositorio.
Desafío
El objetivo es tener un equipo de desarrolladores trabajando en una sola base de datos hospedada en SQL Server usando el modelo de desarrollo de bases de datos compartido. Todos los desarrolladores deben poder comunicarse con el repositorio (insertar cambios desde la base de datos, y extraer (aplicar) cambios desde el repositorio a la base de datos).
Para evitar sobrescribir cualquier cambio, la solución debe incluir presentaciones en tiempo real de estados de objeto, por ejemplo, desprotegido, bloqueado o editado.
La solución debería proveer un mecanismo para reforzar una metodología compartida apropiada de desarrollo de bases de datos, lo que significa que el conjunto de reglas puede ser establecido para ser seguidas por el resto del equipo. Particularmente, si la regla es para desproteger un objeto antes de editar, la solución debe incluir un mecanismo para prevenir que cualquier desarrollador edite un objeto antes de desprotegerlo.
Adicionalmente, todos los cambios enviados al repositorio deben poder accederse fácilmente y revertidos/aplicados contra la base de datos.
Requerimientos
Cada desarrollador debe tener una instancia de SQL Server Management Studio separada. Una instancia de SQL Server separada no es requerida, ya que la base de datos compartida está hospedada en un solo servidor donde todos los desarrolladores tienen acceso.
Solución
Implementando el modelo compartido
ApexSQL Source Control es un complemento para SQL Server Management Studio, ofrece la posibilidad a los equipos para implementar un modelo de desarrollo de base de datos compartido, y establecer un conjunto de reglar para evitar sobrescribir cambios hechos por otros.
Implementar el modelo compartido usando ApexSQL Source Control permite al equipo configurar el ambiente donde los cambios pueden ser presentados en tiempo real.
Para enlazar una base de datos, haga clic derecho en ella en el panel Object Explorer y elija la opción Link database to source control del menú ApexSQL Source Control:
En el primer paso del asistente, elija el sistema de control de código fuente que será usado y asegúrese de que la opción Shared database está seleccionada:
Cuando se usa el modelo compartido, ApexSQL Source Control ofrece una opción para elegir una base de datos donde objetos adicionales serán creados. Por defecto, la base de datos donde estos objetos serán creados es la misma que está siendo enlazada al control de código fuente. De todas maneras, esto puede ser cambiado eligiendo otra base de datos que debe estar hospedada en el mismo servidor SQL Server. Un desencadenador DDL de base de datos será creado en la base de datos que está enlazada a un control de código fuente, y el resto de los objetos (procedimientos almacenados y tablas) pueden ser creados en una base de datos separada.
En el siguiente paso, todos los objetos de la base de datos SQL que serán añadidos al control de versión deberían ser desprotegidos. Por defecto, ApexSQL Source Control incluye todos los tipos de objetos soportados y las instancias de objetos de la base de datos en el proceso de control de versión:
El paso final es especificar las credenciales de repositorio y la localización exacta del repositorio:
Haciendo clic en el botón Finish, ApexSQl Source Control creará los previamente mencionados objetos adicionales en la base de datos seleccionada y codificará todos los objetos de base de datos SQL en el proceso de integración de control de código fuente SQL. Una vez que todos los objetos estén codificados, ApexSQL Source Control compara los objetos codificados (el estado actual en la base de datos) con el estado actual en el repositorio, y muestra diferencias en la pestaña Action center. En caso de un envío inicial a un repositorio vacío, el lado izquierdo de la pestaña Action center muestra todos los objetos desde la base de datos, y el lado derecho no muestra objetos ya que representa un repositorio vacío:
Cuando se trabaja con el modelo compartido, es suficiente que el primer desarrollador que enlaza la base de datos realice el envío inicial. El resto del equipo sólo necesitará enlazar la misma base de datos desde sus máquinas, y la pestaña Action center muestra que no hay diferencias (nada para enviar):
Desde el momento cuando el último desarrollado enlaza la base de datos a cada repositorio, el modelo compartido está implementado. Desde ahora en adelante, cada cambio puede ser rastreado y todo el equipo estará al corriente si cualquier miembro del equipo está trabajando en el mismo objeto.
Estados de objeto desprotegido (check out) y bloqueado (lock)
La opción Check out significa que un desarrollado desea trabajar en un objeto y desprotegiéndolo el resto del equipo será visualmente informado de que el objeto está “en uso” cambiando los íconos en el explorador de objetos para incluir un símbolo de desprotegido (ver la imagen a continuación). Para desproteger un objeto, haga clic derecho en él en el panel Object Explorer y desde el menú ApexSQl Source Control seleccione la opción Check out:
El ícono del objeto será actualizado para representar el estado de desprotegido:
El resto del equipo será informado, ya que el ícono cambiará también:
El mismo mecanismo será aplicado cuando se bloquee un objeto, La única diferencia entre Lock y Check out es que el bloqueo no puede ser anulado. Esto significa que si un objeto está desbloqueado, otro usuario será informado de que el objeto está desbloqueado, pero podrá anular la operación de Check out. Un Lock, por otro lado, no puede ser anulado, y el desarrollador que bloqueó un objeto es el único que puede desbloquearlo ya sea eligiendo la opción Undo check out/lock desde el menú ApexSQl Source Control o enviando los cambios hecho contra el objeto bloqueado.
Esto sirve para informar al equipo acerca del estado del objeto y, si es necesario, evitar que cualquier persona edite el objeto, en caso de que esté bloqueado.
Aparte de los íconos de objetos en el panel Object Explorer, todo el equipo puede revisar el estado de cualquier objeto en el formulario Object status Esto puede ser hecho haciendo clic en la opción Object status desde el menú ApexSQL Source Control:
Registro de cambios
Desde el momento en que se habilita la característica Logging en las opciones de ApexSQl Source Control, cada cambio hecho por cualquier desarrollador del equipo será registrado:
En caso de que alguien edite un objeto, pero olvide enviar los cambio, la característica Logging ayudará a encontrar quién editó qué objeto y cuándo. Todos los cambios son accesibles en el formulario Change log:
Reforzando una metodología de desarrollo apropiada
Aplicando políticas de bases de datos, el equipo puede introducir una metodología de desarrollo apropiada en términos de reforzar el conjunto de reglas a ser seguido. Las políticas de bases de datos pueden ser administradas desde las opciones de ApexSQL Source Control:
Por defecto, la política Optional está establecida, lo que significa que cualquier desarrollador puede editar cualquier objeto sin necesidad de realizar un Check out o Lock. Cambiando la política a Permissive o Restrictive, cada miembro del equipo será forzado a poner un objeto en Check out o Lock respectivamente, para editarlo.
Historial del proyecto
Justamente como en el modelo dedicado, el historial de todos los envíos puede ser accedido desde el formulario Project history:
Aparte de la lista de cambios enviados y la lista de objetos para cada envío, ApexSQL Source Control muestra diferencias línea por línea en el panel Differences, en la parte inferior del formulario Project history. La versión de un objeto desde el envío seleccionado puede ser comparada a cualquier otra versión en el mismo objeto incluyendo la versión actual desde la base de datos. Haciendo clic en el botón Get, la versión desde el envío seleccionado será aplicada contra la base de datos.
De esta forma, cada cambio enviado puede ser fácilmente revertido y aplicado contra la base de datos.
Traductor: Daniel Calbimonte
agosto 16, 2016
