Hockeypuck generally does not need to be shut down while installing upgrades, but care must be taken on restart if upgrading across a major or minor version boundary.
When upgrading to the next minor version (e.g. from 2.3.2 to 2.4), it is normally possible to upgrade in-place, with a few caveats. If upgrading across more than one minor version at once (e.g. from 2.2.1 to 2.4), please see section 1.2.
Changes to the SKS sync filters may happen between minor versions, which will temporarily prevent sync between SKS partners running different minor versions, unless PKS failover is configured. You do not normally need to configure PKS failover on all partners, just the ones that are likely to be running a different minor version. PKS failover is less efficient than SKS sync, but can be used to prevent split-brain scenarios during a rolling upgrade process.
In addition, specific minor upgrades may have exceptional breaking changes. You should consult the release notes of each new minor version for details.
When upgrading to a newer major version (e.g. from 1.x to 2.x), or when upgrading across more than one minor version at once (e.g. from 2.2.1 to 2.4) it is good practice to reload the database. Reloading is an in-place operation if upgrading to version 2.3 or higher. Otherwise the dataset will need to be dumped from the old version before upgrading and then reloaded into the new one afterwards.
To reload in-place, first make sure that Hockeypuck is shut down, then incant (changing the location of the config file as appropriate):
hockeypuck-reload -config /etc/hockeypuck/hockeypuck.conf
This will ensure that all storage schemas and search indexes are up to date. It should take a similar amount of time to dumping and reloading the database (usually several hours), however it does not create any dump files and therefore requires less disk space. Note that your postgres tables may increase in size temporarily; this can be reclaimed using VACUUM.
Once this has completed, Hockeypuck can be started up as normal.