Updating ITFlow

A new version of ITFlow comes with new features and fixes. Most updates change the files and then the database, and ITFlow does both for you.

Before you update

• Take a backup. A snapshot of the whole VM is safest, because you can roll back in a minute if something goes wrong. Otherwise, make a Full Backup and copy it off the server.
• Read what's new. The Update page shows the notes for each release between yours and the newest, and GitHub has them all. Some releases need a step of their own, under Upgrading, and each release says what changes for your team.
• Pick a quiet time. Your team may see errors for a minute or two while an update runs.

From ITFlow

1. Go to Admin > Update. It says whether a newer version is waiting, what's new in it and what to do first - including whether any of ITFlow's own files have been changed on your install, which updating would put back.
2. Click Update ITFlow, and confirm.

Cron picks the update up within a minute and updates the files and then the database. The page shows it running and refreshes itself until it's done, and you get a notification when it finishes. Cron needs to be running - the page says so if it isn't, and the update waits until it is. See Update for more on the page.

If your ITFlow is managed by another, it's updated from there instead, by hand or automatically.

From the command line

Run the updater as the user that owns ITFlow's files, www-data on Debian and Ubuntu:

cd /var/www/itflow.example.com
sudo -u www-data php scripts/update_cli.php

It updates the files to the newest version on your branch, then updates the database. Anything you changed in ITFlow's own files is overwritten. Your config.php, the uploads folder and the custom folders are left alone.

To update only the database - after restoring an older backup, say - run:

sudo -u www-data php scripts/update_cli.php --update_db

If you run it as another user, it stops and tells you which user to run it as.

Releases and develop

$repo_branch in config.php decides where updates come from:

• master - the released versions. Use it for the ITFlow your team works in.
• develop - where new work lands first, before a release. Only use it on a test copy. Once develop has updated a database, there's no going back to master's version.