Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Oracle APEX plugin provides a means to build and deploy Oracle Application Express (APEX) applications, and exporting a workspace from App Builder with the intention of placing under source control.

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.

  • Automatically export APEX application from development environment.
  • Selectively import entire application or individual pages and/or shared components.
  • 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.
  • Source application from development environment or SCM.
  • 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.
  • Manage supporting database objects (tables, packages etc.) using FlexDeploy JDBC or Database plugin.

As a result the changes are not backward compatible, and will cause refactor of any existing workflows and projects.


Development for Oracle APEX is performed on the database using Application Builder. 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.

  1. Developers export an application as SQL files and commit to Source Control System. The build in this case is a simple export of Source Control and packaging into a zipped artifact. 
  2. 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.

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 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.

Supported Versions

  • 4.2 +
  • 5.0 +
  • 18.x
  • 19.1

Key Features

  • Full & Partial Deployment models
  • Page/Component level build and deploy
  • Source from Application Builder or a Source Control Management system
  • Export Workspace/Application to filesystem, for commit into an SCM
  • Continuous Integration use cases
  • Supports multi language

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.
  • See JDBC PluginGuide to manage supporting database objects. We recommend use of Partial deployment approach.

References

  • No labels