Base Datos

Warning:

Esta página define el estándar para documentación de estructura de repositorios GIT para Base Datos. Su aplicación dentro de las actividades diarias es de uso obligatorio para el rol de los responsables de configuración.

Este estándar se establece con la intención de generar repositorios que cumplan con lo establecido por el área de dirección.

Para llevar a cabo el control de los proyectos que llevamos con nuestros clientes, se implementaran repositorios por cada plataforma que se vaya a desarrollar, utilizando el nombre del proyecto y las siglas BD. Estos son algunos ejemplos a seguir:

7Eleven-BD -> Plataforma para objetos de base de datos del proyecto 7Eleven.

Aprecia-BD -> Plataforma para objetos de base de datos del proyecto Aprecia.

Compartamos-BD -> Plataforma para objetos de base de datos del proyecto Compartamos.

Attendo-BD -> Plataforma para objetos de base de datos del proyecto Attendo.

Composición de las ramas del repositorio

La composición de todos los repositorios en GIT, se realiza por medio de la creación de 4 o 5 ramas en la cuales se almacenarán los objetos de base de datos de cada proyecto desarrollado. Estas ramas son las que se mencionan a continuación:

• Development
• QA
• HotFixes
• PreProduction (opcional)
• Master

Development

Rama donde se encuentran los objetos de base de datos para el ambiente de desarrollo por parte de los programadores.

QA

Rama donde se encuentran los objetos de base de datos para el ambiente de pruebas por parte de los Testers del área de QA.

HotFixes

Rama donde se encuentran los objetos de base de datos del ambiente productivo, para resolver alguna incidencia que se haya reportado sin interferir con la rama del ambiente de desarrollo actual.

PreProduction

Esta rama es opcional y se creará cuando el cliente así lo requiera como ambiente de pruebas. No debe confundirse con un ambiente para ejecución de pilotos.

Master

Rama donde se encuentran los objetos de base de datos del ambiente productivo.

Manejo de objetos de base datos en el repositorio

El manejo de los objetos de base de datos que se tienen para cada proyecto, procederá como se describe a continuación:

1. Se carga todo el código de los objetos de la base de datos, el cual debe salir de la base de datos productiva para garantizar que se tiene el ultimo código fuente liberado. La estructura de la carga procederá como se describe a continuación:

a Tables: Subdirectorio que contendrá todas las definiciones de las tablas de la base de datos con el formato [nombreTabla].sql

b Sps: Subdirectorio que contendrá todas las definiciones de todos los procedimientos de la base de datos con el formato [nombreSp].sql

c Others: Subdirectorio que contendrá todas las definiciones de los otros objetos existentes de la base de datos con el formato [nombreObjeto].sql

d Scripts: Subdirectorio que contendrá todos los scripts de modificaciones de datos en la base de datos. No contendrá scripts de modificación de objetos de base de datos. 

2. Los desarrolladores registraran los cambios sobre la base de datos en la rama development. Se actualizaran las definiciones de los objetos de base de datos (DDL, No en formato UPDATE si no en formato CREATE):

3. Para los casos que aplique durante el desarrollo, se crearán los scripts de modificación de registros en la base de datos.

Promoción del código entre las ramas

Los pases de cambios sobre el código de las bases de datos a QA, Preproductivo o Master se ejecutarán solo por usuarios autorizados y se realizarán con la estrategia Squash de GIT para que se genere un único Commit en la rama y sea mas sencillo obtener los cambios a ejecutar.

Estrategia de trabajo en DBA

1.Se envían las solicitudes a DBA indicando el ambiente para el que se despliegan cambios. El identificador del commit a desplegar y la definición del orden de ejecución de cambios cuando aplique.

2.DBA se conecta al repositorio, descarga cambios de la rama indicada y obtiene todos los componentes que se deben modificar.

3.Mediante la estrategia Diff de GIT, se podrán ver con detalle los cambios requeridos sobre los objetos de base de datos afectados.

4.Se ejecutan los cambios sobre las tablas, actualización de procedimientos, índices o cualquier objeto sobre la base de datos.

5.Los scripts para alterar procedimiento, función, tabla, etc deberán ser generados por el área de DBA, basados en la información obtenida del gestor de código fuente.

Estrategia de trabajo de Desarrollo

1.Se deben actualizar todos los objetos modificados o creados dentro del repositorio por cada programador. El no realizar esta acción será considerado para las evaluaciones de desempeño.

2.Se solicitará movimiento de código de las bases de datos entre ramas de la misma manera que se hace para código fuente. Los tickets de solicitud a base de datos se harán agregando el identificador del commit o etiqueta que se desea desplegar.

3.Antes de pasar cambios de Desarrollo a QA, el líder técnico debe validar con cada miembro del equipo que se hayan registrado en el repositorio los cambios que cada uno haya realizado.