3 ms·
Back end PHP/CodeIgniter, Front end TypeScript (no libraries), DB MySQL, ML / Scripts Python3, SCM git. Database upgrades are stores in an upgrades/<version>/u
by jonny383 7y ago
Back end PHP/CodeIgniter, Front end TypeScript (no libraries), DB MySQL, ML / Scripts Python3, SCM git.
Database upgrades are stores in an upgrades/<version>/upgrade.sql format. There can also be upgrades/<version>/upgrade.sh shell scripts.
For testing: back end is a bunch of single files run through a small, purpose built wrapper. Front end uses Jest.
Git hooks run locally for pre-commit and releases. Deployment is handled automatically by GitHub web hooks. The server handles any upgrade file (upgrade.sql and / or upgrade.sh) as triggered by GitHub web hooks. General rule of thumb here is never commit or push to master unless you're confident everything is ready (this only really works for a single person!)
Application server runs on a single instance Debian VM on Azure. MySQL runs on a separate VM instance on Azure, with a failover configured. There's also a read-only MySQL replica which is used for pulling large amounts of reporting data.
For backup (outside of that provided by Azure), there's a series of shell scripts running on cron to dump the database to an encrypted and time stamped backup. These are periodically fetched by other servers in different locations. Backups are kept for every business hour of operation. For user generated files (>1TB per year), rsync is run every hour on a couple of backup machines. Backups are manually checked by a person (for completeness and restorability) once per month. Automated backup checks are run daily on cron.
The longest down time that has been had in six years is fifteen minutes which was due to a bad database upgrade.