Déploiement de nouvelle version plus rapidement

Bonjour à tous,

Je voulais voir avec vous et ce que vous en pensez pour améliorer un point qui pour moi est pas optimal.

Si je me trompe pas, dans le processus actuel, lorsque l’on apporte une modification au code, on doit tout rebuild (logique) et déployer une nouvelle version. Il se trouve que actuellement @pierre-gilles valide les fonctionnalités et surtout il pousse une nouvelle version avec pleins de fonctionnalités en plus.

Il serait intéressant de pouvoir pousser des choses beaucoup plus rapidement. Par exemple un ajout de device sur une lib (genre zigbee2mqtt). Il se trouve que si quelqu’un a un device pas pris en charge, on passe par tout ce processus qui est lourd à mon sens (pour ce genre d’usage).

On pourrait imaginer quelque chose de plus simple pour déployer rapidement les nouveaux devices. Par exemple un fichier qu’on récupère depuis un repo par exemple et qui est pull par les instances de gladys. Ca permet d’avoir des petites rajouts sans nécessairement passer par une attente “inutile” surtout quand on doit rajouter un id dans un json :smiley:

Bien sur cette logique pourrait être utilisé sur ailleurs c’est plus un pattern qui peut être intéressant. On reste dans un cadre controlé (tout est automatique avec controle sur les PR etc) mais au moins on différencie le déploiement de grosses mise à jour et les petits ajouts.

Qu’en pensez vous ?

Salut @damalgos !

J’avais pas vu ton message, je rebondis maintenant :slight_smile:

Je te dis mon avis là dessus, dans l’idée ça pourrait sembler sympa, mais en pratique je pense que ce serait un retour en arrière à la v3 et ses travers, là ou justement dans la v4 on a introduit un process propre qui garanti l’intégrité et la stabilité du logiciel.

Je m’explique: quand on déploie une image Docker de Gladys 4, on déploie un build “atomique”, c’est à dire une version figée qui a été testée, buildée, et déployée.

Ce build il a un numéro de version, un hash, c’est un ensemble cohérent qui a été testé, et tu es certain (grâce au hash du build), que lorsque tu récupère la nouvelle version du logiciel, tu as reçu le bon build d’un numéro de version précis. (Et pas une version pirate, ou un fichier malformé en cas d’erreur réseau)

Quand Watchtower met à jour Gladys, tu as la garanti absolue que la mise à jour va soit réussir, soit échouer (et ainsi tu vas rester dans la version précédente, mais pas dans un état batard).

En cas de problème de réseau, c’est physiquement impossible que tu atterrisse dans un état intermediaire ou tu aurais la moitié des fichiers de la version d’avant, et la moitié des fichiers de la version d’après.

Essayer de bypasser ce process pour certains fichiers (avec une mise à jour via Github comme tu dis), c’est devoir faire nous même tout le travail que fait Docker (vérification des hash, etc…), et surtout c’est perdre l’atomicité des versions et des mises à jours

Perdre l’atomicité, c’est s’exposer à des bugs “mystiques” assez dur à résoudre, car un numéro de version ne détermine plus un set de fichiers données et cohérent.

Si un utilisateur vient nous voir avec un problème, si il nous dit son numéro de version Gladys, ça ne nous aidera pas forcément: on devra savoir aussi à quelle moment il a fait son pull des fichiers, c’est pas terrible.

Je sais pas si tu vois l’idée ? :stuck_out_tongue:

Retour au problème initial

Bon si je comprend bien, tu n’es pas satisfait de la fréquence des release Gladys ? ^^

En soit, faire une nouvelle version de Gladys, c’est un clic sur un bouton, rien de plus (ça prend 10 sec).

Si tu regarde le planning des releases, je fais en général une release toutes les 2 semaines (hors été, tout le monde était off donc j’évite de faire une release qui va potentiellement avoir un impact sur l’installation des gens pendant qu’ils sont hors de chez eux. Et si ta domotique casse au seul moment ou tu veux justement surveiller ton domicile, c’est pas top).

Si on décide de passer à un rythme plus soutenu, on va perdre en qualité de release, déjà que là actuellement j’ai déjà pas énormément de retour sur les builds dev que je fais, si on passe à toutes les semaines, ou tous les 4 jours, je suis pas certain que la communauté suive, et surtout ce n’est pas vraiment en accord avec les valeurs de la v4: on fait les choses bien, la stabilité est plus important qu’aller vite.

Pour parler du Zigbee2mqtt

Vu que ta frustration vient du Zigbee2mqtt, une solution serait de faire différemment pour le Zigbee2mqtt:

  • Mettre en place une détection automatique des feature type/category comme on a fait pour le Philips Hue par exemple ?
  • Permettre à l’utilisateur de déclarer lui même certain périphériques non reconnu dans l’UI ?

Tu en pense quoi ?

Hello,

Pas de soucis :wink:

Tkt pas je suis pas frustré je me dis que ça peut être dommage de devoir attendre pour des changements si mineurs. Pour le coup je comprend tout à fait l’idée d’avoir une version testé que tout passe par le même process. L’idée c’était surtout de poser la problématique ici :slight_smile:

Je suis satisfait globalement de la fréquence de release t’en fais pas toutes les 2 semaines c’est déjà très bien :wink:

Sur ce point je suis plutôt pour ! Ca peut répondre aux problématique de ce module du fait qu’il existe 1 milliards d’équipements compatible et ca simplifierai le process

Bonne idée :slight_smile:

Non mais dans l’idée je comprend 100% ta frustration dans le cas du Zigbee2mqtt, c’est vrai que c’est frustrant d’être bloqué alors qu’en soit c’est une configuration si simple derrière à changer.

Je pense qu’une configuration manuelle dans l’UI (pour les cas particuliers quand Gladys ne connait pas le device) peut être une bonne solution, on pourrait imaginer une sorte d’UI qui te montre un mapping avec à gauche les features qu’envoient Zigbee2mqtt, et de l’autre les fonctionnalités Gladys, un truc super clean

@cicoub13 tu en penses quoi ? :slight_smile:

1 Like