InterSystems Package Manager (IPM) est un outil permettant de déployer les paquets et les solutions dans InterSystems IRIS avec les dépendances.
Télécharger le client Package Manager.
Bonjour, chers collègues développeurs d'InterSystems IRIS !
On me demande souvent, notamment en ce qui concerne les bonus techniques que nous encourageons pour chaque concours Open Exchange, pourquoi nous donnons constamment des bonus pour les tests de qualité Docker, IPM et ObjectScript.
En fait, il est très facile de répondre à cette question.
Nous avons publié IPM 0.9.0. J'ai déjà évoqué une partie de l'historique et du raisonnement ici ; pour résumer, il s'agit d'une version importante pour deux raisons : elle représente une réunification attendue depuis longtemps de notre travail interne et communautaire autour de la gestion des paquets ObjectScript centrée sur IRIS, et elle présente certaines incompatibilités rétroactives. Il existe plusieurs incompatibilités rétroactives nécessaires dans notre feuille de route, et nous les avons regroupées ; ce ne sera pas une nouvelle norme.
Avec IRIS 2024+, les utilisateurs peuvent héberger des applications WSGI à l'aide de Security.Applications. À titre d'exemple, un utilisateur peut faire quelque chose comme ceci.
Après quelques discussions au Global Summit et l'utilisation d'un grand nombre de gestionnaires de paquets dans mon développement quotidien (npm, nuget, Chocolatey, etc) en plus de l'utilisation récente de l'InterSystems Package Manager pour un processus CICD que je suis en train de construire en utilisant Intersystems IRIS et IRIS 4 Health, je voulais un moyen facile et intégré pour rechercher/visualiser/installer des paquets liés à la pile technologique d'Intersystems.
Salut la communauté!
Souvent, lorsque nous développons des solutions commerciales, il est nécessaire de déployer des solutions sans code source, par exemple afin de préserver la propriété intellectuelle.
L'une des manières d'y parvenir est d'utiliser InterSystems Package Manager.
Ici, j'ai demandé à Midjourney de peindre la propriété intellectuelle d'un logiciel :
Illustration numérique de l'espace de travail d'un développeur de logiciels axé sur la protection de la propriété intellectuelle.
La scène montre un développeur de logiciels à son bureau, avec un écran d'ordinateur affichant un code complexe recouvert de verrous et de boucliers lumineux.
Sur le bureau se trouve un document de brevet avec un sceau et un ruban, symbolisant la protection d'innovations logicielles uniques.
A proximité, se trouvent des boîtes de produits logiciels avec des symboles de marque (™ ou ®) et des papiers avec des symboles de droit d'auteur (©), représentant la protection de l'identité de la marque et des œuvres originales.
Le cadre est moderne et bien éclairé, générant un sentiment de sécurité et d'innovation.Comment y parvenir avec IPM ?
En fait, c'est très simple ; ajoutez simplement la clause Deploy="true" dans l'élément Resource de votre manifeste module.xml. Documentation.
J'ai décidé de fournir l'exemple le plus simple possible pour illustrer son fonctionnement et également de vous donner un modèle d'environnement de développement pour vous permettre de commencer à créer et à déployer vos propres modules sans code source. On y va !
ZPM est un gestionnaire de packages conçu pour un déploiement pratique d'applications et de modules sur la plateforme IRIS.
Les développeurs de modules, pour que leur module soit installé à l'aide de ZPM, doivent suivre une série d'étapes simples.
La création manuelle d'un fichier module.xml peut être fastidieuse, donc la commande generate sera désormais créée dans zpm (à partir de la version 0.2.3).
La commande generate sert à créer module.xml pour votre projet.
Exécuter zpm dans le terminal Et puis entrer « generate »
USER>zpm
zpm: USER>generate /temp/zzz
En argument (dans ce cas /temp/zzz), spécifiez le chemin d'accès au répertoire contenant votre projet. Le fichier module.xml sera créé dans ce répertoire.
Répondre ensuite aux questions : zpm: USER>generate /temp/zzz
Enter module name: my-module
Enter module version: 1.0.0 => 1.0.1
Enter module description: module description
Enter module keywords: test,zpm,docker
Enter module source folder: src =>
Existing Web Applications:
/csp/user
/registry
Enter a comma separated list of web applications or * for all: /csp/user
Enter path to csp files for /csp/user: web
Dependencies:
Enter module:version or empty string to continue: sslclient:*
Enter module:version or empty string to continue:
zpm: USER>
Si vous devez ajouter des informations sur l'auteur et la licence à module.xml, utilisez le modificateur -author (-a).
zpm: USER>generate -author /temp/zzz
La commande generate prend également en charge une option différente : utilisez le modificateur -template (-t). Le module.xml est créé avec les données fictives, que vous devez modifier manuellement.
zpm: USER>generate -template /temp/zzz
Cette vidéo montre l'usage de generate.
Salut !
Récemment, j'ai eu besoin de configurer un serveur FHIR local à l'aide d'IRIS For Health et je pense avoir trouvé le moyen le plus simple et le plus simple qui soit.
Exécutez simplement dans le terminal ces deux lignes ci-dessous :
docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-communityet
docker exec -it my-iris iris session iris -U "USER" '##class(%ZPM.PackageManager).Shell("install fhir-server")'Et vous aurez un serveur FHIR exécuté localement sur http://localhost:9092/fhir/r4.
AUssi simple que ça !
Le serveur FHIR utilisera la dernière version d'InterSystems IRIS for Health Community Edition et déploiera FHIR server from this app via le package IPM dans l'espace de noms FHIRSERVER.
Ceci est pour Mac, alors veuillez ajouter des commentaires sur la façon dont cela fonctionne sous Windows.
Il s'agit d'un article très court car il est très simple de configurer un serveur FHIR local avec InterSystems IRIS for Health et IPM Package Manager.
InterSystems a le plaisir d'annoncer que le composant central d'InterSystems Supply Chain Orchestrator™, la version 2023.1 d'InterSystems IRIS for Supply Chain, est désormais généralement disponible (GA).
Ce Template s'agit du modèle de base pour utiliser InterSystems IRIS for Health Community Edition en tant que serveur FHIR.
Il configure un SERVEUR FHIR, importe les données de test, fait la démonstration de l'utilisation de l'API REST avec une simple page web.
Assurez-vous que vous avez installé git et Docker desktop.
Ouvrez l'installation d'IRIS for Health avec le client IPM installé. Appel dans n'importe quel espace de nom :
USER>zpm "install fhir-server"Ainsi, le serveur FHIR sera installé dans l'espace de noms FHIRSERVER.
Salut les développeurs ! Nous avons souvent besoin de déployer des données en même temps que des morceaux de code de l'application. Et pour les développeurs d'InterSystems IRIS, la question peut se poser comme suit : "Comment puis-je déployer les données que j'ai dans les globales ?"
Je vous propose ici l'une des approches suivantes : le déploiement de données globales à l'aide du gestionnaire de paquet ZPM package manager.
Dans un article précédent, j'ai abordé les modèles d'exécution des tests unitaires via le gestionnaire de paquets ObjectScript. Cet article va un peu plus loin, en utilisant les actions GitHub pour piloter l'exécution des tests et la création de rapports. Le cas d'utilisation qui nous motive est l'exécution du CI pour l'un de mes projets Open Exchange, AppS.REST (voir l'article d'introduction à ce projet ici). Vous pouvez voir l'implémentation complète dont les extraits de cet article ont été tirés sur GitHub ; elle pourrait facilement servir de modèle pour l'exécution de l'IC pour d'autres projets utilisant le gestionnaire de paquets ObjectScript.
Les fonctionnalités dont la mise en œuvre a été démontrée comprennent :
Il existe une documentation complète sur les actions GitHub ici. Dans le cadre de cet article, nous nous contenterons d'explorer les aspects présentés dans cet exemple.
Un flux de travail dans les actions GitHub est déclenché par un ensemble configurable d'événements et consiste en un certain nombre de tâches qui peuvent être exécutées séquentiellement ou en parallèle. Chaque tâche comporte un ensemble d'étapes - nous allons entrer dans le détail des étapes de notre exemple d'action plus tard. Ces étapes consistent en références à des actions disponibles sur GitHub, ou peuvent simplement être des commandes shell. Un extrait du modèle initial de notre exemple ressemble à ceci :
# Flux de travail d'intégration continue
name: CI
# Contrôle le moment où l'action sera exécutée. Déclenche le flux de travail sur les événements push ou pull request
# événements dans toutes les branches
on: [push, pull_request]
# Un flux de travail est composé d'une ou plusieurs tâches qui peuvent être exécutées séquentiellement ou en parallèle.
jobs:
# Ce flux de travail contient une seule tâche appelé "build".
build :
# Le type d'exécuteur sur lequel le travail sera exécuté
runs-on : ubuntu-latest
env:
# Variables d'environnement utilisables tout au long de la tâche de "compilation", par exemple dans les commandes au niveau du système d'exploitation.
package: apps.rest
container_image : intersystemsdc/iris-community:2019.4.0.383.0-zpm
# D'autres éléments seront abordés plus tard...
# Les étapes représentent une séquence de tâches qui seront exécutées dans le cadre du travail.
steps:
# Ceux-ci seront montrés plus tard...Dans cet exemple, un certain nombre de variables d'environnement sont utilisées. Pour appliquer cet exemple à d'autres paquets utilisant le gestionnaire de paquets ObjectScript, la plupart d'entre elles n'auront pas besoin d'être modifiées, alors que certaines le seront.
env:
# ** POUR UN USAGE GÉNÉRAL, IL FAUDRA PROBABLEMENT CHANGER : **
package: apps.rest
container_image: intersystemsdc/iris-community:2019.4.0.383.0-zpm
# ** POUR UN USAGE GÉNÉRAL, IL FAUDRA PEUT-ÊTRE CHANGER : **
build_flags: -dev -verbose # Télécharger en mode -dev pour obtenir le code de test unitaire préchargé
test_package: UnitTest
# ** POUR UN USAGE GÉNÉRAL, IL NE FAUDRA PAS CHANGER : **
instance: iris
# Remarque : la valeur test_reports est dupliquée dans la variable d'environnement test_flags.
test_reports: test-reports
test_flags: >-
-verbose -DUnitTest.ManagerClass=TestCoverage.Manager -DUnitTest.JUnitOutput=/test-reports/junit.xml
-DUnitTest.FailuresAreFatal=1 -DUnitTest.Manager=TestCoverage.Manager
-DUnitTest.UserParam.CoverageReportClass=TestCoverage.Report.Cobertura.ReportGenerator
-DUnitTest.UserParam.CoverageReportFile=/source/coverage.xmlSi vous voulez adapter cela à votre propre paquet, il suffit de déposer votre propre nom de paquet et votre image de conteneur préférée (doit inclure zpm - voir https://hub.docker.com/r/intersystemsdc/iris-community). Vous pourriez également vouloir changer le paquet de tests unitaires pour qu'il corresponde à la convention de votre propre paquet (si vous devez charger et compiler les tests unitaires avant de les exécuter pour gérer toutes les dépendances de chargement/compilation ; j'ai eu quelques problèmes bizarres spécifiques aux tests unitaires pour ce paquet, donc cela pourrait même ne pas être pertinent dans d'autres cas).
Le nom de l'instance et le répertoire test_reports ne devraient pas être modifiés pour d'autres utilisations, et les test_flags fournissent un bon ensemble de valeurs par défaut - ils permettent de faire en sorte que les échecs des tests unitaires signalent l'échec de la compilation, et gèrent également l'exportation des résultats des tests au format jUnit et un rapport de couverture de code.
Dans notre exemple de motivation, deux dépôts doivent être vérifiés - celui qui est testé, et aussi mon fork de Forgery (parce que les tests unitaires en ont besoin).
# Vérifie ce référentiel sous $GITHUB_WORKSPACE, afin que votre tâche puisse y accéder.
- uses: actions/checkout@v2
# Il faut aussi vérifier le timleavitt/forgery jusqu'à la version officielle installable via ZPM
- uses: actions/checkout@v2
with:
repository: timleavitt/forgery
path: forgery$GITHUB_WORKSPACE est une variable d'environnement très importante, représentant le répertoire racine où tout cela fonctionne. Du point de vue des permissions, vous pouvez faire à peu près tout ce que vous voulez dans ce répertoire ; ailleurs, vous pouvez rencontrer des problèmes.
Après avoir configuré un répertoire où nous finirons par placer nos rapports de résultats de tests, nous allons exécuter le conteneur InterSystems IRIS Community Edition (+ZPM) pour notre compilation.
- name: Run Container
run: |
# Créer le répertoire test_reports pour partager les résultats des tests avant l'exécution du conteneur.
mkdir $test_reports
chmod 777 $test_reports
# Lancer l'instance InterSystems IRIS
docker pull $container_image
docker run -d -h $instance --name $instance -v $GITHUB_WORKSPACE:/source -v $GITHUB_WORKSPACE/$test_reports:/$test_reports --init $container_image
echo halt > wait
# Attendez que l'instance soit prête
until docker exec --interactive $instance iris session $instance < wait; do sleep 1; doneIl y a deux volumes partagés avec le conteneur - l'espace de travail GitHub (pour que le code puisse être chargé ; nous y rapporterons également des informations sur la couverture des tests), et un répertoire séparé où nous placerons les résultats des tests jUnit.
Après la fin de "docker run", cela ne signifie pas que l'instance est complètement démarrée et prête à être commandée. Pour attendre que l'instance soit prête, nous continuerons à essayer d'exécuter une commande "halt" via la session iris ; cela échouera et continuera à essayer une fois par seconde jusqu'à ce que cela réussisse (éventuellement), indiquant que l'instance est prête.
Pour notre cas d'utilisation motivant, nous utiliserons deux autres bibliothèques pour les tests - TestCoverage et Forgery. TestCoverage peut être installé directement via le Community Package Manager ; Forgery (actuellement) doit être chargé via zpm "load" ; mais les deux approches sont valables.
- name: Install TestCoverage
run: |
echo "zpm \"install testcoverage\":1:1" > install-testcoverage
docker exec --interactive $instance iris session $instance -B < install-testcoverage
# Solution aux problèmes de permissions dans TestCoverage (création d'un répertoire pour l'exportation des sources)
chmod 777 $GITHUB_WORKSPACE
- name: Install Forgery
run: |
echo "zpm \"load /source/forgery\":1:1" > load-forgery
docker exec --interactive $instance iris session $instance -B < load-forgeryL'approche générale consiste à écrire les commandes dans un fichier, puis à les exécuter en session IRIS. Le ":1:1" supplémentaire dans les commandes ZPM indique que la commande doit quitter le processus avec un code d'erreur si une erreur se produit, et s'arrêter à la fin si aucune erreur ne se produit ; cela signifie que si une erreur se produit, elle sera signalée comme une étape de compilation ayant échoué, et nous n'avons pas besoin d'ajouter une commande "halt" à la fin de chaque fichier.
Enfin, nous pouvons effectivement compiler et exécuter des tests pour notre paquet. C'est assez simple - remarquez l'utilisation des variables d'environnement $build_flags/$test_flags que nous avons définies plus tôt.
# Exécute un ensemble de commandes en utilisant l'exécuteur runners
- name: Build and Test
run: |
# Exécution de compilation
echo "zpm \"load /source $build_flags\":1:1" > build
# Le paquet de test est compilé en premier comme solution de contournement pour certains problèmes de dépendance.
echo "do \$System.OBJ.CompilePackage(\"$test_package\",\"ckd\") " > test
# Exécution des tests
echo "zpm \"$package test -only $test_flags\":1:1" >> test
docker exec --interactive $instance iris session $instance -B < build && docker exec --interactive $instance iris session $instance -B < test && bash <(curl -s https://codecov.io/bash)Cela suit le même schéma que nous avons vu, écrire des commandes dans un fichier puis utiliser ce fichier comme entrée de la session iris.
La dernière partie de la dernière ligne télécharge les résultats de la couverture du code sur codecov.io. Super facile !
Supposons qu'un test unitaire échoue. Il serait vraiment ennuyeux de devoir revenir en arrière dans le journal de compilation pour trouver ce qui n'a pas fonctionné, bien que cela puisse toujours fournir un contexte utile. Pour nous faciliter la vie, nous pouvons télécharger nos résultats formatés par jUnit et même exécuter un programme tiers pour les transformer en un joli rapport HTML.
# Générer et télécharger le rapport HTML xUnit
- name: XUnit Viewer
id: xunit-viewer
uses: AutoModality/action-xunit-viewer@v1
if: always()
with:
# Avec -DUnitTest.FailuresAreFatal=1, un test unitaire qui échoue fera échouer la compilation avant ce point.
# Cette action pourrait autrement mal interpréter notre sortie de style xUnit et faire échouer la compilation même si
# tous les tests sont passés.
fail: false
- name: Atacher le rapport
uses: actions/upload-artifact@v1
if: always()
with:
name: ${{ steps.xunit-viewer.outputs.report-name }}
path: ${{ steps.xunit-viewer.outputs.report-dir }}Ces informations sont principalement tirées du fichier readme à l'adresse https://github.com/AutoModality/action-xunit-viewer.
Si vous voulez voir les résultats de ce flux de travail, regardez :
Les journaux pour le job CI sur intersystems/apps-rest (y compris les artefacts de compilation) : https://github.com/intersystems/apps-rest/actions?query=workflow%3ACI
Rapports de couverture de test : https://codecov.io/gh/intersystems/apps-rest
N'hésitez pas à me faire savoir si vous avez des questions !
Salut les développeurs !
Voici encore un court message qui a pour but de simplifier la vie des développeurs. Nous allons maintenant vous expliquer comment faire en sorte que GitHub exécute des tests unitaires à chaque poussée vers le référentiel en ajoutant un seul fichier au référentiel. Gratuitement. Dans le nuage de Github. Ça a l'air génial, n'est-ce pas ?
C'est possible et très facile à faire. Le mérite revient à @Dmitry Maslennikov (et son référentiel), gestionnaire de paquets "ZPM Package Manager", et aux GitHub Actions. Voyons comment tout cela fonctionne !
Considérons d'abord un référentiel avec des tests, par exemple le modèle IRIS de base.
Supposons également que vous chargez votre code de développement dans le docker IRIS à l'aide de ZPM. Si ce n'est pas le cas, regardez la video sur la façon de le faire.
Dans ce référentiel particulier, il s'agit de la ligne suivante et avec la présence de module.xml:
zpm "load /home/irisowner/irisbuild/ -v":1:1
Ensuite, ajoutons un scénario de GitHub Actions qui permettra de construire l'image et d'exécuter les tests :
name: unittest
on:
push:
branches:
- maître
- principale
pull_request:
branches:
- maître
- principale
version:
types:
- libéré
tâches:
build:
runs-on: ubuntu-latest
étapes:
- utilisations: actions/checkout@v2
- nom: Build and Test
utilisations: docker/build-push-action@v2
avec:
contexte: .
push: faux
charge: vrai
balises: ${{ github.repository }}:${{ github.sha }}
build-args: TESTS=1Ce scénario construit une image docker en utilisant Dockerfile du référentiel à chaque push ou pull-request vers la branche master ou main.
Voici une ligne supplémentaire qui transfère la variable TESTS=1 au Dockerfile :
build-args: TESTS=1
Cet argument est évaué dans le Dockerfile et si TESTS=1, il exécute les tests du paquet zpm du référentiel :
([ $TESTS -eq 0 ] || iris session iris -U $NAMESPACE "##class(%ZPM.PackageManager).Shell("test $MODULE -v -only",1,1)") && \
Cette ligne vérifie le paramètre $TESTS et s'il n'est pas égal à 0, elle ouvre la session iris dans $NAMESPACE (IRISAPP dans ce cas) et exécute la commande ZPM :
test $MODULE -v -only
L'indicateur -only exécute uniquement le test sans charger le module (car il a été chargé auparavant dans le scénario de construction de docker).
Le nom du module est défini via $MODULE="dc-sample-template" dans ce cas :
ARG MODULE="dc-sample-template"
La commande va exécuter tous les unittests que nous avons mentionnés dans le module ZPM. Dans ce cas, nous le présentons avec cette ligne:
<UnitTest Name="/tests" Package="dc.sample.unittests" Phase="test"/>
ce qui signifie que les tests unitaires sont situés dans le dossier /tests du référentiel et que la ressource est dc.sample.unittests paquet de classe qui a deux classes.
Ce scénario va construire l'image de votre dépôt sur le nuage GitHub et exécuter des tests pour chaque push ou pull request vers la branche maître !
Voyons comment cela fonctionne !
La méthode Test42 prévoit que la méthode dc.sample.ObjectScript).Test() renvoie 42.
Changeons la ligne en 43 et envoyons pull-request. Nous pouvons voir (dans la section Actions ) que la pull-request a initié l'action Github. En effet, la construction a échoué :
Et les détails de la phase indiquent que Test42() a échoué sur AssertEquals 42 =43 :
Github envoie également des notifications par courriel en cas d'échec des constructions CI.
Remarque : pour exécuter les tests localement, il suffit d'appeler :
USER>zpm test "module-name"
Et si nous remettons la valeur de la variable à 42, les tests seront OK !
Et s'il s'agit de Pull-Request, vous pouvez voir le résultat de l'IC dans la section spéciale de contrôle Checks:
Et voilà !
Pour résumer, faire fonctionner GitHub (gratuitement !) pour les constructions de dockers et les unittests des projets InterSystems IRIS sur les pushes ou les pull-requests nécessite un scénario CI Github Actions scenario, qui sera le même pour chaque projet, et trois lignes dans le Dockerfile :
Le nom ZPM $MODULE - ceci doit être mis à jour avec chaque projet,
Et utilisez le gestionnaire ZPM Package Manager!
Les commentaires et les réactions sont les bienvenus, et bon codage !
L'image du titre est liée à l'histoire de l'un de mes auteurs de SF préférés, Robert Sheckley, ["Quelque chose pour rien"] (https://en.wikipedia.org/wiki/Something_for_Nothing_(book)) - la voici en [audio aussi] (https://www.youtube.com/watch?v=CL0GQTtx-5A), profitez-en !
Nous venons de publier une mise à jour mineure du gestionnaire de packages, qui a été renommé de ZPM à IPM, comme je l'expliquais en novembre. Il s'agit simplement d'une version de correction de bogue, interprétant correctement les codes de retour ROBOCOPY et corrigeant une régression qui empêchait l'installation de certains packages.
Obtenez-le ici :
Bonjour les développeurs!
Souvent, lorsque nous développons une bibliothèque, un outil, un package, quel qu’il soit dans InterSystems ObjectScript, nous avons une question, comment pouvons-nous déployer ce package sur la machine cible ?
De plus, nous attendons souvent d’autres bibliothèques déjà installées, donc notre paquet dépend d’elles, et souvent d’une version spécifique de celui-ci.
Lors de l’encodage javascript, python, etc., le rôle de l’implémentation de packages de gestion des dépendances nécessite un gestionnaire depaquets.
C’est pourquoi j’ai le plaisir de vous annoncer que InterSystems ObjectScript Package Manager est disponible !
Je suis heureux d'annoncer une étape importante dans le cycle de vie du gestionnaire de packages ObjectScript, ZPM. Le gestionnaire de packages offre aux développeurs la possibilité de regrouper soigneusement le code ObjectScript, les paramètres de configuration du déploiement et les informations de version de manière pratique. Au cours des dernières années, il a considérablement évolué pour devenir une partie intégrante de nombreux workflows de développement.
Salut la communauté !
@Joan Pérez a publié une critique selon laquelle il n'est pas très clair quelles applications sont disponibles pour InterSystems Package Manager. Merci Joan ! En effet, cela mérite un article.
Il y a au moins deux façons que je connais pour les présenter :
1. Exécuter la commande find dans zpm :
InterSystems et la communauté des développeurs autour de ZPM ont travaillé ensemble pour faire passer ZPM au niveau supérieur, en l'intégrant à IRIS et en en faisant un outil capable non seulement de gérer du code tiers, mais également des éléments clés des produits InterSystems. Vous pouvez en entendre beaucoup plus sur ce sujet lors du Global Summit 2022, et assister à un laboratoire d'expérience pour vous familiariser.