De

<keywords content="keywords"> process improvement, after production, development, new version, </keywords>

Mejoramiento Continuo y Desarrollo Posterior a un Deployment

Como parte del mejoramiento continuo de procesos, Bizagi se encuentra diseñado para permitir la evolución de sus procesos a medida que el negocio evoluciona.
Algunas veces esto implica realizar cambios en la información de negocio, reglas de negocio e incluso modificar el flujo del proceso.

Dependiendo de los cambios requeridos, se recomienda generar una nueva versión del proceso. Esta es una forma segura de realizar los cambios sin comprometer la infomación de los casos actuales que ya se encuentran en Producción.

Las modificaciones que se deban implementar a un proceso que ya se encuentre en ambiente de Producción deberían ser realizadas siempre en el ambiente de Desarrollo (y llevadas posteriormente a Producción realizando un nuevo deployment).
Recuerde que se recomienda fuertemente utilizar el ambiente de Pruebas para realizar deployments de las versiones de proceso y probar en dicho ambiente antes de realizar un deployment a Producción.
De esta manera, siempre se podrá revisar y probar los procesos para garantizar que en su despliegue a Producción tengan el comportamiento esperado.

Para un mejoramiento continuo de los procesos en Producción y deployment posteriores, tenga en cuenta las siguientes recomendaciones:

1. Los objetos en Producción deben permanecer en Desarrollo

Una vez que se despliega un proceso a Producción (o se encuentra marcado como Release Candidate en el ambiente de Pruebas), no es posible eliminar en el ambiente de Desarrollo, los objetos que ya se usan por esa versión de proceso.
Al referirse a "objetos" se abarca: entidades, atributos y relaciones, formas, expresiones, políticas y reglas en general, asignaciones de participantes, campos de usuario, sistemas, elementos de la organización, entre otros.

De manera similar, no es posible modificar el nombre para estos objetos (la propiedad "Nombre" se torna no-editable).
Esta restricción garantiza la estabilidad del ambiente de Producción en los siguientes deployments.

2. Edición en Desarrollo de los objetos en Producción

Una vez que se despliega un proceso a Producción (o se encuentra marcado como Release Candidate en el ambiente de Pruebas), en Bizagi Studio (el ambiente de Desarrollo) se controlan ciertas posibilidades para la edición de esos objetos que ya se usan por esa versión de proceso.
Esta restricción garantiza la estabilidad del ambiente de Producción en los siguientes deployments.

Esto significa que para una versión de proceso que ya haya sido llevada a Producción (o que esté marcada como Release Candidate), se mantienen para sus objetos usados las siguientes posibilidades de edición controladas por Bizagi Studio en el ambiente de Desarrollo:

3. Versionamiento de procesos

Una vez que se despliega un proceso a Producción (o se encuentra marcado como Release Candidate en el ambiente de Pruebas), la versión actual queda bloqueada de manera que no se puedan realizar cambios adicionales al modelo en el flujo de trabajo. Esto quiere decir que el proceso no puede ser editado utilizando el paso 1 del ayudante de procesos (adición, modificación o eliminación de figuras o transiciones).

Si se desean hacer este tipo de cambios al flujo de proceso, se debe crear una nueva versión de ese proceso (y sus subprocesos).
Por otra parte, es posible decidir no crear una nueva versión del proceso si los cambios relacionados son del tipo (ejemplos):

• Añadir un atributo o entidad.
  
• Añadir o editar las expresiones existentes (eventos, asignaciones, invocaciones a servicios web).
  
• Crear y asignar una nueva forma de consulta.

En otras palabras, no es necesario crear una nueva versión de proceso si los cambios se pueden realizar a través del Ayudante de Procesos a partir del paso 2 en adelante.
Sin embargo, tenga en cuenta que estos cambios serán aplicados en la versión existente en producción, y por lo tanto, las modificaciones afectarán los casos de producción existentes.

En este escenario es todavía más importante la ejecución de pruebas y precauciones necesarias de forma que no se generen errores de inconsistencia para los casos existentes en producción.

Vea información adicional sobre los lineamientos y recomendaciones para una nueva versión de proceso.

4. Nuevas llaves de negocio

Cuando se definan nuevas llaves de negocio, se recomienda asegurar que los registros en Producción para la entidad de la nueva llave, vaya de acuerdo a esta nueva restricción. De lo contrario, al intentar aplicar la restricción de la llave de negocio se puede presentar un error durante el procedimiento de deployment (para garantizar la estabilidad del ambiente de Producción).
Por ejemplo, para una entidad llamada "Producto", no se debe definir como llave de negocio el atributo "Nombre_Producto" si en Producción hay más de un registro que tiene "Crédito" como su Nombre_Producto.

5. Collation de la base de datos sin alterar (aplica para proyectos que utilicen SQL Server)

Nunca se debe alterar el collation de la base de datos o de la instancia del servidor de base de datos.

En los proyectos de Bizagi, se requiere que el collation para el servidor y la base de datos de los diferentes ambientes sea el mismo.

Esto es un requerimeinto que debe satisfacerse desde el principio -el collation se define al momento de instalar la instancia de base de datos SQL Server (antes del primer deployment).

La alteración del collation no es una buena práctica y se puede resultar con pérdida de información en la base de datos.

Artículos Relacionados

• Deployment de Bizagi
• Cómo realizar un deployment a Pruebas
• Cómo realizar un deployment a Producción
• Consideraciones previas y requerimientos para un deployment

<comments/>