APEX 20.1 has finally brought some level of version control to Oracle APEX.
Until now, it has been difficult to work with APEX as part of a traditional development life cycle. It has always been possible to export an entire application, but the Oracle APEX 20.1 export resulted in a single SQL file. Version control was only really possible at the application level.
A new feature of APEX 20.1 makes it possible to export your application as separate component files. The individual files can then be added to a version control system such as SVN or GIT.
A bit of history
Before taking a look at the new export feature in APEX 20.1, it is worth understanding how the same functionality was handled in the past.
APEX Splitter Java Utility
In the past, APEX included a Java utility called the APEX Splitter. This utility has now been deprecated.
The APEX Splitter Utility was a command-line tool that took the single application SQL file and separated it into individual files. It did a good job, but it was an extra step in the export process.
When the APEX Splitter Java Utility was deprecated, the functionality was moved to SQLcl.
Multiple applications and workspaces
Many times, several developers are working on the same project. In other words, all of the developers are contributing to a single application. The problem then is how to keep track of the development being done by individual team members.
To avoid code conflicts, some teams took the approach of having each developer work on their own version of the application. This approach works well if each developer is working in a specific area of the application. Still, this approach makes it somewhat difficult to keep track of changes.
A similar approach is to create a master workspace for the production version of the application. Each new or modified page is imported into the master application and the specific functionality is tested.
Using multiple applications and workspaces may still add value in specific circumstances, but this is not proper version control.
Build Options are still an important part of APEX today.
Build Options are simply an “on” or “off” switch that indicates if a specific component is to be available in the production application. You may have created a region, but are not ready to make it a functional part of the production. You still want it exported with the rest of the application, but don’t want to enable it just now.
The “As Of” export parameter is a nifty APEX feature that often goes unnoticed.
This simple little parameter can save your life! It exports your application “as of” a time in the past. When you mess things up, you can recover the application as it was before things went wrong. You can even use it to recover a deleted application!
APEX 20.1 new export feature
So, with all of that out of the way, how has APEX 20.1 enhanced the export functionality.
In APEX 20.1 you can still export an application as a single SQL file. All you need to do is complete the Export Preferences as you always have
Exporting your application in this way generates a single file with all of the pages and components included.
This single SQL file can be used to import the application into a workspace, or you could run it through SQL Developer.
Now here’s the cool bit added in APEX 20.1. There is a new “export as .zip” option on the Export Preferences screen.
This time a compressed zip file is created.
When you unzip the file, you will see that the application components have been split out.
When you open one of the component folders you will see that an individual SQL file has been generated for each of them. Here’s a look at the contents of the Pages folder.
Each of these individual files can now be added to your version control repository. When a new file is generated, you will be able to compare the two versions.
With individual SQL files, you can also import specific components to your application without having to import the entire application
Your version control repository can even be linked to SQL Developer for the convenience of the development team.
For many years, organizations have looked for a way to integrate APEX with their standard development processes. Rather than integrate APEX development they have resigned to adapting their process to include APEX.
We should not forget that some export features have been a part of APEX for years. The “as of” export preference provides a way of exporting an application component from a previous state. Build Options provides a way of turning “on” or “off” functionality in a production application.
Until the APEX 20.1 release, it has been very difficult to accomplish any kind of version control. Development teams that needed this functionality had had to make use of external tools or custom scripts.
All you have to do is take a quick look at the Oracle APEX Forum to see how many threads have to do with APEX version control. It has been a requested feature for many years.
The new export features of APEX 20.1 go a long way in offering some level of version control. Now, developing in APEX as a project team has become so much easier. No longer do we have to worry about overwriting code and components. It will be easy to revert to a previous version of an entire application or any one of its components.
With every new version of APEX, we are typically excited by UI or Page Designer enhancements, but the way we work with APEX applications is just as important. The new export features are powerful and should attract just as much attention.