How to do a version / release control using APEX?

Question

Hi,
I have APEX 4.2 connected thru pl/sql gatewat , 11gr2 DB and using theme 24 cloudy.
We are currently using forms/reports for our ERP and we are thinking of replacing forms with APEX. We have source code control software that we use to update the development environment to QA then production. This was easy since all programs are represented by physical files. If you have 100 screens you would have 100 files more or less.
In APEX since everything is stored on the DB how do you control which changes should go to QA and production eventually. How do you make a cutoff if you want to build a new release/baseline/patch/service pack?
Thanks in advance!

Answer 1

Hi kvsinfo
You are making terrific sense, Apex is not only not-version control friendly, but makes version control an almost impossible task.
Change just one line in a template or page javascript and you will end with lots of differences when committing your changes. It is very difficult to revision control specific objects (like pages or LOVs.) And if you import an application under a different application ID (sometimes it is necessary), all the internal IDs change and when you commit your changes you will end up with hundreds of differences.
I am also looking for a better way but I am almost convinced that there is none. Apex 4.2 has lots of new functionalities but as far as I know nothing was done to improve integration with revision control systems. It is like they don't care about it, which is frustrating because revision control is extremely important for any system of some complexity. I say this as a constructive criticism.
We have a hard time here controlling versions of Apex applications. The methodology we use is that an Apex application is a unit. We don't control the versions of individual pages or other objects. We try to promote whole applications across environments whenever possible, by coordinating efforts among developers. If for any reason, for example, we need to deploy change A in page 10 to QA but not change B in page 20, we either:
- Undo the changes in page 20 and export the app, then apply the changes again
- Manually edit the export file to remove the undesired change
(at this point someone could say, just promote page 10; but this is a simple example, in most cases dozens of changes are made to an application across multiple pages, including shared objects, and only a handful should not be promoted)
This is terrible, terrible, prone to errors and time-consuming, but I don't see any other way of doing it.
And this is a simple scenario, there are other much complex scenarios. I also would like to hear from other people how they manage this.
Luis