Development for Oracle APEX is performed using Application Builder and code is stored in database. So, this is different than traditional development environment where code is created on developer's workstation and checked into a Source Control System. You can take one of two approaches to automate promotion of APEX applications.

Developers export an application as SQL file(s) and commit to Source Control System. The build in this case is a simple export of Source Control and packaging into a zipped artifact.
The application files (e.g. pages and components) can be built directly from Application Builder in a Development environment, bypassing a Source Control System all together.

No matter the approach chosen, the build operation produces a zip file containing the application sql files, and the deploy operation deploys the application to the target APEX database.

FlexDeploy Oracle APEX plugin supports both modes described above. Plugin also supports exporting multiple applications from App Builder with the intention of placing them under source control, which means if you schedule to run this process periodically, you will have history of application changes in SCM.

Major Improvements in 5.1.0.3

In FlexDeploy 5.1.0.3 the Oracle APEX plugin has undergone a major overhaul, supporting a very rich set of use cases. As a result the changes are not backward compatible, and will cause refactor of any existing workflows, topology and projects.

Supported Versions

4.x
5.x
18.x
19.1
19.2

Key Features

Full & Partial Deployment models.
Page and/or component level build and deploy/
Source application from development environment or SCM. Automatically export APEX application from development environment or source from SCM during build.
Selectively import entire application or individual pages and/or shared components.
Compare individual pages and/or components across all environments to find difference. Comparison is done against deployment state details in FlexDeploy.
Change detection during deployment, i.e. if application/page/component is already deploy (no changes) then it will skipped. User can force deployment if necessary as well.
Continuous Integration use cases
- Automated export of APEX application and commit to SCM of your choice to enable continuous integration.
- As application is exported in split format, it is very easy to use SCM tools to view changes over time to individual page/component.

Full Deployment vs. Partial Deployment

The FlexDeploy Oracle APEX plugin has support for both the Full Deployment and Partial Deployment models. With the Full Deployment model, an entire APEX application is built and deployed together. This is suitable for smaller applications and smaller development teams when changes can be easily coordinated as a whole.

With the Partial Deployment model, developers can assemble individual pages and components into FlexDeploy packages, and deploy subsets of the application. This model works well for larger applications and larger development teams when coordinated deployments of the entire application is just not feasible. Within this model there is also an option to build all files in the application, which in effect produces the same result as a Full Deployment. So in effect the Partial Deployment model provides a hybrid approach which allows teams to build and deploy subsets of the application or the entire application on-demand, which is why Flexagon promotes the use of the Partial Deployment model for all teams. As your application or team grows, you will have the ability to adjust your process without any reconfiguration.

With either model you can choose whether to source your application from a Source Control Management system or from Application Builder in a development environment directly.

If you use Force Deploy option during deployment, entire application will be deleted and recreated, otherwise only individual components will be deployed.

If you plan to use partial deployment model, make sure to check Partial Deployments checkbox and select Oracle APEX as project type.

Plugin Operations

Best Practices

Following best practices are captured from references shown below.

When importing the application into QA/Test or Production environments it is strongly recommended that each application is imported with the same Application ID, as used in development.
The application export file(s) should be checked into the source control system as part of the deliverables for a new release.
We recommend use of parsing schema owner user to export/import applications. This can be easily achieved by creating FlexDeploy instance with same name as parsing schema name. You can alternatively use SYSTEM user as well.
See JDBC Plugin Guide or Oracle Database Plugin Guide to manage supporting database objects (tables, views, packages etc.) . We recommend use of Partial deployment approach.

References

Browser not supported