Context
Goal: streamline the “develop → compile → test → deliver” loop for Forms 12c/14c across mixed Windows/Linux environments while preserving Oracle tooling and adding a modern DevOps layer. The approach uses Tomcat as middleware, GitLab (REST) for branching and traceability, and native Oracle mechanisms (proxy users, DDL triggers) for audit—without forcing teams to change their daily tools. The result: one‑click remote compilation from Builder, per‑branch isolation in FORMS_PATH, assisted PL/SQL packaging, and automated pre‑prod delivery with status feedback.
Remote compilation architecture
- Principle: intercept the Forms Builder “Run” action on the developer workstation and compile on the Linux server via a remote Tomcat that orchestrates frmcmp/frmcmp_batch with the target application environment. The response returns HTML build output and can optionally launch FSAL for standalone form execution to speed up tests without a browser. Version alignment follows standard Oracle Forms build/deploy practices.
- Metadata: application and context are inferred from the repository (Git via .git, CVS via Repository files, or a project root fallback) to apply the correct environment rules and compiler options. This keeps paths, FORMS_PATH, and frmcmp flags consistent with the selected application.
Branch isolation with Git
- Active branch detection provisions a dedicated server workspace: a per‑branch directory, a branch‑specific environment file, and a FORMS_PATH that is prefixed with the branch directory for true feature isolation. Testers can validate multiple features in parallel without artifact collisions or pollution of shared environments. Lifecycle (provisioning and cleanup) follows standard branch events (create, validate, archive) in the DevOps tooling.
DevOps pipeline: ticket → branch → build → pre‑prod delivery
- Ticketing and branching: the UI lists tickets (via REST integration with the ticketing system). Selecting a ticket creates or reuses the corresponding GitLab branch via API and manages the local/server clone plus a scoped file browser for that branch. The orchestration aligns to CI/CD patterns but focuses on the Forms/PLSQL flow: build, compile, artifact promotion, and status/log exposure.
- Assisted PL/SQL packaging: a live “changes” panel shows file diffs; a dual‑list allows selecting packages/procedures to include; the system generates CREATE OR REPLACE scripts to assemble the branch’s delivery bundle. “Deliver to pre‑prod” triggers an orchestration thread (build/compile/deploy), updates a tracking table, and publishes trace links for QA.
UI overview (short)
After sign‑in, an internal mapping links the ticketing identity to a scoped GitLab token used for API operations under least privilege. The user selects an application, views related tickets, chooses one, and the platform creates or reuses the associated branch and clone. A branch file browser, one‑click “open in Forms Builder” for FMB files, a continuous “changes” panel, and guided actions for commit/push and “deliver to pre‑prod” complete the workflow. Status indicators and trace links provide immediate feedback.
Fast execution via FSAL
To accelerate test loops, FSAL launches the compiled form as a standalone client, avoiding browser dependencies. It is straightforward to configure in Forms 12c+ and is well suited to frequent validations and controlled desktop environments. Per‑branch launch parameters help testers validate features independently.
Automated DDL traceability: proxy users + DDL triggers
- Proxy users: one proxy per developer enables work in the application schema while preserving effective identity via SYS_CONTEXT('USERENV','PROXY_USER'), providing precise accountability without altering familiar tools and routines.
- Database‑level DDL triggers: an AFTER DDL ON DATABASE trigger captures event type, object, SQL text, and identity (proxy/session) into an audit table. The packaging module then proposes including these captured DDL changes in the branch’s delivery bundle. This closes the gap between interactive development and reliable delivery scripts, greatly reducing omission risk.
Security and governance
GitLab tokens follow least‑privilege scopes, expirations, rotation, and encrypted storage; avoid token exposure in URLs and logs. Delivery jobs are idempotent, logged, and apply lightweight branch locks during orchestration to prevent conflicts and guarantee repeatability. The approach aligns with enterprise DevOps practices while remaining compatible with existing Forms/WebLogic/OCI deployments.
Observed benefits
- Productivity: remote compilation in seconds and immediate FSAL execution compress feedback cycles for both developers and testers.
- Quality and compliance: proxy identity plus DDL capture enables auditable, accurate changes and reduces missed scripts in deliveries.
- Adoption: no tool disruption; the platform adapts to SQL Developer/Forms practices while opening a path to richer CI/CD extensions when needed.
Discussion
Interested in feedback from other Forms teams: how are branch isolation and DDL traceability handled today, and which areas would be most useful to see in a follow‑up (API shapes, security patterns, data schemas, or operational resilience)?