If a release goes wrong

If a release fails or misbehaves, LobLogix keeps the record of what happened and offers only the ways back that are safe. Sometimes that is the previous version. Sometimes it is a corrected one.

What you see first

The Deployment page shows which step failed: the build, the changes to stored records, the start, or the verification. The output of that step is kept, so nobody has to repeat the failure to understand it. A failed release never becomes the current one.

Going back to the previous release

LobLogix offers this only when it can show that it is safe:

• The changes to stored records did not run, or stopped before changing anything.
• The stored records are as the previous version left them.
• The previous version still fits them.

These are checked when the choice is offered and again when you confirm. Admins and Editors can confirm.

When going back is not safe

If stored records were already changed, the previous version may no longer fit them. The way out is then a corrected version: LobLogix proposes the correction, your checks run again, and you release it like any other.

What LobLogix will not do

• Offer a “roll back” button that it cannot stand behind.
• Reverse a change to stored records on its own.
• Try a second time while the outcome of the first is unknown. It finds out what happened first.

Your records

Going back changes which version runs. It does not restore records. Preview and Stage hold test records and come with no backup, so keep nothing there that you cannot enter again. Backups and high availability are part of production, on the business tiers. See Going live on your own infrastructure: how it is designed.