Scénarios Jeedom : comment revenir en arrière après une modification?

Bonjour à tous,

je me lance sur un sujet qui, je pense, touche pas mal d’entre nous, surtout quand on a régulièrement à mettre les mains dans le cambouis des scénarios avec pas mal de code PHP. Vous faites comment pour gérer les changements dans vos scénarios au fil du temps ? J’ai cherché, je n’ai rien trouvé d’autre que le recours à la duplication.

On a tous eu ce moment, non ? On tente un truc, on change d’avis, ou pire, on fait une boulette et on se retrouve à supprimer une partie importante de notre code par accident. Et là, c’est le drame… À moins de penser à dupliquer le scénario avant de le modifier, on est bon pour restaurer un backup complet…, s’il esst encore temps. On peut dire adieu à notre travail si on a pas prévu le coup

Si je ne m’abuse, il n’y a pas de fonction de versioning pour les scénarios dans Jeedom. Pas de « undo » magique, pas de moyen facile de voir les changements précédents. C’est un peu comme marcher sur un fil sans filet, non ?

Je me demandais donc, ça ne serait pas génial si on avait une sorte de gestion des versions pour nos scénarios ? Un truc pour pouvoir revenir en arrière, comparer les versions, voir ce qu’on a modifié sans avoir à sortir les grands moyens avec un backup. Je suis sûr que je ne suis pas le seul à penser que ça pourrait nous éviter pas mal de sueurs froides et encourager encore plus d’expérimentations et d’innovations.

Vous en pensez quoi ? C’est quelque chose qui pourrait intéresser d’autres par ici ? Pas forcément l’équivalent d’un github. Une duplication en arrière-plan pourrait déjà être très utile. Peut-être qu’en en parlant, on pourrait voir si c’est jouable et si ça vaudrait le coup de pousser l’idée auprès des devs de Jeedom.

Salut,

Ce n’est pas plus simple d’utiliser des blocs Commentaire ou d’exporter le scénario avant de le modifier ?

De mon coté, si je sais que je vais faire de grosses modifs su run scenario, :
1 - soit je duplique le scenario (et je travaille sur le scenario dupliqué. En cas de pb, il suffit d’activer/desactiver le scenario dupliqué ou original, mais difficile de garder X versions
2 - soit j’enregistre un Template du scenario en le nommant scenario _XXX_22032024… En cas de pb, je restaure le template. Très simple, très rapide, et on peut garder X versions d’un scenario

Norbert

1 « J'aime »

La duplication n’est pas une solution. Déjà il faut penser à dupliquer le scenario. Ce qu’on peut oublier de faire (ok, c’est une faute, mais ça arrive plus souvent qu’à son tour). Ensuite, quand le scenario est géré par plusieurs personnes, pouvoir consulter l’historique pour comprendre les évolutions du code, peut être utile.

Après, je suis d’accord que c’est une fonctionnalité plutôt orienté entreprise ou gros scenarios en PHP plutôt qu’en blocs code, et ça vise plus le long terme que le court terme. Pour autant, c’est une option que j’adorerai avoir. Ça m’éviterait de gérer le code PHP des scenarios dans un dépôt à l’extérieur. Ce qui est tout sauf pratique, surtout si je disparais. J’ai beau mettre des commentaires partout, avoir les modifications sur la durée reste utile (comment ferait-on sans CVS, Subversion ou GitHtub :fearful:)

Tu ne te rends clairement pas compte du travail colossal que ça représente ni de l’impact sur les performances générales pour un besoin somme toute très limité et facilement palliable de pleins de manières différentes avec les outils existants.

1 « J'aime »

Du coup, je ne comprends pas, c’est pour toi ou pour une grosse boîte avec plusieurs personnes qui dev sur Jeedom ?

On a tous eu ce moment, non ? On tente un truc, on change d’avis, ou pire, on fait une boulette et on se retrouve à supprimer une partie importante de notre code par accident

J’ose espérer que dans le second cas, tout ça est fait dans un environnement de test ou pré-production.

Dans l’absolu, c’est intéressant mais il y a sans doute d’autres évolutions prioritaires

Norbert

Je me rends très bien compte. Ça fait bien plus de 30 ans que je bosse dans l’industrie du logiciel. Il n’y a apparemment pas de besoin, pas de problème. On fera autrement :slight_smile:

Bonsoir
Perso :
Dans la case commentaire (première page du scénario) je note les dates en commençant par la plus recente et une explication à chaque modif, même en qque mots

  • 01/03/2024 : explication modifs
  • 15/02/2024 : etc
    Apres 2 solutions :
  • j’exporte le scénario et le modifie
  • je le duplique, je range la duplication dans le groupe « Versions » et son nom devient
    Son ancien groupe - son nom - la date
    (en mode 2024-03-32 pour qu’ils se rangent automatiquement dans l’ordre : Groupe / scenario / version dans le temps)
    Je désactive le scénario
    J’enregistre.
    Et je retourne dans celui de base.
    Avec l’habitude, ça prends 30 secondes.

Avec la seconde méthode, tu peux garder des centaines de scénarios / versions, facilement accessibles, pour quelques ko de memoire…
Pour voir toute tes versions, il suffit de tapper son nom dans la recherche, et comme par magi les versions apparaissent dans l’ordre des dates…

La première est plus lourde (surtout à l’importation) mais ne laisse pas de traces sur la machine.

1 « J'aime »

Hello,
J’avais plus en tête la résolution de cette demande en passant par un outil tierce comme mentionné par @Salvialf .

scénario avant de le modifier, on est bon pour restaurer un backup complet…

Oui mais non :slight_smile:

comment ferait-on sans CVS, Subversion ou GitHtub

On utiliserais « Restic »
Je cherchais justement une solution dans cette veine après une boulette faite dans l’IHM un soir (de « nuit » et de brouillard), un clic malheureux, …
Restic fait de la déduplication du coup pas besoin de sauvegarde complète surtout si base conséquente …
De même au niveau des environnements pas besoin d’intégration, recette, préproduction, secours et Cie

Et ce qui me plait aussi dans l’outil c’est la gestion de TAG
Par exemple dans ce cas le TAG idéal serait : scenario

Personnellement je suis en cours d’installation, le repo sera sur un NAS Syno 110J (last gen :stuck_out_tongue: ) monter en NFS.

En espérant que la solution pourrait convenir ? @pommedapi

1 « J'aime »

J’avais comme idée de base de faire quelque chose comme une capture des différences en cas de modification du champ expression de la table scenarioExpression et de balancer les diff dans un système de contrôle de version tournant en local. Mais comme tu n’es pas le premier à me vanter Restic, je vais aller l’examiner de plus prêt.

1 « J'aime »

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.