Though deployment tools can do an update process, they have no way of checking for updates themselves. So that part of work has to be done by custom scripts or some third-party software.
On other hand, the clients do check for updates, but the result can’t be shared, so they annoy the users by notifications until they get updated.
As result we have two separate, parallel procesess:
- Checking for updates by some scripts and launching updating via deployment tools;
- Checking for updates from the rocket.chat clients side and showing notifications (ok, in our case we at least can silence them by the /disableAutoUpdates key, but…);
As a bonus, we can’t control where the clients go for updates nor can direct them to a local server, and that’s a potential security and management issue as they waste traffic, and you need to keep ports opened for them and etc. I don’t even say that you can’t manage the clients in any way, see their info (e.g. what their version is)…
In the light of that, it’s more than logical and a good practice in itself to rely on a local server for all that. And personally I don’t see any major obstacles for developing that.
- A config for clients - check!
- A server and admin panel - check!
- Clients can check for updates - check!
In fact many things have been already done, but from an enterprise point of view the current state is half-baked. It’s already an accomplished chat, but there are no means for a centralized management yet…