Simplifying upgrade instructions

[osresearch]

I've upgraded my self-hosted mattermost multiple times with a much simpler set of instructions and wonder if the documentation could be improved by a few small changes.

1. Rename the top-level directory in the tar file so that it uses the semvar name, ./mattermost-X.Y.Z instead of just ./mattermost. This would eliminate the need for the tar --transform step or extracting in a temp directory and moving.
2. Use a symlink from /opt/mattermost to /opt/mattermost-X.Y.Z so that the startup scripts always refer to the latest version, and so that the older versions are easier to roll-back if necessary.
3. Copy or move only the data, config, and client/plugins directories to the new directory instead of the complex find command to try to clean-out any old files.

My usual upgrade steps (the tar transform is necessary since the distribution tar file doesn't have the new name):

tar -xf mattermost-X.Y.Z-linux-amd64.tar.gz -C /tmp
mv /tmp/mattermost /opt/mattermost-X.Y.Z
cd /opt/mattermost-X.Y.Z
chown -R mattermost:mattermost .
mv ../mattermost/data .
mv ../mattermost/client/plugins ./client/
cp ../mattermost/config/config.json ./config/
rm /opt/mattermost
ln -s `pwd` /opt/mattermost

[cwarnermm]

Thank you, @osresearch, for submitting this contribution. While this abbreviated upgrade process wouldn't replace the existing expanded product documentation, there's value in offering a condensed version of the process for experienced admins. @coltoneshaw @sadohert - Would you be open to reviewing this contribution for technical accuracy and completeness, please?

[coltoneshaw]

I definitely agree that this would be far more streamlined for an upgrade and management process. It would be a bit of an implementation shift for our customers but I could see some instant benefits by doing it via this process. For example the complex find command in our current docs always stumps people.

If we want to do something like this, I'm curious how we'd want to roll it out. You'd want to update both implementation and upgrade documentation for this long term.

[cwarnermm]

Adding @nab-77 for visibility

[nab-77]

@osresearch Thanks for sharing, and I specifically like the proposal for "versioning" the deployment using symlink. Can I ask for some more feedback, namely what are you feelings on an RPM/DEB package?

As @cwarnermm explained such a condensed flow would not replace, but compliment.