Upgrade and Rollback
In NocodilySuite, every built API and WebUI is assigned a Version.
Version-based management lets you make changes to production safely and quickly revert to a previous state when problems occur.
What Is a Version
A Version is an identifier attached to a "confirmed state of an API or WebUI at a specific point in time."
It is not just a number — it plays a central role in change management and operational control.
In NocodilySuite, even after modifying schemas or logic in the console,
the changes are not reflected in production until you explicitly run an upgrade.
This prevents in-progress changes from accidentally affecting production.
| Role of Versions | Description |
|---|---|
| Change history tracking | Record what changed and when — useful for investigation and auditing |
| Controlled production deployment | Run an upgrade intentionally only when you are ready |
| Rollback anchor | Specify exactly which state to return to when a problem occurs |
| Compatibility management | Manage the impact of API changes on clients at the version level |
Upgrade
An upgrade is the operation of moving from the current version to a new one.
After modifying schemas, logic, and settings in the console and verifying they are ready, run the upgrade.
Upgrade Flow
Edit in console → Verify (DevelopEnv / StagingEnv) → Run upgrade → Reflected in production
Key Points
- Runs independently per environment — Upgrading in StagingEnv does not affect ProductionEnv
- Previous version is retained — Even after upgrading, the old version remains recorded as a rollback anchor
- Operable from the console — No specialized CLI operations or deployment work required
When You Need to Upgrade
| Scenario | Description |
|---|---|
| Added a field to the schema | You want to reflect new endpoints or fields in production |
| Fixed validation logic | You want to apply changes to custom code (Embed Code) |
| Changed authentication settings | You want to update RBAC or endpoint authentication settings |
| Modified the WebUI layout | You want to deliver screen changes to production users |
Rollback
A rollback is the operation of reverting to a previously stable version when problems occur after an upgrade.
Why Rollback Matters
Production releases always carry risk.
Problems that did not reproduce in test environments can surface in production —
and whether you can revert quickly and safely at that moment determines the reliability of the system.
In NocodilySuite, every version ever built is retained,
and you can immediately run a rollback to any specified version from the console.
Rollback Flow
Detect issue → Identify affected version → Run rollback → Restored to previous version
Key Points
- Revert to any version — Not just the previous version; any past version can be restored
- Runs independently per environment — Roll back ProductionEnv only while leaving StagingEnv untouched
- Operable from the console — Handle emergencies without specialized expertise
When You Need to Rollback
| Scenario | Description |
|---|---|
| Errors spiked after an upgrade | A bug introduced in the new version is occurring in production |
| API response changed and broke clients | A compatibility issue caused by a schema change |
| An unintended permission change occurred | Want to quickly revert an authentication or access control misconfiguration |
| WebUI layout broke | Want to immediately fix a UI problem introduced by a screen change |
Operational Flow for Version Management
Combining environments and version management creates a safe release cycle.
DevelopEnv StagingEnv ProductionEnv
───────────── ───────────── ─────────────
v3 (in dev) → v2 (in review) → v1 (live)
↓ no issues
upgrade to v3
↓ confirmed
upgrade to v3
- If a problem occurs in production, roll back ProductionEnv to v1
- Investigate the root cause in StagingEnv, fix it as v4, and re-release
- Because each environment is independent, investigation and fixes can proceed without stopping production