Control de versiones de bases de datos con IBM Optim Database Administrator V2.2

Mejore la colaboración y garantice una pista de auditoría

¿Alguna vez quiso saber cuándo se realizó un cambio en la base de datos? ¡Con Optim Database Administrator lo sabrá! IBMOptimDatabase Administrator (ODA) lo ayuda a seguir los cambios, trabajar sin contratiempos con otros miembros de equipos, revertir o deshacer cambios y auditar todos los cambios realizados en su base de datos. Este artículo describe un escenario donde la organización administradora de base de datos (DBA) usa ODA junto con el proyecto Eclipse Team para mejorar la colaboración y garantizar una pista de auditoría consistente. Aprenda a conectarse con un sistema de control de bibliotecas y guardar proyectos, modelos y scripts de gestión de cambios en el control de bibliotecas así como también a auditar los cambios. Además descubra cómo recuperar archivos del control de bibliotecas y usar un script de gestión de cambios para deshacer un cambio.

Nota: El presente es una actualización de un artículo ya publicado acerca de DB2 Change Management Expert, el cual fue actualizado para Data Studio Administrator en agosto de 2008. Esta versión del artículo utiliza el nuevo nombre IBM Optim Database Administrator (en vigencia desde junio de 2009) y aborda otros cambios disponibles a partir de la versión 2.2 de Option Database Administrator.

Carolyn Henry, Information Developer, IBM

Carolyn Henry photoCarolyn Henry es Information Developer del grupo DB2 and IMS Tools en el IBM Silicon Valley Laboratory en San José, California. Trabaja en el equipo de expertos en DB2 Change Management desde el año 2004.



Marcia Miskimen, Software Engineer, IBM

Marcia Miskimen photoMarcia Miskimen es Software Engineer del grupo de Information Management Tools en el IBM Silicon Valley Laboratory en San José, California. Trabaja en el área de soporte de herramientas multiplataforma desde 2003.



Jayashree Ramachandran, Developer, IBM

Jayashree Ramachandran photoJayashree Ramachandran es Developer del grupo de Information Management Tools en el laboratorio de IBM de Silicon Valley en San José, California. Trabaja en el equipo de expertos en DB2 Change Management desde 2004.



Sailaja Bandlamoori, Staff Software Engineer, IBM

Sailaja Bandlamoori photoSailaja Bandlamoori es QA Team Lead para Data Studio Administrator del grupo Information Management Data Studio en el IBM Silicon Valley Laboratory en San José, California. Trabaja en el producto Data Studio Administrator desde 2006, y antes se desempeñó en la Prueba de Sistema DB2 for z/OS client/server.



22-12-2009 (Primera publicación 22-12-2009)

Introducción

El mantenimiento de una base de datos se centra en elcambio. Es necesario garantizar que las aplicaciones de base de datos funcionen de acuerdo a lo previsto, que los cambios se implementen sin contratiempos y que, en el caso de que algo salga mal, sea posible investigar el problema. Si bien la base de datos registra algunas actividades, estos registros suelen ser complejos de analizar. En definitiva, los registros brindan una idea parcial de los cambios en las bases de datos. Entonces, ¿por qué no emplear tecnologías de desarrollo de software para contribuir en la gestión de los cambios? El enfoque tradicional del desarrollo de software efectúa el seguimiento de los cambios mediante distintos tipos de sistemas, procesos o herramientas de gestión de cambios. Este enfoque recibe distintos nombres: gestión de la configuración, gestión de cambios, control del código fuente, control de bibliotecas, control de versiones, entre otros. En este artículo emplearemos el término“control de versiones”.

El proceso de gestión de los cambios realizados sobre una aplicación o directamente sobre el código de un producto ha madurado notablemente. La mayoría de los programadores están acostumbrados a ingresar y extraer sus códigos y saben cuáles van con cada versión de software. Pero, ¿qué ocurre con los otros participantes del ciclo de desarrollo de aplicaciones? ¿Tienen conciencia de la importancia de estos factores? ¿Usan herramientas de control de versiones? ¿Y qué sucede con el diseño del arquitecto, el plan del gerente de proyecto, la documentación del escritor o los escenarios y resultados del tester? ¿Qué hay del administrador de base de datos? Una aplicación es mucho más que un código. Todas las partes que conforman una versión deberían mantenerse en armonía. Todo objeto que forme parte de la aplicación puede y debe participar en el proceso o la herramienta de control de versiones.


El proceso general

La Figura 1 ilustra el proceso general de cambio de una base de datos usando Optim Database Administrator junto con un sistema de control de versiones:

Figura 1. Proceso general de cambio de una base de datos usando Optim Database Administrator
Overall process of changing a database with Optim Database Administrator

Optim Database Administrator y Eclipse

Optim Database Administrator ayuda a las DBA a gestionar sus sistemas de base de datos permitiéndoles configurar la base de datos, realizar un seguimiento de los cambios, trabajar conjuntamente con otras DBA que aporten cambios de otra índole, auditar y gestionar el historial de dichos cambios, y revertir o deshacer todo cambio que ya no se requiera.

Optim Database Administrator se basa en Eclipse de código abierto, lo cual brinda un marco de software de plataforma independiente para proporcionar aplicaciones de clientes de alta calidad. La plataforma Eclipse permite que otros desarrolladores de herramientas construyan y proporcionen herramientas integradas con facilidad. Este marco fue utilizado para desarrollar el Integrated Development Environment (IDE) para Optim Database Administrator. Para obtener más información acerca de la plataforma Eclipse, consulte la sección de Recursos. Se utiliza la funcionalidad Eclipse Team para lograr un proceso de control de versiones exitoso dentro de Optim Database Administrator.

La integración de Eclipse Team es un componente fundamental de las capacidades de control de versiones de Optim Database Administrator. El componente Eclipse Team proporciona un mecanismo que permite que las herramientas de repositorio integren la funcionalidad completa y de alta calidad de su solución de repositorio a la estación de trabajo Eclipse. El ejemplo proporcionado en este artículo muestra la funcionalidad Eclipse Team. Para obtener más información acerca de Eclipse Team, consulte la sección de Recursos de este documento.

Después de realizar un cambio en la base de datos, el proyecto de diseño de datos (con todos los recursos contenidos en él) deberá ingresarse en el control de versiones y etiquetarse o rotularse.

También puede archivar sus proyectos Optim Database Administrator usando la capacidad Eclipse Team. Para poder seguir los cambios, deberá guardar sus proyectos. Es posible archivar durante el proceso de desarrollo del cambio e incluso antes de implementar cualquier cambio. Esto le permite trabajar en iteraciones, es decir que distintos miembros de su equipo o DBA podrán participar y aportar cambios mientras otros se ocupan de revisar y modificar los cambios realizados.


Relación entre Data Design Projects, las bases de datos y el control de versiones

El control de versiones puede usarse de distintas maneras para gestionar sus proyectos de cambios en las bases de datos. Puede optar por usar un sistema de control de versiones formal o informal. Los sistemas de control de versiones van desde los más sencillos, como el sistema de archivos de su máquina, hasta productos completamente desarrollados como Concurrent Versioning System (CVS) o IBM Rational®Clear Case. En la mayoría de los ejemplos citados en este artículo se usa CVS.

Optim Database Administrator usa proyectos para agrupar los distintos recursos necesarios para realizar un cambio. Data Design Project es un repositorio de todos los recursos (scripts, modelos, archivos de registro, etc.) pertenecientes a un cambio y también resulta útil para realizar el seguimiento del ciclo de vida de una base de datos. Los proyectos pueden compartirse usando la funcionalidad Eclipse Team, la cual permite la colaboración de varios DBA en un cambio. Los cambios se representan como Data Design Projects en ciertos momentos específicos. Una vez que el cambio se ha implementado, los recursos suelen enviarse al sistema de control de versiones y etiquetarse o rotularse. Las etiquetas o los rótulos pueden servir para volver al momento puntual previo a que se guardaran los cambios, para deshacer un cambio o para auditar un cambio en particular.

En bases de datos más complejas, los Data Design Projects pueden usarse para gestionar el ciclo de vida de una determinada aplicación de base de datos. En algunos talleres, las tablas o esquemas se dividen para que determinados DBA o equipos de DBA las gestionen. Los Data Design Projects pueden adaptarse a este tipo de entornos. Una única base de datos puede dividirse y gestionarse mediante varios Data Design Projects.

Los sistemas de control de versiones que se conectan con Eclipse, como CVS o IBM Rational Clear Case, son los que proporcionan la mejor integración con Optim Database Administrator. Sin embargo, como Optim Database Administrator almacena todos sus archivos y carpetas de datos en los sistemas de archivos locales, es posible usar sistemas de control de versiones que no se integren a Eclipse para la gestión de recursos de cambios de bases de datos. También podrá gestionar sus cambios prescindiendo de un sistema de control de versiones formal. Este artículo describe una situación de este tipo en la sección Uso de Optim Database Administrator sin un sistema de control de versiones.


Uso de Optim Database Administrator con un sistema de control de versiones

Este ejemplo explica cómo usar el control de versiones para auditar sus cambios y coordinar los cambios realizados por distintos DBA. Las figuras del ejemplo corresponden a Optim Database Administrator con DB2 V9.1. El ejemplo se divide en las siguientes cuatro partes:


Requisitos previos

En este escenario se usa la base de datos GSDB. También necesitará usar la base de datos de muestra denominada GSDB. Siga los pasos a continuación para crear la base de datos:

  1. Descargue el archivo zip de la sección Descargas de este artículo y extraiga el archivo GSDB_Database.sql.
  2. Abra una ventana de comando DB2.
  3. Navegue hacia la ubicación donde guardó el archivo GSDB_Database.sql.
  4. Ingrese:db2 -td~ -f GSDB_Database.sql

Cuando inicie Optim Database Administrator, las conexiones con las bases de datos aparecerán automáticamente en el Data Source Explorer, como muestra la Figura 2. Al usar estas conexiones por primera vez, se le solicitará ingresar su nombre de usuario y contraseña para conectarse con las bases de datos.

Figura 2. Conexiones en Data Source Explorer
Connections in Data Source Explorer

Parte 1: Uno de los DBA, Jaya, realiza un cambio en la base de datos.

Jaya crea una tabla nueva llamada GOSALES.PROD_PROMO para almacenar información sobre descuentos disponibles en determinados productos. Para realizar este cambio, ella usa el editor de scripts Change Management de ODA. Siga los pasos realizados por Jaya:

  1. Cree un nuevo script de gestión de cambios.

    En la vista Data Source Explorer (Explorador de fuentes de datos), despliegue la conexión GSDB (GSDB debe estar en estado “conectado”). Haga clic con el botón derecho en la carpeta Change Management (Gestión de cambios)y seleccione el elemento de menú New Database Change... (Nuevo cambio de base de datos), como muestra la Figura 3a.

    Figura 3a. Crear un nuevo asistente de Change Management
    Launch new Change Management wizard

    Se abrirá el asistente New Change Management (Nueva gestión de cambios). Dentro de este asistente, seleccione los esquemas denominados GOSALES y GOSALESCT Y luego haga clic en Finish (Finalizar).

    Cuando se cierre el asistente, se habrá creado un nuevo archivo script llamado GSDB.changexml. También se habrán creado dos archivos modelo de datos físicos. Uno de estos archivos modelo, llamado base model (modelo base), representa a la base de datos antes del cambio. El Segundo archivo, denominado target model (modelo objetivo), contendrá todos los cambios nuevos realizados por el DBA en el editor. Los comandos de cambios se generan en base a estos dos modelos. El archivo script changexml y los archivos modelo de base de datos se crean dentro de un nuevo proyecto denominado GSDB, y luego podrá accederse a ellos usando la vista Data Project Explorer (explorador de proyectos de datos).

    El archivo script de gestión de cambios recién creado se abrirá automáticamente en el editor para que el DBA pueda iniciar el proceso de cambio.

  2. Cree la tabla PROD_PROMO.

    En el editor, defina la tabla nueva (PROD_PROMO) que se desea crear en la base de datos. Para hacerlo, agregue la tabla a la lista Objects to be changed (Objetos a cambiar) haciendo clic en el ícono Agregar, representado por un signo más (+), y luego seleccionando las Tablas Database Object Type (Tipo de objeto de base de datos) en la lista emergente (ver Figura 3b a continuación). Use el esquema GOSALES para la tabla nueva.

    Figura 3b. Crear una tabla nueva, PROD_PROMO, usando el editor de gestión de cambios
    Create new table, PROD_PROMO, using the Chnage Management Editor
  3. Después de que la tabla se haya agregado a la lista "Objects to be changed", seleccione la tabla en el editor y realice los siguientes cambios en la vista Properties (Propiedades):
    1. Si la tabla nueva aparece con un nombre predeterminado (como Table1), cambie el nombre a PROD_PROMO.
    2. Agregue las siguientes columnas haciendo clic en el ícono Nuevo, representado por un signo más (+) verde, como muestra la Figura 4a:
      • PROMO_CODE de tipo INTEGER
      • PROD_NUMBER de tipo INTEGER
      • START_DATE de tipo DATE (fecha)
      • END_DATE de tipo DATE
      • DISCOUNT_PCNT de tipo INTEGER
      • DESCRIPTION de tipo VARCHAR(128)
      Figura 4a. Renombrar la tabla nueva y agregarle nuevas columnas
      Add new columns to PROD_PROMO.
    3. Establezca la columna PROMO_CODE como clave principal de la tabla PROD_PROMO seleccionando la casilla de verificación Primary Key (Clave principal) correspondiente a la columna.
    4. Agregue el espacio de tabla USERSPACE1 a la tabla GOSALES.PROD_PROMO usando la pestaña Table Space (Espacio de tablas) en la vista Properties, como muestra la Figura 4b.
    Figura 4b. Especificar el espacio de tabla de PROD_PROMO
    Specify the tablespace for PROD_PROMO.
  4. Cree una relación con una clave externa entre la columna PROD_NUMBER de la tabla GOSALES.PROD_PROMO y la columna clave principal PRODUCT_NUMBER en GOSALES.PRODUCT. Para hacerlo, agregue una nueva restricción de clave externa a la lista "Objects to be changed" en la que GOSALES.PROD_PROMO sea la tabla de base y GOSALES.PRODUCT se la tabla primaria. Para hacerlo, haga clic enAdd icon (Agregar ícono)y luego seleccione el tipo de objeto de base de datosForeign Key Constraint (Restricción de clave externa), como muestra la Figura 4c. Se le solicitará especificar las tablas de base y primaria.
    Figura 4c. Crear relación de clave externa entre las tablas GOSALES.PROD_PROMO y GOSALES.PRODUCT
    Create foreign key relationship between tables GOSALES.PROD_PROMO and GOSALES.PRODUCT.
  5. A continuación, seleccione la restricción de clave externa recién agregada en el editor y especifique las columnas claves usando la vista Properties. Seleccione la pestaña Details (Detalles) en la vista Properties. En Child (Secundaria), agregue PROD_NUMBER como clave externa haciendo clic en el botón de navegación Key Columns (Columnas clave). En Parent (Prinicipal), seleccione la clave principal definida en PRODUCT_NUMBER desde el cuadro Unique Constraint (Restricción única) o Index (Índice), como muestra la Figura 4d:
    Figura 4d. Agregar columnas claves a la restricción de clave externa
    Add key columns to the Foreign Key.

    En la pestaña General, dentro de la vista Properties, seleccione el botón de radio denominado Non-Identifying (No identificador), como muestra la Figura 4e:

    Figura 4e. Actualizar las propiedades de clave externa
    Update Foreign Key properties.

    Guarde los cambios.


Parte 2: Jaya ha terminado de realizar sus cambios y está lista para compartir su proyecto agregándolo al sistema de control de versiones.

Los cambios se envían al sistema de control de versiones. Más tarde estos cambios podrán extraerse del sistema de control de versiones y usarse para continuar el proceso de gestión de cambios. Esto también permite que, de ser necesario, otros administradores auditen los cambios. Los cambios realizados por dos o más DBA pueden combinarse y coordinarse fácilmente.

En este ejemplo se emplea el sistema de control de versiones CVS. A continuación se describen los pasos a seguir para agregar el proyecto a CVS.

  1. Instale el servidor CVS y configure un repositorio.
  2. Pase a la perspectiva CVS Repository Exploring (Exploración de repositorios CVS). Esta perspectiva posee una vista llamada CVS Repositories que permite agregar distintas ubicaciones de repositorios.
  3. Para agregar la ubicación de repositorio del Data Design Project de Optim Database Administrator, haga clic con el botón derecho en la vista CVS Repositories y seleccione New (nuevo) > Repository Location (Ubicación del repositorio), como muestra la Figura 5:
    Figura 5. Diálogo Add CVS Repository (Agregar repositorio CVS)
    The Add CVS Repository dialog
  4. Complete los campos obligatorios y seleccione Finish. Ahora podrá ver el repositorio agregado en la vista CVS Repository.
    Figura 6. Vista Repository Exploring con la nueva ubicación de repositorio
    Repository Exploring view
    Desglose y navegue los contenidos del repositorio.
  5. Vuelva a la perspectiva Data Administration (Administración de datos). Seleccione el proyecto depruebaque desea ingresar en CVS, haga clic con el botón derecho en el proyecto y seleccione Team (Equipo) -> Share Project (Compartir proyecto). Se visualizará el asistente Share Project.
    Figura 7. Asistente Share Project
    The Share Project wizard
  6. Seleccione la ubicación de repositorio existente (la que agregó en el paso anterior). Acepte todas las opciones predeterminadas y haga clic en Finish. Recuerde: puede ingresar todos los recursos de Optim Database Administrator como de tipo ASCII. Todo DBA que esté autorizado a acceder a esta ubicación de repositorio específica podrá extraer el proyecto, revisarlo y realizar cambios.

Parte 3: Otro DBA llamado Eric extrae el proyecto para realizar otros cambios.

Siga los pasos realizados por Eric:

  1. Extraiga el proyecto
    1. Abra la perspectiva CVS Repository Exploring.
    2. Seleccione el proyecto GSDB en la vista CVS Repository, haga clic con el botón derecho y seleccione Check Out (extraer). Esta acción crea una copia del proyecto en el espacio de trabajo actual.
    3. Vuelva a la perspectiva Database Administration. Los archivos extraídos de CVS quedarán disponibles en la vista Data Project Explorer. Ahora puede modificar el proyecto y todos sus archivos asociados. Antes de abrir el archivo GSDB.changexml en el editor, cerciórese de que exista la conexión GSDB y se encuentre en estado “conectado”.
  2. Especifique los cambios que desea incorporar
    1. Abra el archivo script de gestión de cambios, GSDB.changexml, haciendo doble clic sobre él en la vista Data Project Explorer. Este archivo se encuentra dentro de la carpeta SQL Scripts en la vista Data Project.
    2. Seleccione la tabla PROD_PROMO en el editor.
    3. En la vista Properties, cambie el nombre de la columna PROMO_CODE por PROMO_NUMBER.
    4. Guarde los cambios.
  3. Supongamos que Eric se dio cuenta de que estos cambios eran incorrectos. Para revertirlos y volver a la versión en CVS, haga clic con el botón derecho en el proyecto GSDB (o sobre cualquier recurso individual del proyecto) en la vista Data Project Explorer, y luego seleccione el menú de contextos Replace With (Reemplazar por) > Latest from Head (Última versión). Esta acción deshará todos los cambios realizados desde que se extrajeron los archivos. Esta característica, que permite deshacer todo lo realizado desde un momento puntual, resulta muy útil, especialmente cuando deben deshacerse grandes cantidades de cambios.
  4. Luego de que los archivos se hayan reemplazado, Eric procederá a realizar otros cambios de la siguiente manera:
    1. Reabra el archivo GSDB.changexml y luego agregue una nueva columna llamada PROMO_CODE de tipo INTEGER a la tabla GOSALESCT.CUST_ORD. Agregue la tabla a modificar a la lista "Objects to be Changed" haciendo clic en Alter icon (Modificar ícono) y luego seleccione la tabla CUST_ORD, como muestra la Figura 8a:
      Figura 8a. Seleccionar la tabla GOSALESCT.CUST_ORD para su modificación
      Alter table

      Seleccione la tabla en el editor y agregue la nueva columna usando la vista Properties, como muestra la Figura 8b:

      Figura 8b. Agregar una columna nueva llamada PROMO_CODE a la tabla GOSALESCT.CUST_ORD
      Add new column
    2. Cree una relación de clave externa entre la columna PROMO_CODE de la tabla GOSALESCT.CUST_ORD y la columna clave principal PROMO_CODE de la tabla GOSALES.PROD_PROMO.
  5. Guarde los cambios y genere los comandos haciendo clic en el botón Preview Commands (Vista previa de comandos) en el editor de gestión de cambios. Verifique que los comandos generados funcionen correctamente.

    Nota:

    • Los comandos generados incluyen comandos para la conservación de datos en caso de que se realice un cambio que destruya la tabla. También se incluyen comandos de mantenimiento como reorg y rebind que se utilizan para restaurar el estado de la base de datos luego de la implementación de comandos.
    • Si los comandos generados contienen errores (como mapeo de columnas de exportación e importación incorrecto), se le solicitará usar el asistente Data Options, el cual lo ayudará a corregir los problemas siguiendo en una serie de pasos. Para obtener más información acerca de la gestión de cambios con Optim Database Administrator, consulte la sección de Recursos de este documento.
  6. Aplique los cambios a la base de datos.

    Haga clic en el botón Run... (Ejecutar) en el editor para implementar los comandos contra la base de datos GSDB. El mensaje de estado de implementación se visualizará en el editor y también en la vista SQL Results, como muestra la Figura 9. La sección del mensaje de estado en el editor también incluye una barra de progreso que muestra el tiempo aproximado que falta para completar la implementación de los comandos.

    Figura 9. Implementación de los comandos
    Command Deployment
  7. Guarde los archivos y cierre el editor. Para copiar los cambios nuevos a CVS, haga clic con el botón derecho en el proyecto GSDB y seleccione Team > Commit (Enviar) para ingresar los cambios en CVS.

Ahora todo el equipo puede revisar los cambios realizados por Jaya y Eric.


Parte 4: la primera DBA, Jaya, extrae el proyecto y revisa los cambios realizados por Eric.

Si bien los cambios suelen implementarse en la base de datos recién después de su aprobación, podría suceder que nos percatemos de que es necesario volver atrás un cambio luego de que ha sido realizado. Esta parte describe una situación de este tipo, en la cual la primera DBA decide deshacer un cambio ya implementado.

Jaya realizaría los siguientes pasos para deshacer los cambios implementados por Eric en la base de datos:

  1. Extraer el proyecto de CVS (si el proyecto ya existe en el espacio de trabajo, reemplazarlo por el último proyecto de CVS).
  2. Verificar que la conexión GSDB exista y se encuentre en estado “conectado”.
  3. Abrir el script de gestión de cambios y hacer clic en el botón Undo... (Deshacer) en el editor (el botón Undo se encuentra en la sección Messages del editor).
  4. Una vez finalizada la implementación de los comandos de deshacer, restablecer el script de gestión de cambios (mediante Change Management > Reset del menú principal) para iniciar el proceso de cambio desde el principio.

Uso de Optim Database Administrator sin un sistema de control de versiones

¿Puede usar Optim Database Administrator aunque no tenga acceso a un sistema de control de versiones? ¡Por supuesto que sí! Probablemente deba cumplir con ciertos controles por razones de auditoría y seguimiento, ¿cómo hacerlo si todos sus cambios de DB2 están almacenados en Optim Database Administrator? La información del Data Project se almacena en el espacio de trabajo Optim Database Administrator, el cual es definido por usted durante el inicio. El espacio de trabajo es un conjunto de directorios de su disco local. Puede mantener estos archivos juntos como el conjunto de archivos correspondientes a la versión.

Consideremos el ejemplo desarrollado en este artículo, pero supongamos que usted NO cuenta con un sistema de control de versiones.

Una de las ventajas de usar un repositorio para almacenar los cambios es el completo historial que se encuentra disponible en el espacio de trabajo. El historial puede utilizarse con fines de auditoría o para volver atrás un cambio. Si usted administra únicamente los archivos de proyectos por sí solos, dependerá de usted realizar o no el seguimiento de quiénes realizaron los cambios y cuándo los realizaron.

¿Puedo compartir todo el espacio de trabajo con otro usuario?

En teoría, es posible compartir directamente todo el espacio de trabajo a través de, por ejemplo, un disco compartido. Sin embargo, si ese caso usted intentara abrir el espacio de trabajo mientras otra persona lo tuviera abierto, obtendría un mensaje de error que le informaría que el archivo está siendo utilizado. Otra desventaja de compartir el espacio de trabajo es que además se comparten todas las configuraciones, por lo cual se perderá cualquier personalización que haya realizado si otra persona cambia la configuración. En conclusión, no se recomienda compartir el espacio de trabajo.

¿Cómo comparto los archivos entre varios DBA?

Existen varias formas de compartir los archivos de un proyecto. El enfoque más sencillo, que describiremos a continuación, consiste en exportar todo el proyecto como archivo comprimido (ZIP) y en que el otro usuario importe el proyecto a su espacio de trabajo. Retomemos el escenario del ejemplo en el cual Jaya y Eric trabajan en cambios en la base datos. Imaginemos que Jaya se encuentra al final de la Parte 1, luego de que se han generado los comandos de cambios. En lugar de ingresar los archivos en el control de versiones, Jaya ahora debe conservar los cambios y ponerlos a disposición de otro DBA que trabaja en el proyecto. Para esto, Jaya realizaría los siguientes pasos:

  1. Seleccionar el proyecto, luego seleccionar File (Archivo) -> Export (Exportar) para abrir el diálogo de exportación.
  2. Desplegar la carpeta General, seleccionar Archive File (Archivo almacenado) y hacer clic en Next (Siguiente).
  3. En la siguiente pantalla, seleccionar el proyecto, la ubicación del archivo de salida, el nombre del archivo y el formato (ZIP o TAR), y hacer clic en Finish. Esta acción crea el archivo ZIP en el disco.
  4. Jaya puede salir de Optim Database Administrator y poner a disposición de Eric el archivo ZIP exportado.

Eric debe trabajar sobre el proyecto. En lugar de extraer el proyecto de CVS, Eric debe llevarlo manualmente a su espacio de trabajo. Eric realizará los siguientes pasos:

  1. En el espacio de trabajo, seleccionar File -> Import (Importar).
  2. Desplegar la carpeta General y seleccionar Existing Projects into Workspace (proyectos existentes hacia el espacio de trabajo).
  3. Usar Select archive file Para navegar hacia la ubicación del archivo almacenado exportado por Jaya. Los proyectos que se encuentran dentro de este archivo aparecerán en el cuadro de lista Projects (Proyectos).
  4. Seleccionar el proyecto y hacer clic en Finish.

Ahora el proyecto se encuentra en el espacio de trabajo de Eric y él puede proceder a realizar los cambios como se describió en la Parte 3. Cuando Eric realiza los cambios y genera los comandos, el script de gestión de cambios contendrá cambios de Jaya y de Eric (Eric podría haber extraído o modificado los cambios de Jaya, pero en este caso no lo hizo).

En la Parte 3, Eric renombra una columna pero luego se arrepiente y revierte el proyecto a la versión en CVS. Si no contamos con un sistema de control de versiones, ¿cómo podemos realizar esta acción?

En Optim Database Administrator, una cierta cantidad de historial local se mantiene en el espacio de trabajo. En este escenario en particular, Eric podría utilizar la especificación de cambio rename column PROD_NUMBER (Renombrar columna) y luego revertir el cambio en el modelo meta y en el script de gestión de cambios desde la vista Data Project Explorer seleccionando Replace with Local History (Reemplazar por historial local). Eric también podría intentar revertir el proyecto a un cambio realizado previamente. Sin embargo, esta acción no funcionará en todos los casos y solo se realizará con éxito mientras se mantenga en el espacio de trabajo, es decir que Eric y Jaya no podrán revertir el proyecto a los cambios realizados por el otro.

En la Parte 4 del proceso, luego de que Eric ha exportado el proyecto a un archivo (ZIP/TAR), Jaya puede traer nuevamente el proyecto al espacio de trabajo. Jaya deberá eliminar el proyecto existente del espacio de trabajo e importar el nuevo archivo de proyecto realizado por Eric. Este proyecto incluirá todos los cambios efectuados en las Partes 1 y 3. Sin embargo, Jaya no podrá acceder al historial local de los cambios realizados por Eric y, por consiguiente, revertir el proyecto a cambios anteriores resultará más difícil.

Este escenario demuestra la importancia de contar con un sistema de control de versiones cuando se trabaja en un entorno de equipo.

Un enfoque alternativo al de compartir cambios mediante un archivo del proyecto completo consiste en compartir los modelos o scripts de gestión de cambios individuales y usar las características de fusión y migración de Optim Database Administrator para integrar los cambios. Este enfoque requiere de mayor atención a los detalles pero podría brindar más flexibilidad en la administración de cambios múltiples o más complejos. Ninguno de estos dos enfoques posee las completas capacidades de historial que ofrece un sistema de control de versiones.


Conclusión

El uso de Optim Database Administrator junto con un sistema de control de versiones proporciona un importante recurso para la gestión de sus necesidades de negocios. Usando ambas herramientas, podrá dinamizar el seguimiento de todos los cambios que conforman el ciclo de desarrollo de aplicaciones, lo cual, de lo contrario, podría convertirse en una ardua tarea. Aún prescindiendo de un sistema de control de versiones establecido, usted podrá obtener los beneficios de Optim Database Administrator con un sistema propio correctamente planificado. Esperamos que este artículo lo impulse a seguir informándose acerca de cómo Optim Database Administrator puede satisfacer sus necesidades.


Descargar

DescripciónNombretamaño
GSDB sample database for this articleGSDB_database.zip4.74KB

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=966747
ArticleTitle=Control de versiones de bases de datos con IBM Optim Database Administrator V2.2
publish-date=12222009