Saltar al contenido

Gestión de versiones en Jitterbit App Builder

Este artículo describe las mejores prácticas, los requisitos previos para construir una versión y los pasos a seguir para la gestión general de versiones en App Builder. Para instrucciones detalladas sobre cómo construir la versión de App Builder dentro de App Builder mismo, consulta el artículo Construir una versión.

Mejores prácticas

El entorno de desarrollo no es un sandbox. App Builder está capturando cada cambio en la base de datos, rastreándolos, y los reproducirá en QA cuando se envíe la base de datos. Como tal, el desarrollador debe aplicar cambios al entorno de desarrollo de la misma manera que esperaría que se aplicaran los cambios en QA y Prod. Hay dos tipos de cambios que App Builder captura en desarrollo y aplica durante una actualización de QA y PROD:

Cambios en el esquema

  1. Renombrar una tabla
  2. Agregar/Modificar/Eliminar una columna
  3. Modificar una clave primaria
  4. Agregar/Modificar/Eliminar una clave foránea
  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

Si bien es posible enviar una sola aplicación o una sola fuente de datos de Dev a QA, esto solo debe hacerlo administradores avanzados con un conocimiento detallado de los cambios que se están enviando 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 al no incluir 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 sea utilizada por 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, entonces la actualización fallará. Al actualizar la aplicación, App Builder intentará agregar el nuevo control, pero la columna a la que está vinculada no existe en la fuente de datos actual en QA y, por lo tanto, no se puede agregar.

Múltiples aplicaciones utilizando 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 los 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 columna aún está referenciada por la Aplicación X en QA y, por lo tanto, la actualización fallará al intentar eliminar la columna. Es mejor incluir cualquier aplicación y fuente de datos que se haga referencia en la solución para asegurar que la actualización sea exitosa.

Agregar una columna no nula

Aproveche las reglas de migración. Supongamos que una tabla "Empleado" ha sido enviada a QA y PROD y ha sido poblada con datos de producción. Un desarrollador luego elimina todas las filas de esa tabla para agregar una Columna NO NULA (Activo Booleano Permitir Nulos = Falso). Esta operación tendrá éxito en el entorno de desarrollo porque no hay registros de empleados. Sin embargo, cuando este conjunto de cambios se aplique en QA o PROD, fallará. Una base de datos RDBMS no permitirá que se agregue una columna no nula a una tabla que contiene filas.

En su lugar, en el entorno de desarrollo, no elimine los registros de empleados. Déjelos para que el entorno sea representativo de los entornos objetivo de QA y PROD. Agregue la nueva columna a la tabla Empleado, pero permita valores nulos (Activo Booleano Permitir Nulos = Verdadero). 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 para que Permitir Nulos = Falso. 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 Activo a la tabla Empleado Permitir Nulos = Verdadero
  2. Actualizar todas las filas de Empleado para que tengan Activo = verdadero/falso
  3. Modificar la columna Activo para que Permitir Nulos = Falso

Nota

Utilice expresiones soportadas para establecer el bit Activo 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 Activo en Falso para empleados contratados que no han sido contratados en el último año, mientras que establece todas las demás filas de empleados con Activo = verdadero.

Modificando la clave primaria de una tabla

Tome precauciones al modificar una clave primaria en una tabla que ya ha sido enviada a QA y contiene datos. Nuevamente, es mejor asegurarse de que el entorno de desarrollo tenga datos en la tabla, para que represente mejor los entornos de QA y Prod. Hay varias formas en que una clave primaria podría cambiar. A continuación se presenta un ejemplo:

Suponga que Empleado tiene una columna EmployeeId Entero Clave Primaria. También suponga que EmpleadoAcumulación tiene una columna EmployeeId Entero (clave foránea que hace referencia a Employee.EmployeeId). La tabla Empleado también tiene una columna SeguridadSocial (Cadena Única Permitir Nulos = Falso).

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

  1. Agregar SeguridadSocial Cadena Permitir Nulo = Verdadero a EmpleadoAcumulación.
  2. Crear una regla de migración que actualice EmpleadoAcumulación.SeguridadSocial para que sea Empleado.SeguridadSocial uniendo las dos tablas en EmployeeId. Ejecutar la regla de migración.
  3. Cambiar SeguridadSocial en EmpleadoAcumulación para que Permitir Nulos = Falso
  4. Eliminar la relación entre Empleado y EmpleadoAcumulación en EmployeeId
  5. Eliminar la columna EmployeeId de EmpleadoAcumulación
  6. Cambiar la clave primaria de Empleado a SeguridadSocial
  7. Eliminar la columna EmployeeId de la tabla Empleado
  8. Crear relación entre Empleado y EmpleadoAcumulación en SeguridadSocial

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

Nota

Mientras se realizan los pasos 1 a 8, se espera que el desarrollador realice cambios en Objetos de Datos, Acciones, Paneles, Controles, y así sucesivamente. Siéntase libre de hacer 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, objetos de datos y controles también se cambian en diversas etapas. El punto importante es realizar los pasos listados en el orden correcto, para que se ejecuten en el orden adecuado durante una actualización. Se espera y está bien realizar cualquier número de cambios en la fuente de datos lógica o aplicación mientras se realizan estos pasos.

Avoid importing schema

Si la intención es mover una base de datos física de Dev a Qa a Prod, y modificar aún más 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 utilice la función de importación para las Fuentes de Datos de App Builder. Para enviar cambios realizados en el desarrollo, App Builder captura esos cambios a medida que 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, no se propagarían cambios en la fuente de datos importada 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 entornos, entonces se admite la importación de la fuente de datos a lo largo del 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 a lo largo del ciclo de vida del desarrollo.

Prerequisites to building a release

Los siguientes elementos deben ser considerados y completados antes de construir 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 entorno en el que está instalando.
  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 esté sufriendo cambios físicos y/o de esquema.
  3. Asegúrese de que el paquete de entorno que se instalará esté ejecutándose en la misma versión de App Builder que la que está utilizando el entorno fuente.

Pasos a seguir para la gestión de lanzamientos

  1. Usando 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 construyendo un lanzamiento. Esta información está disponible en el IDE de App Builder, Construye tu aplicación, haz clic en tu aplicación y revisa el Panel de Fuentes de Datos resultante.
  3. Crea una Plantilla de Lanzamiento de la aplicación y asegúrate de que todas las aplicaciones que deben ser promovidas estén incluidas.
  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 para las que gestionarás cambios de esquema con App Builder.
  6. Revisa y compromete cualquier paso abierto de gestión de cambios de base de datos para bases de datos que estén marcadas como Lógica y Instalación Física.
  7. Configura la Configuración de Datos para las tablas en bases de datos que han sido marcadas 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. Construye el lanzamiento. Para instrucciones detalladas sobre cómo construir un lanzamiento dentro de App Builder, consulta el artículo Construir un lanzamiento.