Après presque quatre ans de pause, ma série CI/CD est de retour ! Au fil des ans, j'ai travaillé avec plusieurs clients d'InterSystems, développant des pipelines CI/CD pour différents cas d'utilisation. J'espère que les informations présentées dans cet article seront utiles à quelqu'un.

Cette série d'articles aborde plusieurs approches possibles du développement logiciel avec les technologies InterSystems et GitLab.

Nous avons une gamme passionnante de sujets à couvrir: aujourd'hui, parlons de choses au - delà du code, à savoir les configurations et les données.

Problème

Nous avons déjà abordé la question des promotions de code, qui était, d'une certaine manière, sans état - nous passons toujours d'une instance (présumée) vide à une base de code complète. Mais parfois, nous devons fournir des données ou un état. Il existe différents types de données:

• Configuration: utilisateurs, applications Web, LUT, schémas personnalisés, tâches, partenaires commerciaux et bien d'autres
• Paramètres: paires clé-valeur spécifiques à l'environnement
• Données : des tableaux de référence etc. doivent souvent être fournis pour que votre application fonctionne.

Discutons de tous ces types de données et de la manière dont ils peuvent d'abord être validés dans le contrôle de code source, et ensuite déployés.

Configuration

La configuration de système est répartie dans de nombreuses classes différentes, mais InterSystems IRIS peut exporter la plupart d'entre elles en XML. Tout d'abord, il s'agit d'un paquet de sécurité qui contient des informations sur :

• Les Applications Web
• DocDBs
• Les domaines
• Les événements d'audit
• Les serveurs KMIPServers
• Les configurations LDAP
• Les ressources
• Les rôles
• Les privilèges SQL
• Les configurations SSL
• Les services
• Les utilisateurs

Toutes ces classes sont dotées de méthodes Exists, Export et Import, qui vous permettent de les déplacer d'un environnement à l'autre.

Quelques avertissements :

• Les utilisateurs et les configurations SSL peuvent contenir des informations sensibles, telles que des mots de passe. Il N'est généralement PAS recommandé de les stocker dans le contrôle du code source pour des raisons de sécurité. Utilisez des méthodes d'exportation/importation pour faciliter les transferts ponctuels.
• Par défaut, les méthodes d'exportation et d'importation produisent tout dans un seul fichier, ce qui n'est pas forcément compatible avec le contrôle du code source. Voici une classe utilitaire qui permet d'exporter et d'importer des tableaux de consultation (LUT), des schémas personnalisés, des partenaires commerciaux, des tâches, des informations d'identification et une configuration SSL. Il exporte un élément par fichier, de sorte que vous obtenez un répertoire avec LUT, un autre répertoire avec des schémas personnalisés, et ainsi de suite. Pour les configurations SSL, il exporte également des fichiers : certificats et clés.

Il convient également de noter qu'au lieu d'exporter/importer, vous pouvez utiliser %Installer ou Merge CPF pour créer la plupart de ces éléments. Ces deux outils prennent également en charge la création d'espaces de noms et de bases de données. Merge CPF peut ajuster les paramètres du système, tels que la taille du tampon global.

Tâches

La classe %SYS.Task stocke les tâches et fournit les méthodes ExportTasks et ImportTasks. Vous pouvez également consulter la classe utilitaire ci-dessus pour importer et exporter des tâches individuellement. Notez que lorsque vous importez des tâches, vous pouvez obtenir des erreurs d'importation (ERROR #7432 : La date et l'heure de début doivent être postérieures à la date et à l'heure actuelles) si StartDate ou d'autres propriétés liées à la planification sont dans le passé. Comme solution, réglez LastSchedule à 0, et InterSystems IRIS replanifiera une tâche nouvellement importée pour qu'elle s'exécute dans le futur le plus proche.

Interopérabilité

Les productions d'interopérabilité contiennent le suivant :

• Les partenaires commerciaux
• Les paramètres par défaut du système
• Les références
• Les tableaux de consultation (LUT)

Les deux premiers sont disponibles dans le paquet Ens.Config avec les méthodes %Export et %Import. Exportez les références et les tableaux de consultation à l'aide de la classe utilitaire ci-dessus. Dans les versions récentes, les tableaux de consultation peuvent être exportés/importés via la classe $system.OBJ.

Paramètres

Paramètres par défaut du système est un mécanisme d'interopérabilité par défaut pour les paramètres spécifiques à l'environnement :

L'objectif des paramètres par défaut du système est de simplifier le processus de copiage d'une définition de production d'un environnement à l'autre. Dans toute production, les valeurs de certains paramètres sont déterminées dans le cadre de la conception de la production ; ces paramètres doivent généralement être identiques dans tous les environnements. D'autres paramètres, en revanche, doivent être adaptés à l'environnement ; il s'agit notamment des chemins d'accès aux fichiers, des numéros de port, etc.

Les paramètres par défaut du système ne doivent spécifier que les valeurs spécifiques à l'environnement dans lequel InterSystems IRIS est installé. En revanche, la définition de la production doit spécifier les valeurs des paramètres qui doivent être identiques dans tous les environnements.

Je recommande fortement de les utiliser dans des environnements de production. Utilisez %Export et %Import pour transférer les paramètres par défaut du système.

Paramètres de l'application

Votre application doit également utiliser des paramètres. Dans ce cas, je vous recommande d'utiliser les paramètres par défaut du système. Bien qu'il s'agisse d'un mécanisme d'interopérabilité, il est possible d'accéder aux paramètres via : %GetSetting(pProductionName, pItemName, pHostClassName, pTargetType, pSettingName, Output pValue) (docs). Vous pouvez écrire un wrapper qui définira les valeurs par défaut dont vous ne vous souciez pas, par exemple :

ClassMethod GetSetting(name, Output value) As %Boolean [Codemode=expression]
{
##class(Ens.Config.DefaultSettings).%GetSetting("myAppName", "default", "default", , name, .value)
}

Si vous voulez plus de catégories, vous pouvez aussi exposer les arguments pItemName et/ou pHostClassName. Les paramètres peuvent être initialement définis par importation, en utilisant le portail de gestion du système, en créant des objets de la classe Ens.Config.DefaultSettings, ou en définissant une globale ^Ens.Config.DefaultSettingsD.

Mon premier conseil est de conserver les paramètres en un seul endroit (il peut s'agir des paramètres par défaut du système ou d'une solution personnalisée), et l'application doit obtenir les paramètres uniquement à l'aide d'une API fournie. De cette façon, l'application elle-même ne connaît pas l'environnement et il ne reste plus qu'à fournir un stockage centralisé des paramètres avec des valeurs spécifiques à l'environnement. Pour ce faire, créez un dossier de paramètres dans votre référentiel contenant des fichiers de paramètres, avec des noms de fichiers identiques aux noms des branches de l'environnement. Ensuite, pendant la phase CI/CD, utilisez la variable d'environnement $CI_COMMIT_BRANCH pour charger le fichier approprié.

DEV.xml
TEST.xml
PROD.xml

Si vous avez plusieurs fichiers de configuration par environnement, utilisez des dossiers nommés d'après les branches de l'environnement. Pour obtenir la valeur d'une variable d'environnement à l'intérieur d'InterSystems IRIS utilisez $System.Util.GetEnviron("name").

Données

Si vous souhaitez mettre à disposition certaines données ( tableaux de référence, catalogues, etc.), vous disposez de plusieurs moyens pour le faire :

• Exportation globale. Utilisez soit un fichier binaire GOF export, soit un nouvel fichier XML. Avec le fichier GOF export, rappelez-vous que les locales sur les systèmes source et cible doivent correspondre (ou au moins la collation globale doit être disponible sur le système cible). Le fichier XML export prend plus de place. Vous pouvez l'améliorer en exportant les globales dans un fichier xml.gz, les méthodes $system.OBJ (dés)archivent automatiquement les fichiers xml.gz selon les besoins. Le principal inconvénient de cette approche est que les données ne sont pas lisibles par l'homme, même XML - la plupart d'entre elles sont encodées en base64.
• Format CSV. Export CSV et l'importer avec LOAD DATA. Je préfère CSV car c'est le format lisible par l'homme le plus efficace en termes de stockage, et que tout le monde peut importer.
• Format JSON. Créez la classe JSON Enabled.
• Format XML. Créez la classe XML Enabled pour projeter des objets en XML. Utilisez-la si vos données ont une structure complexe.

Le choix du format dépend de votre cas d'utilisation. Ici, j'ai classé les formats par ordre d'efficacité de stockage, mais ce n'est pas un souci si vous n'avez pas beaucoup de données.

Conclusions

L'état ajoute une complexité supplémentaire à vos pipelines de déploiement CI/CD, mais InterSystems IRIS fournit une vaste gamme d'outils pour le gérer.

Liens

• Utility Class
• %Installer
• Merge CPF
• $System.OBJ
• Paramètres par défaut du système