Software Development Lifecycle with Oracle APEX

-

The software development lifecycle (SDLC) with Oracle APEX can take many forms. This blog post will give you an overview of four common scenarios. If you are interested to learn the details, I recommend reading the following paper from the APEX team:

https://apex.oracle.com/go/lifecycle-technical-paper
Author Steve Muench, Version 3.2, June 2025


1. Single environment, single developer

In a situation where a single developer works directly against the production environment, the lifecycle couldn’t be simpler. In this scenario, you typically would create a working copy of the app in APEX, make changes, test and merge changes automatically back into the main app. You should regularly backup your app and the database in case you need to restore.

This lifecycle is best suited for citizen developers and IT developers creating small and simple non-critical apps used by a few users.


2. Multiple environments, single developer

When you’re working alone on different environments like development, test and production, working in the development environment can’t impact your test- and end users. You can safely develop and test the release on a clone of the production environment before going into production. The environments can be all on a single Oracle APEX instance (using different workspaces), but it is highly recommended to at least separate dev/test from prod. Ideally, don’t test your own code on the test environment, but let somebody else do this for you.

Of course, this approach comes with more work. You will have to export and import the app including all involved database objects.

Even if you are a single developer, I do recommend use a version control system like Git in the process.


3. Multiple environments, with development environment shared with multiple developers

In combination with APEX features like “Page Locking” and “Working Copies”, the team members all work in the shared dev environment. Each developer creates their own working copy of the app within APEX and merges the working copy back into the main app when they are ready.

As a working copy of an application only keeps track of changes on application level, a version control system like Git is now an absolute must-have to keep track of underlying database objects like tables, views, packages, etc. Each developer is required to document and check-in all changes.

Once a release is ready, a delivery manager exports the main application and imports it into the test environment. After successful testing, this process is repeated for the production environment. To save time, especially when you are frequently staging a release, it’s recommended to automate the process using an CI/CD tool like Jenkins. To keep track of differences at database level, the developers and the delivery manager may want to use SQLcl Projects, which utilizes Liquibase under the hood.

Here are some detailed walk-throughs about SQLcl Projects:

https://danmcghan.hashnode.dev/tag/sqlcl-projects?source=tags_bottom_blogs 

 https://www.thatjeffsmith.com/archive/2025/05/getting-started-with-sqlcl-projects/ 

The APEX application is checked in by a script at least daily and a policy can be in place that sets up the dev environment from scratch before the working day starts (thereby enforcing developers to check-in changes to database objects on the end of their working day).


4. Multiple environments, with each developer having a private dev environment

This is also known as “feature centric” as you would like to develop new features on a private environment without the need of having a shared development environment (where developers may interfere with each other’s work). Before development starts, a feature branch is created in a clone of the repo after which the app and all required database objects are loaded in the local database. To quickly spin up your own environment, one could make use of a prebuild container image based on podman or docker. After development is done, a pull request is created to let somebody verify and merge the changes to the main branch.

To keep track of all the changes in the app and all related database objects, the developer may want to use SQLcl Projects in the process.

The staging process in this case is identical as for the shared dev environment scenario.


Comments

Post a Comment

Popular posts from this blog

Getting up to speed with Oracle Application Express (Oracle APEX)

-
Image
Want to start developing web applications with Oracle Application Express (Oracle APEX)? Make sure you don't reinvent the wheel and adapt good practises from industry experts right from the start. Here are some tips for beginners: 1. If you don't already have Oracle APEX installed, don't install it yourself, but get a free workspace within minutes on apex.oracle.com  to be used for demo purposes. To learn about Oracle APEX in the Oracle Cloud, you can use the always free tier on cloud.oracle.com/free with two databases up to 20 GB database storage each without any cost. For production purposes, we recommend that you pay 115 €/month (as of 20-JAN-2025) for the Oracle APEX Service on the Oracle Cloud. 2. Start making your first apps using one of the Oracle APEX tutorials: Hyand (German):  apex.hyand.com/development  (includes good practises!) Oracle (English):  apex.oracle.com/en/learn/tutorials  ( here is a good overview of these) 3.  Take note ...
Read more

My favorite new features in APEX 24.2 at a glance

-
Image
Oracle APEX 24.2 is out! Here are some of the major features in APEX 24.2 that I think are a great productivity booster for APEX developers. JSON Sources With storing JSON in a CLOB or BLOB column, you get some flexibility in your data model. Before 24.2, you couldn't let your APEX chart, form or report interact with the JSON structure without custom coding. With 24.2, this is now possible using JSON Sources. There is no need anymore to deal with JSON yourself using SQL, just let APEX do the heavy lifting. For those of you using 23ai of the Oracle Database, it works even with JSON Collection Tables and Duality Views! APEX Workflow enhancements Major features here include the possibility to call a workflow from with another workflow. This will let you re-use smaller workflow definitions. Also, a workflow administrator can now resume a workflow at any given activity in case of an unforeseen situation. Great must have features! For those of you that need to be BPMN-compliant, you migh...
Read more

Common misperceptions around Oracle APEX

-
Image
In the last years, I spoke with many in the IT industry about low-code and there seem to be several misperceptions around Oracle APEX, so I thought it is time to address these in this blog post. Here we go: 1. "APEX is only for Oracle customers" Existing Oracle Database customers can install APEX right-away without paying anything extra, have the infrastructure and licensing already set up, have the personnel to manage it all and store their data already in the Oracle Database. So, yes, APEX is very attractive for existing Oracle Database customers. Does that mean it is limited to this scenario? No. There are multiple reasons why you should start using APEX, although your company has no track record with Oracle: - Your data can reside outside the Oracle database. No matter if you are using PostgreSQL, MS SQL Server, SAP, Hubspot, MS Dynamics, Spotify, etc.: you can integrate it all without programming a single line of code! APEX is doing a great job and can handle even comple...
Read more