24

Oracle Apex is great. The biggest problem I have with it is using it along with source code control. Generally after making a change, the entire application gets exported and the resulting SQL script checked into source code control.

The problem is that because it's unclear what most of that exported script is doing, I have to treat is as essentially a binary file. That means changes from multiple source code branches can't be merged together, which severely limits its usefulness.

I've heard of some people exporting each page and putting those into source code control individually. First, that sounds like a major pain. Second, Apex does not allow you to import a page into any application other than the one from which it was exported. So it's hard to have two developers working in their own copy of an application at once.

Has anyone found a good way to handle Apex with source code control? I'm using Subversion, thought I doubt it makes a difference.

eaolson
  • 14,717
  • 7
  • 43
  • 58
  • 1
    I wrote [a small article](https://ruipedrobarata.blogspot.ie/2017/12/simpler-version-control-for-oracle.html) on a working approach to source control with APEX, might be of interest here. The main idea is to shift development over to the developers' own workstations, and use Subversion to keep in sync and merge all the different APEX application versions. This makes the source control workflow look like [this](https://i.stack.imgur.com/r9zvb.png) That is, each developer has his own instance of the Oracle database, installed on his own workstation. As long as all the workspace and application I – Rui Barata Mar 05 '18 at 21:24

3 Answers3

11

I've dealt with this issue as well. Another aspect of the problem is that Apex is tied so tightly with the underlying SQL database that any changes in the SQL need to be reflected as well (in other words exporting each page has other issues above and beyond being a huge pain). Actually as far as I know the shared components are not exported when you export a page as well.
We dealt with this by exporting the entire application and checking it in. Essentially, there isn't a better way at present to deal with versioning in APEX. I also remember seeing something on the Oracle APEX forum that there is a way to split the exported file into component parts, but I have not tried it.

jle
  • 9,316
  • 5
  • 48
  • 67
  • 3
    5 years later... has Oracle bothered to address this? It is a huge pain to collaborate on an Apex application. It seems that Apex was designed by some genius who realized he could have infinite job security by creating applications with Apex :/ – Avindra Goolcharan Mar 20 '16 at 17:33
  • https://www.npmjs.com/package/apex-source-controlIt claims it has a solution with oracle apex 5.0. We will try out the whole process when there is time.. – Mookayama Oct 06 '16 at 16:31
6

I have come up with what I think is a reasonably good solution for this issue. The main idea is to shift development over to the developers' own workstations, and use Subversion to keep in sync and merge all the different APEX application versions.

This makes the source control workflow look like this:

this

That is, each developer has his own instance of the Oracle database, installed on his own workstation. As long as all the workspace and application IDs are kept in sync between the workstations, merging APEX dump files is quite easy -- and having source control ensures they stay that way.

My team has been using this approach for almost two years now with excellent results.

Based on this experience, I wrote a small article detailing the whole approach, as I hope it will be useful for other teams.

Rui Barata
  • 61
  • 1
  • 4
1

Default Apex Export application into one sql file (Apex Export). But also Apex has APEXExport Splitter, which export application into separately parts (css, template, etc.) Good way it is commit these parts into svn

1. Automating APEX Export for SVN

2. How to use source control with apex?

3. Apex-source-control

Ramin Darvishov
  • 1,043
  • 1
  • 15
  • 30