Gestión de versiones en Jitterbit App Builder

Este artículo describe las prácticas recomendadas, los requisitos previos para crear una versión y los pasos a seguir para la gestión general de versiones en App Builder. Para obtener instrucciones detalladas sobre cómo crear la versión de App Builder dentro de App Builder, consulte Crear una versión artículo.

Mejores prácticas

El ambiente de desarrollo no es un ambiente aislado. App Builder captura cada cambio en la base de datos, los rastrea y los reproduce en el control de calidad cuando se envía la base de datos. Por lo tanto, el desarrollador debe aplicar los cambios al ambiente de desarrollo de la misma forma que esperaría que se aplicaran en control de calidad y producción. Hay dos tipos de cambios que App Builder captura en desarrollo y aplica durante una actualización de control de calidad y producción:

Cambios de esquema

1. Cambiar el nombre de una tabla
2. Agregar/Modificar/Eliminar una columna
3. Modificar una clave principal
4. Agregar/Modificar/Eliminar una clave externa
5. Agregar/Modificar/Eliminar una restricción única

Reglas de Migración: Las reglas de migración se definen de forma similar a una regla de Crear/Actualizar/Eliminar y se ejecutan en el ambiente de desarrollo. App Builder registra la regla y la ejecuta durante una actualización.

Transportar todas las aplicaciones y fuentes de datos dependientes

Envío solo de una aplicación o solo de una fuente de datos

Si bien es posible enviar una sola aplicación o una sola fuente de datos de Desarrollo a Control de Calidad, esto solo debe ser realizado por administradores avanzados con un conocimiento detallado de los cambios que se envían con el objeto. En general, es mejor incluir todos los objetos dependientes al enviar una solución de Desarrollo a Control de Calidad y Producción. A continuación, se presentan algunos escenarios a considerar cuando no se incluyen todos los objetos dependientes:

Un diseñador agrega una columna a un objeto de datos en la Fuente de Datos A. Luego, agrega un control a un panel en la Aplicación X que está vinculado a la nueva columna. Si el desarrollador intenta enviar la Fuente de Datos A a QA, la actualización se realizará correctamente. El objeto de datos tendrá una nueva columna, aunque la aplicación no la utilice. Sin embargo, si el desarrollador envió la Aplicación X a QA sin incluir la Fuente de Datos A en su solución, la actualización fallará. Al actualizar la aplicación, App Builder intentará agregar el nuevo control, pero la columna a la que está vinculado no existe en la fuente de datos actual de QA y, por lo tanto, no se podrá agregar.

Varias aplicaciones que utilizan la misma fuente de datos

Supongamos que la Aplicación X y la Aplicación Y hacen referencia a la Fuente de Datos A. Un equipo trabaja en la Aplicación X y otro en la Aplicación Y. Ambos equipos han añadido columnas a objetos de datos en la Fuente de Datos A, y han añadido controles a las Aplicaciones X e Y que están enlazados a esas columnas. Uno de los equipos también eliminó un control de la Aplicación X y la columna Z, a la que estaba enlazado. Si un desarrollador intenta enviar la Aplicación Y y la Fuente de Datos A a QA, la actualización fallará. App Builder intentará eliminar la Columna Z de la Fuente de Datos A, pero la columna sigue siendo referenciada por la Aplicación X en QA y, por lo tanto, la actualización no podrá eliminarla. Es mejor incluir todas las aplicaciones y fuentes de datos referenciadas en la solución para garantizar que la actualización sea exitosa.

Agregar una columna no nula

Aproveche las reglas de migración. Supongamos que la tabla "Empleado" se ha enviado a QA y PROD y se ha rellenado con datos de producción. Un desarrollador elimina todas las filas de esa tabla para agregar una columna NO NULL (el booleano activo "Permitir valores nulos" = Falso). Esta operación se realizará correctamente en el ambiente de desarrollo porque no hay registros de empleados. Sin embargo, al aplicar este conjunto de cambios en QA o PROD, fallará. Una base de datos RDMB no permite agregar una columna no nula a una tabla que contiene filas.

En su lugar, en el ambiente de desarrollo, no elimine los registros de empleados. Déjelos de forma que el ambiente sea representativo de los ambientes de destino de QA y PROD. Agregue la nueva columna a la tabla Empleado, pero permita valores nulos (Active Boolean Allow Nulls = True). Cree una regla de migración que actualice el valor de Employee.Active a verdadero/falso para todos los empleados. Ejecute la regla. Cambie la nueva columna a Allow Nulls = False. Esta operación se realizará correctamente en el desarrollo y se enviará correctamente al QA y PROD. App Builder realizará los siguientes pasos durante la actualización:

1. Agregar Activo a la tabla Empleado Permitir nulos = Verdadero
2. Actualice todas las filas de Empleado para que Activo = verdadero/falso
3. Modifique la columna Activa para que Permitir nulos = Falso

Nota

Use expresiones compatibles para establecer el bit Activo como verdadero o falso según las circunstancias. Normalmente, al agregar una columna a una tabla, no se espera que todas las filas tengan el mismo valor. En este caso, la regla de migración podría establecer Activo como Falso para los empleados con contrato que no hayan estado contratados durante el último año, mientras que el valor de Activo para las demás filas de empleados podría ser verdadero.

Modificar la clave principal de una tabla

Tenga cuidado al modificar una clave principal en una tabla que ya se envió a QA y que contiene datos. Es recomendable asegurarse de que el ambiente de desarrollo contenga datos en la tabla para que represente mejor los ambientes de QA y Producción. Una clave principal puede cambiar de varias maneras. A continuación, se muestra un ejemplo:

Supongamos que la columna "Empleado" tiene una clave principal entera "IdEmpleado". Supongamos también que "AcumulaciónEmpleado" tiene una columna "IdEmpleado" de tipo entero (la clave externa hace referencia a "Empleado.IdEmpleado"). La tabla "Empleado" también tiene una columna "SeguridadSocial" (la cadena "Única" permite valores nulos = "Falso").

El desarrollador ha decidido cambiar la clave principal de Employee de EmployeeId a SocialSecurity. Estos son los pasos recomendados:

1. Agregue la cadena de Seguridad Social Permitir Nulo = Verdadero a Acumulación de Empleados.
2. Cree una regla de migración que actualice EmployeeAccrual.SocialSecurity a Employee.SocialSecurity y una las dos tablas en EmployeeId. Ejecute la regla de migración.
3. Cambie el Seguro Social en EmployeeAccumual para que Permitir valores nulos sea Falso
4. Eliminar la relación entre Employee y EmployeeAccrual en EmployeeId
5. Elimine la columna EmployeeId de EmployeeAccrual
6. Cambie la clave principal de Empleado a Seguridad Social
7. Elimine la columna EmployeeId de la tabla Employee
8. Crear una relación entre Empleado y Acumulación de Empleado en la Seguridad Social

App Builder registrará estos pasos y los ejecutará con éxito mientras actualiza QA y Prod.

Nota

Al realizar los pasos del 1 al 8, se espera que el desarrollador realice cambios en los objetos de datos, acciones, paneles, controles, etc. Puede realizar estos cambios en cualquier momento. En el ejemplo anterior, es posible que los 8 pasos se realicen durante un período de 8 horas, durante el cual también se modifican varias páginas, objetos de datos y controles en diversas etapas. Lo importante es realizar los pasos en el orden correcto para que se realicen correctamente durante una actualización. Se espera que se realicen todos los cambios necesarios en la fuente de datos lógica o la aplicación durante estos pasos.

Evitar importar esquema

Si la intención es trasladar una base de datos física de Desarrollo a Control de Calidad y a Producción, y modificarla posteriormente a través de la interfaz de usuario de App Builder y enviar esos cambios a Control de Calidad y Producción, no utilice la función de importación de fuentes de datos de App Builder. Para desplegar los cambios realizados durante el desarrollo, App Builder los captura a medida que se realizan a través de su interfaz de usuario. La importación de una fuente de datos omite la interfaz de usuario de App Builder, sincronizando el modelo lógico de App Builder para que coincida con el modelo físico de la fuente de datos importada. Por lo tanto, no se propagarán cambios en la fuente de datos importada durante una actualización. Existen situaciones en las que la importación es compatible con la gestión de versiones:

1. Si la base de datos física se mantiene y modifica fuera de App Builder en todos los ambientes, se admite la importación de la fuente de datos durante todo el ciclo de vida del desarrollo.
2. Si la base de datos física es compartida por Dev/Qa/Prod, entonces se admite la importación de la fuente de datos durante todo el ciclo de vida del desarrollo.

Requisitos previos para crear una versión

Se deben considerar y completar los siguientes elementos antes de crear una versión de App Builder:

1. Asegúrese de que el usuario de la base de datos de App Builder tenga permisos de creación de tablas y bases de datos en el ambiente en el que está realizando la instalación.
2. Asegúrese de que un administrador de base de datos complete una copia de seguridad de la base de datos de App Builder y de cualquier base de datos que sufra cambios físicos o de esquema.
3. Asegúrese de que el paquete de ambiente que se instalará se esté ejecutando en la misma versión de App Builder en la que se está ejecutando el ambiente de origen.

Pasos a seguir para la gestión de releases

1. Utilizando los estándares de su empresa para realizar pruebas, verifique la funcionalidad de la aplicación App Builder.
2. Crea una lista de todas las Fuentes de Datos adjuntas a la aplicación para la que estás compilando una versión. Esta información está disponible en el IDE de App Builder. Compila tu aplicación, haz clic en ella y revisa el Panel de Fuentes de Datos resultante.
3. Cree una Plantilla de lanzamiento de aplicaciones y asegúrese de que se incluyan todas las aplicaciones que deben promocionarse.
4. Asegúrese de que todas las Fuentes de datos vinculadas identificadas en el paso 2 estén incluidas en la Plantilla.
5. Verifique la configuración de la plantilla para las fuentes de datos. Configure solo Lógico y Físico para las fuentes de datos que esquema con App Builder.
6. Revise y confirme todos los pasos de gestión de cambios de base de datos abiertos para las bases de datos que estén marcadas como Instalación lógica y Instalación física.
7. Configure la Configuración de datos para las tablas en bases de datos que hayan sido marcadas para Instalación lógica y física.
8. Una vez completada la Configuración de datos, confirme la configuración de datos.
9. Crea la versión. Para obtener instrucciones detalladas sobre cómo crear una versión dentro del propio App Builder, consulta Crear una versión artículo.