VBCS has a built-in deployment mechanism — click Stage, then Publish. This is fine for a personal project. For enterprise applications with multiple environments and ongoing releases, you need a structured approach.
Environment strategy
The standard Oracle Cloud environment progression: Development → Test/UAT → Production
Each environment has its own VBCS instance (or separate applications within the same instance). The key decisions:
- Single VBCS instance with separate applications per environment, or separate OCI tenancies?
- How are service connection endpoints promoted between environments?
- Who has deployment authority for each environment?
For most enterprise deployments: separate applications within the same instance, with production deployment requiring an approver role separate from the developer.
Version management
VBCS uses a simple publish/stage model — it doesn’t have Git-based version control built in. Work around this:
- Name your versions descriptively — use the “Version” field in VBCS to tag each published version with a meaningful identifier (e.g.
v1.2.3-po-workflow-fix) - Export the application before major changes — VBCS export creates a ZIP you can store in Git as a binary backup
- Document what each publish contains — VBCS doesn’t have a changelog; maintain one externally (Confluence, Notion, a simple text file)
Service connection endpoint promotion
The trickiest part of VBCS deployment: service connections that point to development endpoints need to point to production endpoints in the production app.
VBCS doesn’t have environment variables — the most reliable approach is to maintain the endpoint URLs in OIC lookup tables, fetched by the VBCS app at startup. This way, the VBCS application code is identical across environments; only the lookup table values differ.
Staging vs Publishing
Stage deploys to a staging URL accessible for testing — real users cannot access it without direct link and specific permissions.
Publish replaces the live version — all users hit the new version immediately on next page load.
For significant releases: stage first, verify with business users, then publish. For patches: assess risk; minor bug fixes can go directly to publish if staging delay isn’t warranted.
Rollback
VBCS’s Previous Version feature lets you revert to the prior published version. Keep this in mind — don’t publish until you have a stable baseline to roll back to.