All posts · General

Version Control Strategies for Oracle Cloud Configurations

Beyond code — how to version control OIC lookups, VBCS design-time configurations, BIP templates, and environment-specific settings across dev, test, and production.

Anurag Jangra · March 5, 2026 · 5 min read · ... views

The version control gap in low-code

Oracle Cloud’s low-code nature means much of your work happens in web UIs — designing in OIC’s visual mapper, clicking in VBCS’s canvas editor, configuring in BIP’s data model builder. These interactions produce artifacts (files, exports) that need the same version control discipline as code, but teams often skip it because the workflow is less natural.

What to export and commit

Create a release cadence: at the end of each sprint, export all changed artifacts and commit to Git with a meaningful message.

OIC: export each modified integration as a .iar package. Use the OIC REST API to automate this: GET /ic/api/integration/v1/integrations/{id}/archive. Name files: INTEGRATION_NAME_v{major}.{minor}.{patch}.iar.

VBCS: export the full application via Visual Builder → Export Application. Commit the .zip with a version tag matching your release.

BIP templates: download .rtf and .xsl files from BIP catalog. Commit to bip-templates/{module}/.

OIC Lookup Tables: export as CSV (OIC has a REST endpoint for this). Commit environment-specific versions with suffix: CURRENCY_MAP_prod.csv.

Connection configurations: document connection properties (endpoint URLs, auth type, certificate names) in a YAML file — not the actual credentials (those live in a vault), but the structure so you can recreate connections.

Tagging releases

Before each promotion to production, tag the Git commit:

git tag -a v2.3.0 -m "Sprint 12 release: invoice approval workflow, supplier sync"
git push origin v2.3.0

Tags create immutable points in history. When you need to roll back, git checkout v2.2.0 gives you the exact previous release artifacts.

Environment branching

main                → production artifacts
develop             → next release staging
feature/oic-invoice → current sprint work
hotfix/bip-template → urgent production fix

Hotfixes go to main directly via PR, then are merged back to develop so develop doesn’t regress.

Automated export via CI/CD

Use OIC REST APIs in a GitHub Action to automate artifact export:

- name: Export OIC integrations
  run: |
    curl -u $OIC_USER:$OIC_PASS     https://$OIC_HOST/ic/api/integration/v1/integrations/INVOICE_SYNC/archive     -o artifacts/INVOICE_SYNC_v$VERSION.iar

Run this on a schedule or on pipeline trigger to ensure Git always reflects the current deployed state.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp