The current process for upgrading a Mattermost server (found here) is somewhat painful, and feels like it takes longer than it should.
Ideally, I’d like to be able to trigger a server upgrade from the System Console, and have it take care of things for me. The same goes for server plugins… currently the administrator needs to watch the GitHub page for every plugin (or follow @mattermost onTwitter). The same goes for the desktop Mattermost client. Mobile clients get automatically updated whenever a new version is released (perfect!).
What needs to be done to make this happen?
The desktop client is probably fairly straightforward… things like Discord and Slack tell you when you need to update, you click a thing, it updates. Maybe Electron has a canned API for this, or maybe there’s a commonly-used technique?
For plugins, the server code will have to have a way to see what version(s) are available, and (presumably) what server API level they require.
For the server, I have no idea. Split plugins into “comes with the server code” vs. “added later by admins”, to make it safe® to update? Move user data out of the mattermost directory completely? Do other Go-based servers have a good method for handling this?
For the time guess one have to be creative on this side, we’ve built an internal mu.sh script based on the upgrade process, yet because of all folder move involved it will need more knowledge from me to improve the script.
I believe because of the Docker being supported and for many other ways to deploy Mattermost it leaves users to be open like the source and add their ways or improvements on the process.
The easiest upgrade* way would be to have this built in the application. (*Most modern application if they respect themselves and their users, will have one click upgrades/modules updates built in the application)
The upgrade process described there can be automated outside mattermost, yet I am not sure what solutions are for Go available on this side.
Someone made an attempt to make a suggestion here:
Yet that is not the way one should propose a feature. Thats why personally trying to give feedback directly to those involved in process, pitty not many companies take such feedbacks, they will loose a lot. we all learn from loosing at first.
Personally places like USerVoice has never been proved efficient, and are way much better to gather feedback to improve product, and customer experience.
I don’t see us realistically making the server self-updating. The easiest path forward here is to use our Docker containers, and simply upgrade the image — the server already takes care of the database migration automatically from there. I don’t know a lot of server-side applications that upgrade /themselves/, but I’d love to hear of some examples from which we could learn.
On the plugins side, good news: we are aiming to launch a Plugins Marketplace MVP in the next few releases, which should make it much easier to discover (and later upgrade) plugins. I fully agree that plugin upgrades have been much more painful, but we wanted to tread carefully here given how powerful plugins are.
Or there are many other hardcore apps that have a sort of automatic upgrades. Whmcs can be another example. Most of them are based on web technologies and rather made into apps with the new step of web 2.0. For me any application made and adapted to these times should keep count by default of automatic upgrades especially when the manual steps are not for all to do or act upon. This alto not hard would still involve someone to login always or a script that any changes in the process would be needed to reflect immediately on both sides.
Needing to manually check for and install new versions of the desktop app is somewhat archaic for sure. I came here to suggest that it’s published on the Microsoft Store for easy updating - but any sort of auto-update mechanism, or new version notifications at the very least, would be highly appreciated.
we all learn from loosing at first.