Bonjour,
Nous avons besoin d’automatiser le process de déploiement des configurations/ imports XMLs d’un environnement à un autre, avec des scripts d’appel CLI. Avez vous une documentation à nous conseiller pour ce besoin ?
Cordialement.
Pour les déploiements de paramétrage (modules) vous pouvez aussi mettre en place des mécanismes à base de Git (pour mémoire un module Simplicité peut s’exporter comme un repository Git).
Exemple basique:
- clonez ce repository Git depuis votre instance de dev (cette instance sera votre remote “origin”)
- ajoutez les URLs des instances de test/recette et/ou prod l’import comme remotes supplémentaires
- le déploiement se fait alors depuis ce repository en faisant:
a)git pullpour exporter la dernière version commitée de votre module depuis l’instance de dev
b)git push <remote name = test or prod or ...>pour importer cette version vers vos instances de test, prod, …
Dans tous les cas (que ça soir par Git ou par des appels curl sur I/O) il est impératif de regarder attentivement les logs de l’instance cible pendant l’import car toute éventuelle erreur de paramétrage (ex: dépendance croisée entre modules) peut conduire à des erreurs qui feront que vos modules ne seront que partiellement importés.
PS: si vous procédez par export imports par appels curl sur I/O utilisez de préférence le format ZIP plutôt que XML, surtout si vos données comportent des attributs fichiers
Oui actuellement j’ai déjà développé une pipeline qui est prêt sur gitlab, nous allons partir sur cette solution.
Je vous remercie pour vos retours.
Cordialement.
Kahina Ferroukhi
Bonjour,
Dans la documentation simplicite il y a cet URL pour I/O: http[s]://<host[:port]>[/]/api/io
J’ai fait un test en localhost par quoi peut-on remplacer le approot ? pourriez-vous me donner un exemple ?
en localhost : http://localhost:8080/api/io ?
Merci
Vous devez taper par défaut directement sur /io
Dans la doc il est dit "As of version 4.0.P22 it can also be one available on the API endpoint http[s]://<host[:port]>[/<app root>]/api/io" => tout est dans le “also” cette remarque ne concerne que les gens qui pour une raison ou une autre on bloqué l’accès au /io…
Pour ce qui est de [/<app root>] => sur un déploiement “par défaut” c’est déployé à la racine dont sans le /<app root> c’est le sens des crochets dans la syntaxe BNF utilisée ici = optionel = à mettre uniquement si vous êtes dans ce cas là
Exemples: si votre webapp Simplicité est déployée sur une URL du genre https://myhost.mydomain alors l’URL de I/O sera https://myhost.mydomain/io, si elle est déployée sur http://myhost.mydomain:1234/myapp alors ce sera http://myhost.mydomain:1234/myapp/io etc.
Dans nos docs on est obligé d’utiliser des syntaxes “à géométrie varaible” (d’où la syntaxe BNF) car seul le client sait sur quelle(s) URLs ils déploie
Par contre je ne comprend pas bien pourquoi on parle de /io alors qu’il me semblait avoir compris de nos échanges précécent que vous alliez utiliser des déploiements de paramétrage basés sur Git…
1 Like
Bonjour,
Oui, les déploiement sous git sont utiles, sauf que nous avons un process de déploiement qui un peu compliqué pour le moment. Nous avons 2 environnements de test en DEV…
Pour le moment j’ai déjà initié un pipeline sur gitlab, c’est pour cela que je cherche à comprendre /io.
Je n’ai pas regardé en détail la solution de déploiement git, c’est possible qu’on l’utilise.
Merci.
OK donc pour déployer des modules de paramétrage sur /io vous devez impérativement utiliser le service moduleimport décrit dans la doc.
Les autres services d’import simple xmlimport/zipimport/... c’est pour les données métier uniquement.
La différence c’est que pour le service d’import de module il y a un mécanisme de diff final qui retire les paramétrage devenus inutiles. Les services d’import simple ne font pas ce diff, il ne font que de l’“upsert” (insert or update). Bref, si vous importez un module via un service d’import simple vous n’aurez sans doute pas le résultat attendu.