History: Automatic updates

• «
• »

            This is the recipe for 1-click updates/upgrades starting in ((Tiki25)).
* Updates are in the same branch: 24.1 -> 24.2
* Upgrades are different branches: 21.3 -> 22.0 or 21.3 -> 24.1

!! Context
1-click updates/upgrades is a highly-requested capability which is tricky to do right. Risks include:
* broken updates/upgrades
* time-outs
* loss of local modications
* lower security on file permissions


!! Requirements
* Command line access
* Cron jobs
* Tiki Manager dependencies, or the capability to install them
** Git, etc.

!! High-level
Once set up, Tiki will update Tiki Manager, and Tiki Manager will updates/upgrades Tiki. Steps:
# Install Tiki from Git manually or with an external ((Manager|Tiki Manager)) (which you don't need to keep after)
# Set up ((Scheduler))
# Install the ((Tiki Manager Package))
# Use Tiki Manager to update/upgrade Tiki on demand (web or command line) or update automatically (via a cron job)

!! Benefits
While tools have been available for years for updates/upgrades, they required using the command line. Starting in Tiki25, the command line will only be required for the initial setup.

!!! Code directly from Git sources
* Can get any revision, and not just released versions
* Can efficiently maintain local modifications
** Before updates/upgrades, there is a check to detect conflicts
* Can use your own Git branch
* Can use merge requests / branches

!!! Pick your preferred lifecycle
* Pick any version (Bleeding edge, stable, Long Term Versions (LTS), etc. See: ((tw:Versions))

!!! Sensible file permissions
Since Tiki Manager is not ran by the web user (like Apache or www), it can set safer file permissions

!!! Background process
Since Tiki Manager is not ran by the web user (like Apache or www), it is not prone to time-out errors

!!! Testing on clones
* Thanks to Tiki Manager, you can easily clone, clone-and-update or clone-and-upgrade to have a test environment.

!!! A Tiki instance can be managed by more than one Tiki Manager
* So for example, a hosting company could handle updates for security issues via a remote Tiki Manager, while the site manager uses the local Tiki Manager for other updates/upgrades like testing new features.

!!! Tons of other features
* Please see ((Manager|Tiki Manager))

!! Before Tiki25 via command line
!!! Tiki Manager
Recent versions of ((Manager|Tiki Manager)) use Git, but previously, it was SVN
* ((Manager|#manager:instance-upgrade|instance-upgrade))
* ((Manager|#manager:instance-update|instance-update))
* ((Manager|#manager:setup-update|setup-update))

!!! svnup.php
[https://gitlab.com/tikiwiki/tiki/-/blob/master/doc/devtools/svnup.php|svnup.php] which is bundled starting in ((Tiki17))

{CODE(caption="An example of this script on a daily cron job")}
0 0 * * * cd /var/www/html/;  php doc/devtools/svnup.php
{CODE}


~tc~ (alias(1-click updates)) ~/tc~