Saltar al contenido

Gestión de versiones en Jitterbit App Builder

Este artículo te guía a través de las mejores prácticas, 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, consulta el artículo Crear una versión.

Para conocer cómo la gestión de versiones se ajusta a una estrategia general de actualización de plataforma, consulta Estrategias de actualización de producción.

Mejores prácticas

El entorno de desarrollo no es un sandbox. App Builder captura cada cambio de base de datos, los rastrea y los reproducirá en QA cuando se envíe la base de datos. Por lo tanto, el desarrollador debe aplicar cambios al entorno de desarrollo de la misma manera que espera que se apliquen en QA y Prod. Existen dos tipos de cambios que App Builder captura en desarrollo y aplica durante una actualización de QA y PROD:

Cambios de esquema

  1. Renombrar 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 manera similar a una regla de Crear/Actualizar/Eliminar y se ejecutan en el entorno de desarrollo. App Builder registra la regla y la ejecuta durante una actualización.

Transportar todas las aplicaciones y fuentes de datos dependientes

Enviar solo una aplicación o solo una fuente de datos

Aunque es posible enviar una sola aplicación o una sola fuente de datos de Dev a QA, solo debe hacerlo administradores avanzados con 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 Dev a QA y Prod. 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 tendrá éxito. El objeto de datos tendrá una nueva columna, aunque no la use la aplicación. 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 en QA y, por lo tanto, no se puede agregar.

Múltiples 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 está trabajando en la Aplicación X y otro equipo está trabajando en la Aplicación Y. Ambos equipos han agregado columnas a objetos de datos en la Fuente de datos A, y ambos equipos han agregado controles a las Aplicaciones X e Y que están vinculados a esas columnas. Uno de los equipos también eliminó un control de la Aplicación X y eliminó la columna, Columna Z, a la que estaba vinculado el control. 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 aplicación X en QA aún hace referencia a la columna y, por lo tanto, la actualización no podrá eliminarla. Es mejor incluir cualquier aplicación y fuente de datos a la que se haga referencia en la solución para garantizar que la actualización sea exitosa.

Agregar una columna que no admite nulos

Aprovecha las reglas de migración. Supongamos que una tabla "Employee" se ha enviado a QA y PROD y se ha poblado con datos de producción. Un desarrollador luego elimina todas las filas de esa tabla para agregar una columna NO NULA (Booleano activo Permitir nulos = Falso). Esta operación tendrá éxito en el entorno de desarrollo porque no hay registros de empleados. Sin embargo, cuando se aplique este conjunto de cambios en QA o PROD, fallará. Una base de datos RDMBS no permitirá agregar una columna que no admita nulos a una tabla que contiene filas.

En su lugar, en el ambiente de desarrollo, no elimines los registros de empleados. Déjalos para que el ambiente sea representativo de los ambientes objetivo QA y PROD. Agrega la nueva columna a la tabla Employee, pero permite valores nulos (Active Boolean Allow Nulls = True). Crea una regla de migración que actualice el valor de Employee.Active a verdadero/falso para todos los empleados. Ejecuta la regla. Cambia la nueva columna para que sea Allow Nulls = False. Esta operación tendrá éxito en desarrollo y tendrá éxito cuando se envíe a QA y PROD. App Builder realizará los siguientes pasos durante la actualización:

  1. Agregar Active a la tabla Employee con Allow Nulls = True
  2. Actualizar todas las filas de Employee para que tengan Active = verdadero/falso
  3. Modificar la columna Active para que sea Allow Nulls = False

Nota

Utiliza Expresiones compatibles para establecer el bit Active en verdadero/falso según condiciones prácticas. Típicamente, al agregar una columna a una tabla, no se espera que todas las filas tengan el mismo valor para esa columna. En este escenario, la regla de migración podría establecer Active en False para empleados contratistas que no han sido contratados en el último año, mientras que establece todas las otras filas de empleados con Active = verdadero.

Modificar la clave primaria de una tabla

Ten precaución al modificar una clave primaria en una tabla que ya se ha enviado a QA y contiene datos. Nuevamente, es mejor asegurar que el ambiente de desarrollo tenga datos en la tabla, para que represente mejor los ambientes QA y Prod. Hay varias formas en que una clave primaria podría cambiar. A continuación se presenta un ejemplo:

Supón que Employee tiene una columna EmployeeId Integer Primary Key. Supón también que EmployeeAccrual tiene una columna EmployeeId Integer (clave foránea que referencia Employee.EmployeeId). La tabla Employee también tiene una columna SocialSecurity (String Unique Allow Nulls = False).

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

  1. Agregar SocialSecurity String Allow Null = True a EmployeeAccrual.
  2. Crear una regla de migración que actualice EmployeeAccrual.SocialSecurity para que sea Employee.SocialSecurity uniéndose a las dos tablas en EmployeeId. Ejecuta la regla de migración.
  3. Cambiar SocialSecurity en EmployeeAccrual para que sea Allow Nulls = False
  4. Eliminar la relación entre Employee y EmployeeAccrual en EmployeeId
  5. Eliminar la columna EmployeeId de EmployeeAccrual
  6. Cambiar la clave primaria de Employee a SocialSecurity
  7. Eliminar la columna EmployeeId de la tabla Employee
  8. Crear relación entre Employee y EmployeeAccrual en SocialSecurity

App Builder registrará estos pasos y los ejecutará exitosamente durante la actualización de QA y Prod.

Nota

Mientras realizas los pasos 1 al 8, se espera que el desarrollador esté realizando cambios en Data Objects, Actions, Panels, Controls, etc. Siéntete libre de realizar estos cambios en cualquier momento. En el ejemplo anterior, es posible que los 8 pasos listados se realicen durante un período de 8 horas en el cual varias páginas, data objects y controles también se cambian en varias etapas. El punto importante es realizar los pasos listados en el orden correcto, para que se ejecuten en el orden correcto durante una actualización. Se espera y está bien realizar cualquier número de cambios a la fuente de datos lógica o a la aplicación mientras realizas estos pasos.

Evitar importar esquema

Si la intención es mover una base de datos física de Dev a QA a Prod, y además modificar esa base de datos física a través de la interfaz de usuario de App Builder y enviar esos cambios a QA y Prod, entonces no utilices la función de importación para Data Sources de App Builder. Para enviar cambios realizados en desarrollo, App Builder captura esos cambios conforme se realizan a través de su interfaz de usuario. Importar 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, ningún cambio en la fuente de datos importada se propagaría durante una actualización. Hay 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, entonces importar la fuente de datos durante todo el ciclo de vida del desarrollo es compatible.
  2. Si la base de datos física se comparte entre Dev/QA/Prod, entonces importar la fuente de datos durante todo el ciclo de vida del desarrollo es compatible.

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úrate de que el usuario de base de datos de App Builder tenga permisos de Crear tabla y base de datos en el entorno donde se va a instalar.
  2. Asegúrate 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 y/o de esquema.
  3. Asegúrate de que el paquete de entorno que se va a instalar se ejecute en la misma versión de App Builder que el entorno de origen.

Pasos a seguir para la gestión de versiones

  1. Utilizando los estándares de tu empresa para pruebas, verifica la funcionalidad de la aplicación App Builder.
  2. Crea una lista de todas las Fuentes de datos adjuntas para la aplicación para la que estás creando una versión. Esta información está disponible en el IDE de App Builder, Construir tu aplicación, haz clic en tu aplicación y revisa el panel de Fuentes de datos resultante.
  3. Crea una Plantilla de versión de aplicación y asegúrate de que se incluyan todas las aplicaciones que deben promoverse.
  4. Asegúrate de que todas las Fuentes de datos vinculadas identificadas en el paso 2 estén incluidas en la Plantilla.
  5. Verifica la configuración de la plantilla para las fuentes de datos. Solo establece Lógica y Física para las fuentes de datos cuyo cambio de esquema gestionarás con App Builder.
  6. Revisa y confirma todos los pasos abiertos de gestión de cambios de base de datos para las bases de datos marcadas como Instalación lógica y Física.
  7. Configura la Configuración de datos para las tablas en bases de datos que se han marcado para Instalación Lógica y Física.
  8. Una vez que la Configuración de datos esté completa, confirma la configuración de datos.
  9. Crea la versión. Para obtener instrucciones detalladas sobre cómo crear una versión dentro de App Builder, consulta el artículo Crear una versión.