Gestión de Versiones¶

Este artículo describe 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 construir el App Builder liberación dentro App Builder en sí, consulte Crear una versión artículo.

Mejores Prácticas¶

El ambiente de desarrollo no es una zona protegida. App Builder captura cada cambio de la base de datos, los rastrea y los reproducirá en QA cuando se envíe la base de datos. Como tal, el desarrollador debe aplicar los cambios al ambiente de desarrollo de la misma manera que esperaría que se apliquen los cambios en QA y Prod. Hay dos tipos de cambios que App Builder captura en desarrollo y se aplica durante una actualización de QA y PROD:

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 manera similar a una regla de creación/actualización/eliminación 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 de 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 desde el departamento de desarrollo al de control de calidad, esto solo lo deben hacer 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 desde el departamento de desarrollo al de control de calidad y producción. A continuación, se presentan algunos escenarios que se deben 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 use. 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.

Varias Aplicaciones Que Utilizan la Misma Fuente de Datos¶

Supongamos que tanto la aplicación X como 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 añadido columnas a objetos de datos en la fuente de datos A, y ambos equipos han añadido controles a las aplicaciones X e Y que están vinculados a esas columnas. Uno de los equipos también ha eliminado un control de la aplicación X y ha eliminado 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 al control de calidad, 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 no podrá eliminar la columna. Es mejor incluir todas las aplicaciones y fuentes de datos a las que se hace referencia en la solución para garantizar que la actualización sea exitosa.

Agregar una Columna No Nula¶

Aproveche las reglas de migración. Suponga que se envió una tabla "Empleado" a QA y PROD y se llenó con datos de producción. Luego, un desarrollador elimina todas las filas de esa tabla para agregar una columna NO NULA (Active Boolean Allow Nulls = False). Esta operación se realizará correctamente en el ambiente de desarrollo porque no hay registros de empleados. Sin embargo, cuando se aplica este conjunto de cambios en QA o PROD, fallará. Una base de datos RDMBs no permitirá que se agregue una columna no nula a una tabla que contiene filas.

En cambio, en el ambiente de desarrollo, no elimine los registros de los empleados. Déjelos de manera que el ambiente sea representativo de los ambientes de destino de QA y PROD. Agregue la nueva columna a la tabla Employee, 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 para que sea Allow Nulls = False. Esta operación se realizará correctamente en el desarrollo y se realizará correctamente cuando se envíe a QA y PROD. App Builder realizará los siguientes pasos durante la actualización:

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

Modificar la Clave Principal de una Tabla¶

Tome precauciones al modificar una clave principal en una tabla que ya se envió a QA y que contiene datos. Nuevamente, es mejor asegurarse de que el ambiente de desarrollo tenga datos en la tabla, de modo que represente mejor los ambientes de QA y de producción. Hay varias formas en que una clave principal puede cambiar. A continuación, se muestra un ejemplo:

Supongamos que Employee tiene una columna EmployeeId Integer Primary Key. Supongamos también que EmployeeAccrual tiene una columna EmployeeId Integer (la clave externa hace referencia a Employee.EmployeeId). La tabla Employee también tiene una columna SocialSecurity (String Unique Allow Nulls = False).

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 EmployeeAccumual.
2. Cree una regla de migración que actualice EmployeeAccrual.SocialSecurity para que sea Employee.SocialSecurity y una las dos tablas en EmployeeId. Ejecute la regla de migración.
3. Cambie el Seguro Social en EmployeeAccurual para que Permitir valores nulos = 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 relación entre Employee y EmployeeAccrual en la Seguridad Social

App Builder registrará estos pasos y los ejecutará con éxito mientras se actualiza el control de calidad y la producción.

Evitar Importar Esquema¶

Si la intención es mover una base de datos física de Dev a Qa y luego a Prod, y modificar aún más esa base de datos física a través de la App Builder uI y envíe esos cambios a QA y Prod, luego no use la función de importación para App Builder fuentes de datos. Para impulsar los cambios realizados en el desarrollo, App Builder captura esos cambios a medida que se realizan a través de su interfaz de usuario. La importación de una fuente de datos omite la App Builder uI, sincronizando la App Builder modelo lógico 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. 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, 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, 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¶

Los siguientes elementos deben tenerse en cuenta y completarse antes de comenzar la construcción an App Builder liberación:

1. Asegúrese de que el App Builder el usuario db tiene 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 tanto de la App Builder base de datos y cualquier base de datos que sufra cambios físicos y/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 el que se ejecuta 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 del App Builder aplicación.
2. Cree una lista de todas las Fuentes de datos adjuntas para la aplicación para la que está creando una versión. Esta información está disponible en App Builder IDE, cree su aplicación, haga clic en su aplicación y revise el Panel de fuentes de datos resultante.
3. Cree una Plantilla de lanzamiento de aplicación 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. Establezca Lógica y Física únicamente para las fuentes de datos para las que administrará los cambios de esquema con App Builder.
6. Revise y confirme los pasos de administración de cambios de bases de datos abiertas 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 se han marcado para Instalación lógica y Instalación física.
8. Una vez que se complete la Configuración de datos, confirme la Configuración de datos.
9. Genere la versión. Para obtener instrucciones detalladas sobre cómo generar una versión dentro de App Builder en sí, consulte Crear una versión artículo.