Introducción
A menudo, existen situaciones en las que usted necesita aplicar un cambio menor en una parte específica de un proyecto sin afectar la mayor parte de este.
Dado que en tales situaciones usted aún necesita hacer un deployment de cambios, por mínimos que sean, debe asegurarse de que dicho deployment no incluya objetos que puedan alterar otras partes de su proyecto.
Algunos ejemplos de estas situaciones son:
•La necesidad de cambiar textos o etiquetas específicas en Formas.
•Cambiar solo una Forma de Consulta.
•Cambiar una regla de negocio.
•Cambiar propiedades de ejecución de una Tarea, como el número de reintentos o el comportamiento asíncrono.
Para estas situaciones, Bizagi introduce la funcionalidad de Microdeployment.
Consideraciones con versiones de Bizagi
Un Microdeployment considera las mismas restricciones que un deployment normal. Cuando usted realiza un microdeployment, debe asegurarse de que la versión de su ambiente destino, Pruebas o Producción, tenga la misma versión o una superior a la de su ambiente de Desarrollo.
Por ejemplo, usted puede hacer un deployment de Spring 2025 a Summer 2026, o from Fall 2025 a Fall 2025. No puede aplicar un Microdeployment a versiones inferiores, por ejemplo, de Summer 2025 a Fall 2025.
Antes de empezar
Existen algunos aspectos importantes a considerar antes de iniciar un Microdeployment:
•Un Microdeployment, como procedimiento, NO sigue los mismos pasos de configuración de un deployment tradicional. Usted puede considerarlo como un procedimiento más corto y rápido en comparación con otros deployments.
•Como tal, NO se realiza un análisis exhaustivo de dependencias al exportar un paquete a un ambiente.
Esto significa que cualquier metadata incluida en el archivo .bex exportado debe existir previamente en el ambiente donde dicho archivo se importará, por ejemplo, el ambiente de Pruebas o Producción.
•Además de las consideraciones generales de metadata, esto también aplica específicamente a los elementos relacionados con tareas. Las referencias a formas, reglas o elementos dependientes no se transportan y deben existir previamente en el ambiente destino.
•
En otras palabras, al realizar un Microdeployment hay un aspecto clave para un deployment exitoso: las referencias de objetos.
La siguiente tabla resume los posibles resultados:
Situación |
Resultado |
|---|---|
Objetos desplegados solo hacen referencia a otros objetos ya presentes en la metadata del ambiente destino |
El Microdeployment es exitoso |
Objetos desplegados hacen referencia a otros objetos no presentes en la metadata del ambiente destino |
El Microdeployment falla |
|
Para utilizar un Microdeployment, las reglas básicas de ambientes siguen siendo aplicables, como asegurarse de que exista un solo ambiente Producción válido por proyecto de Bizagi. |
¿Qué puede incluir en un Microdeployment?
No todos los objetos pueden incluirse en un Microdeployment debido a que algunos tienen referencias complejas.
Los siguientes objetos son elegibles:
•Acciones de actividad
•Agentes de IA
•Columnas personalizadas
•Plantillas de documento
•Formas
•Mapeos
•Plantillas de mensaje
•Parámetros administrables en Desarrollo
•Participantes
•Procesos compartidos a Procesos en Vivo
•Consultas
•Reglas
•Formas de búsqueda
•Formas de inicio
•Triggers
•Vocabularios
Adicionalmente, Microdeployment soporta actualizaciones a nivel de tarea, permitiendo transportar propiedades específicas de ejecución de los siguientes objetos:
•Tareas de usuario
•Tareas de servicio
•Tareas manuales
•Eventos
•Compuertas
Objetos no incluidos en este alcance:
•Flujos de secuencia o conectores
•Artefactos
•Subprocesos como objetos independientes
Microdeployment de Tareas
El Microdeployment de Tareas le permite actualizar propiedades específicas de tareas dentro de un proceso sin volver a hacer un deployment del proceso completo ni afectar elementos no relacionados.
Propiedades soportadas
Solo se incluyen propiedades relacionadas con la ejecución, como:
•Nombre
•Nombre para mostrar
•Número de reintentos
•Estado asíncrono
Las propiedades de modelado visual, como cambios de posición, se excluyen y no aparecen en la Consulta Gráfica.
Comportamiento y alcance
•Solo se transporta el objeto principal y las referencias permanecen como identificadores.
•Los objetos hijos y elementos referenciados se excluyen.
•El paquete contiene únicamente las propiedades del objeto seleccionado.
•Las validaciones existentes y reglas de deployment permanecen sin cambios.
Consideraciones
•El Proceso Padre debe existir previamente en el ambiente destino.
•Las tareas de tipo subproceso solo son soportadas si el proceso relacionado ya existe en el ambiente destino.
•Usted es responsable de asegurar que las dependencias necesarias ya estén previamente desplegadas mediante un deployment.
Microdeployment de un Proceso
Para realizar un Microdeployment:
1.En Bizagi Studio, vaya a la pestaña Exportar/Importar y seleccione la opción Microdeployment para obtener la lista de objetos disponibles.
2.Seleccione uno o más objetos.
3.Genere un paquete que contenga solo los objetos seleccionados.
4.Vaya al Management Console del ambiente destino e importe el paquete.
5.Espere a que el sistema valide y aplique los cambios.
6.Revise el Log de Auditoría donde cada operación se registra automáticamente.
Ejemplo
Un ambiente ya ha sido configurado con el proceso Suscripción de póliza de seguro de vehículos, el cual se encuentra operativo en un ambiente Producción.
En este ejemplo, el Microdeployment tiene como destino un ambiente en la nube.
Descripción
El estado inicial de este escenario es el siguiente:
•El proceso Suscripción de póliza de seguro de vehículos tiene una primera actividad llamada Registrar datos del cliente y del vehículo.
•La Forma (UI) para esa actividad se ve como se muestra en la imagen original.
•Su gerente indicó que el grupo Información del caso que se muestra en la Forma ya no es necesario. En otras palabras, usted debe eliminar este grupo de la Forma.
•Asumiendo que usted y sus compañeros de equipo están trabajando actualmente en el ambiente Desarrollo, mientras implementan otros cambios no finalizados, entonces queda claro que necesita realizar un Microdeployment, para que esos otros cambios no afecten la operación de su proceso.
Realización de los cambios en el ambiente Desarrollo
Lo primero es realizar los cambios menores en el proceso, según lo indicado por su gerente.
En este caso, el grupo ya no está presente y Información del titular de la póliza pasa a ser el elemento superior en la Forma IP_CustomerVehicleBasicData.
Generar un paquete de deployment con los objetos específicos
1.Una vez implementados los cambios, usted procede a generar un archivo .bex considerando únicamente la Forma en cuestión. Para hacerlo, vaya a la pestaña Exportar/Importar y seleccione la opción Microdeployment.
2.En la ventana del asistente de Microdeployment, debe seleccionar el tipo de Microdeployment entre Procesos y Matriz de Experiencia. Para este caso, seleccione la vista Procesos.
3.Luego, debe filtrar los objetos que desea incluir. Seleccione los objetos en el panel izquierdo del asistente y, en el panel derecho, seleccione el proceso o subproceso de los objetos seleccionados. Puede usar el campo Filtro para encontrar el proceso. Una vez haya seleccionado los elementos, haga clic en Siguiente.
De acuerdo con su selección, se muestra una lista de todos los objetos disponibles para Microdeployment.
4.Use el campo Filtro o navegue en el panel para encontrar el elemento modificado y márquelo para indicar que será incluido en el Microdeployment.
5.Haga clic en Exportar y seleccione una carpeta en su equipo donde desea guardar el archivo .bex.
Importar el paquete en el ambiente destino
Para importar el paquete en el ambiente destino, siga estos pasos:
1.Diríjase a las opciones de administración de su ambiente destino desde el Management Console.
2.Haga clic en la opción Importar o Cargar nuevo paquete y seleccione el archivo .bex recientemente creado. Confirme que desea cargarlo en su ambiente y espere a que el proceso finalice.
Usted puede verificar que el Microdeployment fue exitoso revisando la Forma de la primera tarea, asegurándose de que el grupo Información del caso ya no esté presente. Dado que la importación no generó errores, puede asumir que no se introdujo nueva metadata en su ambiente destino.
De esta manera, usted puede tener la tranquilidad de que no se incluyeron cambios no deseados por error.
En este punto, usted ha llevado a cabo exitosamente un Microdeployment y ha cumplido con la solicitud de su gerente.
|
Considere lo siguiente al usar un Microdeployment: •El Microdeployment está disponible al usar Deployment. •Los objetos referenciados deben existir previamente en la metadata del ambiente destino. No se incluyen automáticamente debido a la ausencia de un análisis completo de dependencias. Esto también aplica a objetos relacionados con tareas y sus dependencias. •Si usted está realizando un Microdeployment de columnas personalizadas, asegúrese de que variables o vocabularios ya existan en el ambiente destino. •El Microdeployment de Tareas solo incluye propiedades de ejecución y no transporta formas, reglas o configuraciones visuales. •El paquete incluye solo las propiedades de los objetos seleccionados, asegurando un impacto mínimo en el ambiente destino. •En Automation Service, una ventana de mantenimiento puede activarse automáticamente si el paquete requiere reiniciar el ambiente en la nube. Consulte la documentación de la Ventana de mantenimiento para obtener más información. |
Solución de problemas
Un Microdeployment falla cuando el paquete incluye objetos de metadata que no existen en el ambiente destino.
En ese caso, revise los Logs de deployment en la Management Console en Rastreo > Trazas > Ejecución. Estos registros muestran los GUID de los objetos faltantes para ayudarle a resolver el problema.
Last Updated 1/23/2023 12:10:15 PM