#Control del origen

La interfaz de usuario de Interoperabilidad ahora incluye experiencias modernizadas para las aplicaciones DTL Editor y Production Configuration, las cuales están disponibles para su activación en todos los productos de interoperabilidad. Podéis alternar entre las vistas moderna y tradicional. Todas las demás pantallas de interoperabilidad permanecen en la interfaz de usuario estándar. Tenéis que tener en cuenta que los cambios se limitan a estas dos aplicaciones, y a continuación se identifica la funcionalidad que está disponible actualmente.

Cuando desplegáis código desde un repositorio, la eliminación de clases (archivos) podría no reflejarse en vuestro sistema CICD. Por ejemplo si en vuestro repositorio elimináis una clase y queréis que se refleje en el código desplegado.
Aquí tenéis un sencillo comando de una sola línea para eliminar automáticamente todas las clases en un paquete específico que no hayan sido importadas. Se puede ajustar fácilmente para una variedad de tareas adicionales:

set packages = "USER.*,MyCustomPackage.*"
set dir = "C:\InterSystems\src\"
set sc = $SYSTEM.OBJ.LoadDir(dir,"ck", .err, 1, .loaded)
set sc = $SYSTEM.OBJ.Delete(packages _ ",'" _ $LTS($LI($LFS(loaded_",",".cls,"), 1, *-1), ",'"),, .err2)

El primer comando compila las clases y también devuelve una lista de las clases cargadas.
El segundo comando elimina todas las clases de los paquetes especificados, excepto las clases que se cargaron justo antes en el paso anterior.

Una solución de control de versiones eficaz permite a las organizaciones gestionar bases de código complejas, facilitar una colaboración sin fisuras dentro de los equipos de desarrollo y agilizar los procesos de despliegue.

Sonic Healthcare, un proveedor líder de servicios médicos corporativos, de práctica general, radiología y patología, ha mejorado significativamente la visibilidad y el control sobre su entorno complejo al implementar el control de versiones de Deltanji.

En el vasto y variado mercado de las bases de datos SQL, InterSystems IRIS destaca como una plataforma que va mucho más allá de SQL, ofreciendo una experiencia multimodelo perfecta, y siendo compatible con un amplio conjunto de paradigmas de desarrollo. Especialmente el avanzado motor objeto-relacional ha ayudado a organizaciones a utilizar el enfoque de desarrollo más adecuado para cada una de sus cargas de trabajo intensivas en datos; por ejemplo, ingerir datos a través de Objetos y consultarlos simultáneamente mediante SQL. Las Clases Persistentes corresponden a tablas SQL, sus propiedades a columnas de la tabla y se accede fácilmente a la lógica de negocio utilizando Funciones Definidas por el Usuario o Procedimientos Almacenados. En este artículo, nos centraremos un poco en la magia que se encuentra justo debajo de la superficie y discutiremos cómo puede afectar vuestras prácticas de desarrollo e implementación. Esta es un área del producto que tenemos planificado evolucionar y mejorar, así que no dudéis en compartir vuestras opiniones y experiencias en los comentarios al artículo.

¡Hola Comunidad!

Como sabéis, las soluciones de Interoperabilidad de InterSystems IRIS contienen diferentes elementos de la solución, como: producciones, reglas de negocio, procesos, transformaciones de datos, mapeos de registros, etc. Y a veces podemos crear y modificar estos elementos con herramientas visuales en la UI. Y por supuesto necesitamos una forma práctica y sólida de controlar el código fuente con los cambios realizados con herramientas de UI.

Durante mucho tiempo, esto era un proceso de configuración manual (exportar clase, elemento, global, etc.) o engorroso, por lo que el tiempo ahorrado con la automatización del control de fuentes de la UI competía con el tiempo perdido en configurar y mantener la configuración.

Ahora ese problema ya no existe. Con dos enfoques: desarrollo "package first" y uso del paquete IPMgit-source-control, de @Timothy.Leavitt.

Os explico los detalles a continuación.