You are not logged in.
Pages: 1
Topic closed
Bonjour,
Je travaille en local dans GLPI et je développe N fonctionnalités pour mon entreprise. Ces N fonctionnalités sont OK et intégrables en production. Le projet est livrable, il suffit d'exporter en SQL la BDD locale et l'intégrer à la BDD en production. Bien, mais je suis tout de même confronté à un problème dont je ne vois pas quelle serait la meilleure solution...
Supposons que je développe une nouvelle fonctionnalité en local, elle fonctionne, je veux l'intégrer en production. Comment faire pour intégrer ma fonctionnalité en production sans modifier/écraser quoi que ce soit à ce qui a été fait en production du moment où j'ai envoyé mon SQL avec N fonctionnalités jusqu'à cette nouvelle intégration ?
Quelques idées me sont venues mais non viables, comme celle d'exporter en SQL la BDD en production pour l'intégrer en local, ajouter ma nouvelle fonctionnalité en local, et réexporter en SQL la BDD en local pour l'intégrer en production. On m'a bien dit que tout ce qui est en production reste en production (ce qui paraît cohérent).
J'ai pensé à un script permettant de différencier le SQL local et le SQL en production pour permettre uniquement l'intégration de nouvelles données sans toucher aux données existantes. Pour être plus clair, lors de l'exportation en SQL de la BDD en local pour l'intégrer en production, plutôt que d'avoir un SQL contenant des DROP, UPDATE, etc... n'avoir que des requêtes type ajout de données.
Est-ce une bonne idée ou il existe une solution plus simple ?
Offline
C'est pour ca qu'il faut faire des plugins, c'est plus simple
Offline
Il n'en existe pas un pour ce type de problème ?
Offline
si vous avez creé des fonctionalités, elles ne modifient normalement pas les tables existantes mais ajoutent des tables liées.
les classes associées sont séparées.
vous pouvez donc exporter vos nouvelles tables dans la base de prod sans toucher au coeur de glpi et déposer vos fichiers php sur votre serveur sans ecraser ce qui existe.
par contre si vous touchez aux tables natives de GLPI, vous vous exposez à des ennuis lors de la prochaine migration.
Trouver la panne avant de réparer...
GLPI10.0.10 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.2 reports 1.16.0 formcreator 2.13.8, datainjection 2.13.4 fields 1.21.6
Offline
D'après son message, il a fait le bourrin sur les tables GLPI...
Offline
Je ne touche pas au coeur de GLPI, je me suis peut-être mal exprimé mais je parlais uniquement en termes de données. Je vais donner un exemple ce sera plus simple à comprendre...
GLPI est dans un état E1 à l'instant T, je sauvegarde la BDD en local. Je l'envoie en production.
GLPI est utilisé en production à partir cette base E1, supposons que 2 tickets sont créés.
Maintenant je veux ajouter une nouvelle fonctionnalité, que je développe en local bien entendu.
Je vais alors repartir de la base E1, ajouter la fonctionnalité et avoir un état E2 à l'instant T+1.
Je sauvegarde la nouvelle BDD en local et l'envoie en production.
Le problème c'est qu'une fois en production, les 2 tickets créés en production entre temps n'existent plus dans la BDD, toute la BDD en production est recréée à partir cet état E2...
__________________________________________________
LaDenrée : je n'ai pas touché aux tables natives de GLPI, dans mon exemple en l'occurrence c'est 2 INSERT INTO à la table glpi_tickets, rien de plus...
Offline
Bah tu peux pas, ta base de prod est la reference, donc si tu as des choses a ajouter dessus que t'as ajouté sur ta base de test, tu dois les ajouter sur la prod
Offline
La restauration n'est pas un complément mais une substitution.
Donc tout ce qui a été fait en production sera écrasé par la restauration de votre sauvegarde fait en test
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Merci pour vous réponses, au moins je suis fixé !
Offline
Pages: 1
Topic closed