Cree una biblioteca personalizada de UI5 ​​con control de versiones utilizando un espacio de nombres de varias versiones

Motivación

Para una buena estructuración en un proyecto de desarrollo, es una buena idea encapsular diferentes componentes y ponerlos a disposición para su reutilización.
En el área de UI5 ​​existe la opción de un biblioteca o un componente de reutilización.

Una buena visión general de las opciones. es un artículo de 2018 por Nabi que todavía discute temas actuales:

Estos componentes pueden ser utilizados por muchas aplicaciones sin tener que desarrollarlos una y otra vez.
La gran desventaja es que los cambios en estos componentes pueden tener un impacto significativo en muchas aplicaciones.

El problema es que se supone que el componente mejora y acelera el trabajo.
En cambio, esto hace que los componentes ya no se toquen porque el riesgo de romper algo es demasiado grande o el esfuerzo de prueba es demasiado extenso.

Idea

El principal problema es que solo se debe utilizar la versión que está disponible en el sistema. No es posible utilizar diferentes versiones de un componente de reutilización en el mismo sistema.
Funciona de manera diferente, por ejemplo, en el ecosistema JavaScript de NPM, donde los cambios crean un nuevo número de versión que luego puede ser utilizado explícitamente por una aplicación.
¿No sería genial si pudiéramos usar este sistema para bibliotecas y reutilizar componentes?

Concepto

Un componente está organizado en un espacio de nombres único, el espacio de nombres del componente es igual al nombre del componente.
Podríamos usar esto para incluir la versión de un componente en el espacio de nombres, ya que siempre se llama a un componente específico con el espacio de nombres en el manifiesto.
Para el control de versiones para el ampliamente utilizado versionado semántico puede ser usado

Entonces, en lugar de verse así «ui.component.orderhandling», el espacio de nombres de un componente podría verse así «ui.component.orderhandling.v1_2_4».

Esta variante de espacio de nombres es solo una sugerencia que utilizo y, dado que aún no existe una solución universal para ella, el control de versiones se puede personalizar como más le convenga.
La versión también se puede separar con puntos y verse así:
“ui.component.orderhandling.v1.2.4”.
Sin embargo, dado que esto sugiere una partición, se recomienda utilizar guiones bajos.

También el control de versiones con mayor menor y parche se puede adaptar para el caso de uso propio y, por ejemplo, el parche se puede omitir por completo.
Sin parche, por ejemplo, una versión «ui.component.orderhandling.v1_2» se puede sobrescribir con una corrección sin tener que adaptar el manifiesto de la aplicación.
Pero esto debe decidirse de manera diferente para cada caso de uso.

Prueba de concepto

Mi proyecto de código abierto UI5 actual es el reutilizar componente UI5 ​​Excel Subir.
Aquí quería implementar la idea de un espacio de nombres de varias versiones desde el principio.
Pedro Muessig y franco weigel me dio la idea y me ayudó con la implementación de esta prueba de concepto.

Desarrollo

El código de la última versión consumida por una aplicación está siempre disponible en npmjs.com:
El código fuente está disponible aquí: https://github.com/marianfoo/ui5-cc-excelSubir

Puede ver el espacio de nombres con la versión en el código y, por supuesto, también en el ui5.yaml:

specVersion: '2.6'
type: module
metadata:
  name: ui5-cc-excelupload
resources:
  configuration:
    paths:
      /thirdparty/customControl/excelUpload/v0_10_0/: ./dist/

Por supuesto, sería una molestia cambiar siempre este espacio de nombres manualmente. Así que aquí usamos una combinación de script de nodo y el «ui5-tooling-stringreplace” módulo.

Como base para la versión siempre tomamos el atributo de versiones del paquete.json.
La secuencia de comandos del nodo toma esta versión y reemplaza la versión en los archivos yaml por la componentePara el construir y para el Despliegue del sistema ABAP.

Dado que la versión actual ahora está en los archivos yaml, podemos usarlos y activar la compilación con las herramientas ui5.
Usamos ui5-tooling-stringreemplazar y reemplazar marcadores de posición en el código con el espacio de nombres actual.

Entonces, el código original se convierte en la variante final con el espacio de nombres de versiones:

const Component = UIComponent.extend("cc.excelUpload.XXXnamespaceXXX.Component", {

const Component = UIComponent.extend("cc.excelUpload.v0_10_0.Component", {

Consumo

El componente de reutilización se puede consumir en una aplicación de dos formas.
Por un lado, puede integrarse directamente en la aplicación y desplegarse juntos, o el componente puede desplegarse de forma centralizada en un servidor SAP.
Tengo describió las dos opciones en la documentación para la carga de Excel.

La parte importante para el componente se define en manifiesto.json donde también se especifica el espacio de nombres.

"componentUsages": {
  "excelUpload": {
    "name": "cc.excelUpload.v0_10_0"
  }
},

Aquí es donde la gran ventaja se hace evidente. Cada aplicación puede definir su propia versión para ser utilizada.
Por lo tanto, se pueden crear versiones cada vez más nuevas con cambios sin afectar todas las aplicaciones.
Todo lo demás funciona normalmente como con cualquier otro componente de reutilización.

Despliegue

El caso de uso para la implementación en un sistema ABAP es probablemente el más común.
Como ya se mencionó anteriormente, también he desarrollado y documentado un concepto aquí.
El problema con el control de versiones de un componente es que el nombre en el sistema debe cambiarse una y otra vez cuando se crea una nueva versión.
Si esto no se cambia, la versión más nueva siempre sobrescribirá la anterior.

Como ejemplo, he creado un separado Yaml archivo para la implementación en SAP ABAP Platform 1909, Developer Edition (afortunadamente, esto todavía se está ejecutando en mi sistema) para aclarar esto.
El lineas esenciales en este archivo seria:

app:
  name: Z_XUP_v0_10_0

Desafortunadamente, la cantidad de caracteres es limitada, por lo que el prefijo frente a ellos se mantuvo mínimo para asegurarnos de que podamos mantener el esquema del nombre.
Dado que la versión se actualiza aquí con un script de nodo, por supuesto, se puede usar el esquema de nomenclatura propio. Solo debe tenerse en cuenta que el nombre está limitado a 15 caracteres.
Como se explicó anteriormente, en caso de un cambio de versión, el nombre de la aplicación cambiaría automáticamente, por ejemplo, a Z_XUP_v0_10_1.

Esto hace posible que diferentes aplicaciones consuman diferentes versiones del mismo componente.
Como ilustración simple, aquí hay un diagrama que muestra la implementación en un sistema ABAP y el consumo de una plataforma de lanzamiento Fiori.

Conclusión

El procedimiento básico para usar un espacio de nombres de múltiples versiones en un componente o biblioteca tiene algunos gastos generales para configurar.
La gran ventaja es que el componente se puede desarrollar de forma ágil y con un mínimo esfuerzo de prueba.
Por lo tanto, se puede evitar la obsolescencia y muerte de grandes componentes muy utilizados.

Una desventaja de este enfoque es que si un cambio realmente afectara a todas las aplicaciones inmediatamente, la versión también debe cambiarse en todas las aplicaciones.
Por lo tanto, el enfoque descrito no es el óptimo para todos los componentes y bibliotecas.

¿Es este enfoque práctico y útil para usted y también ha encontrado los mismos problemas descritos?
Dado que aún no he visto un enfoque comparable, ¿tiene alguna sugerencia para mejorar esto?
Estoy abierto a sugerencias y discusión.

Enlaces