Deploy new version faster

Configuration
1

Hello everyone,

I wanted to discuss with you and get your thoughts on improving a point that I find not optimal.

If I’m not mistaken, in the current process, when we make a code change, we have to rebuild everything (logically) and deploy a new version. Currently, @pierre-gilles validates the features and especially pushes a new version with many additional features.

It would be interesting to be able to push things much faster. For example, adding a device to a library (like zigbee2mqtt). It turns out that if someone has an unsupported device, we go through this entire process which, in my opinion, is cumbersome for this kind of use.

We could imagine something simpler to quickly deploy new devices. For example, a file that we retrieve from a repository and that is pulled by the Gladys instances. This allows for small additions without necessarily going through an « unnecessary » wait, especially when you need to add an ID in a JSON file. :blush:

Of course, this logic could be used elsewhere; it’s more of a pattern that could be interesting. We stay within a controlled framework (everything is automatic with control on PRs, etc.), but at least we differentiate the deployment of major updates and small additions.

What do you think?

2

Hi @damalgos!

I didn’t see your message, I’m responding now :slight_smile:

I’ll give you my opinion on this. In theory, it might seem nice, but in practice, I think it would be a step back to v3 and its flaws. In v4, we introduced a clean process that guarantees the integrity and stability of the software.

Let me explain: when you deploy a Gladys 4 Docker image, you deploy an « atomic » build, meaning a frozen version that has been tested, built, and deployed.

This build has a version number, a hash, it’s a coherent set that has been tested, and you are certain (thanks to the build hash) that when you get the new version of the software, you have received the correct build of a specific version number. (And not a pirated version, or a malformed file in case of a network error)

When Watchtower updates Gladys, you have the absolute guarantee that the update will either succeed or fail (and thus you will stay in the previous version, but not in a bastard state).

In case of a network problem, it is physically impossible to end up in an intermediate state where you have half of the files from the previous version and half of the files from the next version.

Trying to bypass this process for some files (with an update via GitHub as you say), means we would have to do all the work that Docker does (hash verification, etc.), and above all, it means losing the atomicity of versions and updates.

Losing atomicity means exposing yourself to « mystical » bugs that are quite hard to solve, because a version number no longer determines a given and coherent set of files.

If a user comes to us with a problem, if they tell us their Gladys version number, it may not help us: we will also need to know when they did their pull of the files, it’s not great.

I don’t know if you see the idea? :stuck_out_tongue:

Back to the initial problem

So if I understand correctly, you are not satisfied with the frequency of Gladys releases? ^^

In itself, making a new version of Gladys is a click of a button, nothing more (it takes 10 sec).

If you look at the release schedule, I usually do a release every two weeks (except in the summer, everyone was off, so I avoid making a release that might potentially impact people’s installations while they are away from home. And if your home automation breaks at the only time you want to monitor your home, it’s not great).

If we decide to switch to a more sustained pace, we will lose quality in the release, already now I don’t have much feedback on the dev builds I make, if we go to every week, or every 4 days, I’m not sure the community will follow, and above all it is not really in line with the values of v4: we do things well, stability is more important than going fast.

To talk about Zigbee2mqtt

Since your frustration comes from Zigbee2mqtt, a solution would be to do things differently for Zigbee2mqtt:

  • Implement automatic detection of feature type/category as we did for Philips Hue for example?
  • Allow the user to declare certain unrecognized devices in the UI themselves?

What do you think?

3

Hello,

No worries :wink:

Don’t worry I’m not frustrated I think it’s a shame to have to wait for such minor changes. In this case, I completely understand the idea of having a tested version that goes through the same process. The idea was mainly to raise the issue here :slight_smile:

I’m generally satisfied with the release frequency, don’t worry, every two weeks is already very good :wink:

On this point, I’m rather for it! It can address the issues of this module because there are 1 billion compatible devices and it would simplify the process

Good idea :slight_smile:

4

I totally get your frustration with Zigbee2mqtt, it’s really annoying to be stuck when it’s such a simple configuration to change in the end.

I think a manual configuration in the UI (for special cases when Gladys doesn’t know the device) could be a good solution. We could imagine a kind of UI that shows you a mapping with the features sent by Zigbee2mqtt on the left and Gladys’ features on the right, something super clean.

@cicoub13 what do you think? :slight_smile: