Bonjour à tous,
Je m’adresse à vous, la communauté technique francophone pour vous présenter une réflexion et une proposition de réponse que j’ai apporté pour utiliser docker dans un environnement de développement avec plusieurs développeurs.
Ma réponse se compose en 2 parties, une architecture du repository GIT d’un namespace et un repository lié à DOCKER. La première partie, je pense, peut être utile au-delà d’un contexte docker.
La complexité de ce projet réside dans le fait d’avoir une solution permettant de conteneuriser un nombre “infini” de namespace et éviter d’avoir un conteneur par namespace.
Présentation du framework
Dans chacun de mes projets, je crée un dossier à la racine nommé Config.
Dans ce dossier va se trouver toute la configuration du namespace avec les fichiers suivants
- Les WebApps
- Les default Settings
- Le deployer
- L’installer
- Les packages (ce fichier sert à dire au plugin docker GIT quels packages il doit exporter dans le repository. L’intérêt est de ne pas polluer le repo avec toutes les classes du namespaces, mais bien seulement celles que je crée.)
Attention, il est extrêmement important de respecter le nommage de chaque fichier avec le nom du namespace et le reste du nom du fichier. Je me sert de cette convention pour détecter automatiquement les namespaces.
Les intérêts sont les suivants
1- Dans mon dossier DOCKER, je n’ai AUCUN fichier de config (à part celui permettant l’affichage dans VSCODE)
Pour chaque namespace présent dans mon workspace respectant le framework, il sera automatiquement déployé lors des commandes docker
2- Chaque namespace peut posséder son propre GIT qui est totalement omnipotent puisqu’il possède également la configuration. Cela permet de résoudre les soucis de gestion des différentes configurations. Dans un contexte multi-développeur sur un même namespace, cela permet d’ajouter automatiquement les nouveaux default settings présent dans la version déployée par exemple.
3- Le repo GIt de chaque namespace n’est pas “pollué” avec de la config docker, il peut très bien être utilisé dans un monde non conteneurisé, toute la complexité de la conteneurisation est portée par le repo DOCKER
Je ne rentre pas pour le moment dans le détail de la solution. Elle n’est pas spécialement complexe mais elle est très fournie. Je peux vous donner les différentes choses à regarder si cela vous intéresse
- La classe File.CLS qui me permet de faire toutes les actions requises
- Les deux scripts (Install et Deploy) qui orchestrent les appels à la classe File pour l’installation.
- Le Readme qui explique techniquement comment démarrer le projet.
- A noter que j’utilise un fork personnel du projet MW-de/git-for-iris qui ne gère la les arborescences et le contexte multi namespace (En tout cas à l’époque où j’ai mené ce projet). Toute la complexité de GIt est porté part ce projet. La façon donc les fichiers locaux sont compilés dans la BDD IRIS où comment une modification dans la BDD IRIS (Ajout d’un composant en production) est automatiquement exporté dans un fichier local pour être “commitable”.
Si ce projet vous intéresse, je pourrai aller plus dans le détail de l’explication et/ou faire une vidéo où je présente l’exhaustivité des étapes de conception.
Je vous invite à “jouer” avec mon repo Git prévu à cet effet. Dans ce contexte, j’ai tout réuni au sein d’un même repo pour simplifier le test, mais dans le monde réel, j’ai bien un répo par namespace + un DOCKER. Il n’y a plus qu’à suivre le readme 🙂
https://github.com/ArchiMatt/Framework-docker
C’est un projet que j’ai mené il y a très longtemps pour résoudre nos problématiques projets. Je n’ai plus la chance de travailler sur les technologies InterSystems régulièrement mais je tenais à vous partager ce bout de réflexion. N’hésitez pas à réagir, c’est un projet qui n’est pas terminé, il y a encore plein de choses à améliorer / nettoyer. Peut être que les dernières version d’IRIS sont venues faire évoluer cette vision 🙂
