Deploying Staging and Production¶
A push on a feature branch deploys Test Servers. Staging and Production Servers are deployed by hand, with the same deployment: you choose the moment and the git ref.
Launch a deployment¶
On the App Server form, click Upgrade / Deploy, in the header. The same wizard opens from:
- Upgrade / Deploy on the form of an HA pack;
- Upgrade / Deploy in the menu of an App Server's kanban card;
- Deploy / Upgrade Server(s) in the Actions menu of the App Server list, for several servers of the same kind at once.
The wizard is pre-filled from the Application Definition, tab CICD LXC, sub-tab Staging Servers or Production Servers, according to the server's qualifier.
| Field | What it does |
|---|---|
| Git Refspec | The branch to deploy. Pre-filled with the server's own branch. Muppy checks it exists on the remote, and refuses a ref it cannot find. |
| Quick Code Deployment | Deploy the code only: no database upgrade, no backup, no builder, no stop before the backup. |
| Backup database before upgrade | Back the database up before the upgrade command runs. |
| Impacted Servers | The servers deployed, with their Role in Pack. |
Tab Upgrade:
| Field | What it does |
|---|---|
| Upgrade command (DB migration) | The command that upgrades the database. none skips the upgrade. |
| Code deployment (via git) on Primary | Update the code on the primary, or on a server outside any pack. |
| Stop before Git code deployment | Stop the application before updating the code. |
| Duplicate database before upgrade | Copy the database to <database>_bu before the upgrade. On failure, Muppy puts the copy back. |
| Delete Dupl. DB after upgrade | Drop <database>_bu once the upgrade succeeded. |
| Stop server before database backup | Stop the application before the backup or the copy. |
| Code deployment (via git) on Standbys | Update the code on the standbys of an HA pack. |
| Stop before Git code deployment (Standbys) | Stop the standbys before updating their code. |
| Reset Git repository | Delete the repository and clone it again. The builder then always runs. |
| Launch builder (npm, maven, gradle, ikb,...) | Run the builder after updating the code. |
Click Launch. There is no confirmation dialog. A toast says the deployment started; it runs in the background, one message per server under Muppy › Qs › Messages.
What the deployment runs, step by step, is in How It Works. How long the application stays down is in Configuration.
Production in an HA pack¶
Launched from the pack, or from its primary, the wizard lists every server of the pack.
- Muppy deploys the primary first, then the standbys, in that order.
- The primary updates its code, upgrades the database, and restarts.
- A standby updates its code and runs the builder; it never runs the upgrade command, since its database is a replica of the primary's. It is then restarted, unless HA Standby mode keeps it stopped.
- The messages of a pack form one group: a failed primary holds its standbys back until its message is archived.
The deployment record¶
Each deployment leaves a record on the App Server, page Upgrades:
- list Deployments: Ref, Git Refspec, Start Git index and End Git index, Start, Duration (s), Downtime, and the state — In Progress, Upgrade Success or Upgrade Failed;
- list Database upgrades: one line per database upgraded, with its Nb Errors.
Open a database upgrade to read its log: Log file to download it, pages Logs,
Warnings and Errors. Muppy keeps the file the command writes to $UPGRADE_LOG_FILE
when the command names it, and the command's output otherwise.
A ribbon on the App Server form shows the last state: Upgrade Ok, Upgrade failed! or Upgrade In Progress.
When a deployment fails¶
The upgrade command fails (non-zero exit code, or ERROR lines in its log). The
deployment ends Upgrade Failed, and the application is restarted on the new code.
- With Duplicate database before upgrade, the database is already back to its state before
the upgrade. The failed one is kept as
<database>_failed_upg_<dbupgN>. - With Backup database before upgrade only, the database stays as the upgrade left it. Restore the backup to go back.
Any other step fails — git fetch, the builder, the backup, the copy. The deployment
stops where it failed, and the application stays down if it was stopped. The deployment shows
In Progress until the next deployment of the server marks it Upgrade Failed.
To bring the application back:
- deploy again once the cause is fixed;
- or start it as it is: Start All, on the App Server's Systemd Units.
There is no rollback button. To go back to the previous version:
- Deploy the previous ref. Start Git index, on the failed deployment, says which code ran before.
- Restore the backup taken before the upgrade, if the database was upgraded. It is listed under Muppy › Databases › PostgreSQL › Database Backups (pg_dump). Stop the application first: the restore drops the database. See Restoring a Backup on a Staging Server for the steps.