Nueva publicación
Pregunta
· 10 mar, 2020

InterSystems Cache, Visual Studio Code, GIT y Namespaces

#Caché #InterSystems IRIS #InterSystems IRIS for Health

Hola

Estoy trabajando con un equipo de desarrolladores que quieren dar el salto a InterSystems 2019.4, actualmente utilizan Object Script para sus desarrollos, y no utilizan ningún tipo de sistema de control de versiones. 

Yo desconozco como funciona todo este entorno, por lo que he creído que sería buena idea solicitar ayuda en la comunidad, ya que parece bastante activa, y así asegurarnos de seguir buenas prácticas. 

Actualmente, se trabaja sobre distintos Namespace en la misma plataforma en producción. Cada desarrollador debe tener una imagen Docker donde trabajar en su local, y crear clases/funciones/etc con objectScrip y en VS Code. El problema nos ha surgido al no saber como gestionar el código de los distintos NameSpace en un solo repositorio, y no hemos encontrado documentación que nos oriente respecto a esto...

¿Alguna idea sobre como deberíamos trabajar?

Comentarios (14)2
Inicie sesión o regístrese para continuar
David Reche · 10 mar, 2020

Hola Jorge, 

Me surgen varias dudas. Si trabajáis con diferentes Namespaces es porque son proyectos diferentes o ¿cómo están relacionados?. En principio lo lógico es que cada Namespace disponga de un Repo diferente. También podría estar todo junto si no hay solapamiento entre nombres de paquetes y clases. Ya que la idea es que cada desarrollador tenga un entorno aislado y por lo tanto el que toque clases de un Namespace normalmente no tocará las otras y esas no molestan. Sin embargo es muy importante que los despliegues en el servidor en producción se hagan de manera controlada y mediante paquetes de despliegue que se construyan ex-profeso para el mismo. No se si me he explicado bien...

Pero en resumen, una cosa es como se organiza el código en el desarrollo y otra diferente es como repartas las clases en el despliegue

0 0
Jorge Jerez · 10 mar, 2020

Hola David,

Primero agradecerte tu rápida respuesta. Creo que los diferentes NameSpaces referencian distintos proyectos, si.(disculpa mi desconocimiento, como aquel que dice acabo de incorporarme a este mundo). Entiendo que la forma correcta sería tener un repo para el código de cada NameSpace y ¿quizá otro para el código que sea común a todos los Namespaces? 

0 0
David Reche · 10 mar, 2020

Sí claro, eso tiene mucho sentido. Lo único es que os toca gestionar varios Repos. Pero será muy práctico ir identificando funcionalidad común y llevarlo  al Repo común. Luego las clases comunes gestionarlos como librerías independientes. Si el esquema que tenéis se despliega todo en la misma instancia entonces también podéis hacer mapeos de clases entre Namespaces.

0 0
Jorge Jerez · 10 mar, 2020

¿Habría alguna forma de realizar este mapeado en el código? Entiendo que cuando desarrollamos en local sobre distintos NameSpaces, si lo subimos todo a un mismo repositorio para desde ahí desplegar en producción, tendríamos que remapear, ¿cierto? 

Por otro lado, Francisco nos ha dejado otra posibilidad para trabajar con esto, ¿crees que sería una buena solución?

0 0
David Reche · 10 mar, 2020

Lo que @Kurro Lopez te ha presentado con detalle es lo que te decía en la primera respuesta:

También podría estar todo junto si no hay solapamiento entre nombres de paquetes y clases.

Como ellos ya lo han hecho han elegido la forma que mejor les ha funcionado. Por lo que desde luego es una buena solución.

El uso de mapeo de paquetes es util para no tener que duplicar clases (y código) en diferentes Namespaces. Pero es un mecanismo asociado a la operación/despliegue pero no al desarrollo. Son cuestiones diferentes. Puedo desarrollar un paquete de forma común y luego repartirlo entre varios namespaces (como una librería) o puedo ponerlo en un lugar accesible por varios (aka mapeo). Pero lo haga de una manera o de otra no me afecta a como lo desarrollo.

0 0
Kurro Lopez · 10 mar, 2020

Hola Jorge.

Bienvenido a la comunidad.

En mi empresa tenemos varios proyectos separados por NAMESPACES y cada proyecto tiene un repositorio independiente. Pero a lo mejor te podría servir la forma que lo tenemos distribuido, luego tener el mismo repositorio (GIT, TFS, etc..) para todo el conjunto:

1) Crear un directorio común con todos los namespaces, cada namespace tendrá su propia carpeta

2) Guardar en el directorio principal (Healthshare) el area de trabajo, pero cada carpeta que no sea visible (luego explico el por qué)

{
    "folders": [
        {
            "path": "."
        },
        {
            "name": "Common",
            "path": "./COMMON"
        },
        {
            "name": "Customers",
            "path": "./CUSTOMERS"
        },
        {
            "name": "Documents",
            "path": "./DOCUMENTS"
        },
        {
            "name": "Hospital",
            "path": "./HOSPITAL"
        }
    ],
    "settings": {
        "files.exclude": {
            "**/.git": true,
            "Common": true,
            "Customers": true,
            "Documents": true,
            "Hospital": true
        }
    }
}

Quedará el siguiente aspecto en VSCode

3) Configuramos el VSCode ObjectScript de @Dmitry Maslennikov de la siguiente forma:

en MyWork.code-workspace. Esta sería la configuración general de conexión con el servidor de Ensemble / ObjectScript

    "settings": {
        "files.exclude": {
            "**/.git": true,
            "Common": true,
            "Customers": true,
            "Documents": true,
            "Hospital": true
        },
        "objectscript.conn": {
            "active": true,
            "host": "localhost",
            "port": 57772,
            "username": "_SYSTEM",
            "password": "SYS",
            "https": false,
            "links": {}
        }  

 

4) En cada uno de los directorios, añadimos una configuración por carpeta con el nombre del namespace que esté trabajando cada subconjunto

{
    "objectscript.conn": {
        "ns": "COMMON"
    }
}

 

De esta forma cada workspace trabajará con su conexión correspondiente

A la hora de subir el repositorio, se sube en Git como cualquier otro fichero, incluso se tendría el equipo totalmente actualizado dado que se podría sincronizar los otros NAMESPACE a la vez y tener actualizado el entorno de desarrollo.

Espero que esta forma de distribuición te sirva como nos está sirviendo a nosotros.

Un saludo,

Francisco López

3 0
Jorge Jerez · 16 mar, 2020

Hola Francisco 

Tu respuesta nos está siendo de mucha ayuda para estructurar nuestro repo, estoy realizando pruebas y me he encontrado con un problema. He creado un workspace similar al que tu has compartido:

 Sin embargo, y como se ve en la parte inferior de la imagen, el namespace siempre es 'USER'. Dentro de cada carpeta correspondiente al namespace he incluido el archivo setting.json:

{

    "objectscript.conn": {

        "ns": "NAME"

    }

}

¿Es posible que esté realizando algo mal? Dentro de mi local host existen ambos namespace

0 0
Kurro Lopez · 16 mar, 2020

Entiendo que el setting.config de cada uno de los folders contiene el nombre del namespace a que se quiere desarrollar.

Por defecto siempre se carga en namespace "USER", si no puede conectarse con el servidor y no encuentra el namespace indicado se conecta al namespace por defecto.

Como comentas, tienes un namespace con ese nombre. Prueba a seleccionar el folder "scr" e intenta crear un fichero (prueba.cls) y ver que te cambia el namespace correcto

0 0