FlexDeploy - Oracle Application Express Plugin Guide

Oracle APEX plugin provides a means to export and import (deploy) Oracle Application Express (APEX) applications.

See blog series FlexDeploy Loves APEX for additional details.

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

  1. Developers export application as SQL files and commit to Source Control System. Build in this case is simple export of Source Control files and zips it as artifacts. FlexDeploy Apex plugin Deploy operation then uses unzipped SQL files to import using APEX_APPLICATION_INSTALL package.
  2. FlexDeploy Apex plugin Export operation exports code from Development environment and zips it as artifacts. FlexDeploy Apex plugin Deploy operation then uses unzipped SQL files to import using APEX_APPLICATION_INSTALL package.

Zip of files is just done to save space and is not at all required. In either case, FlexDeploy project refers to one and only one Application Id and Work space. You are free to organize FlexDeploy projects as appropriate in your development process.

In summary,

  • You can either export APEX application using export operation automatically or export manually from application builder. FlexDeploy workflow can also automatically commit exported file to your choice of SCM.
  • Deployment of application is done using deploy operation. @Since 5.0.0.1.2 version of FlexDeploy APEX plugin, you can also deploy individual page files, which will require you to maintain page level SQL files in your SCM folder.
  • Use of FlexDeploy platform allows you to orchestrate many changes to various environments using approvals, schedule etc. For example, necessary PL/SQL logic and structures can be migrated using other plugins provided with FlexDeploy along with APEX application changes.

Source options

  1. Entire Application sourced from development environment
    1. Regular project in FlexDeploy
    2. Build workflow will export entire application from development environment
    3. Deploy workflow will deploy entire application from versioned artifacts
  2. Entire Application sourced from SCM
    1. Regular project in FlexDeploy
    2. Build workflow will export entire application from SCM. Application is either exported and saved to SCM folder manually or using FlexDeploy workflow.
    3. Deploy workflow will deploy entire application from versioned artifacts
  3. Application pages sourced from SCM
    1. Partial deployment project in FlexDeploy with type set to Generic
    2. Build workflow will export entire application from SCM. Application pages are exported manually and saved to SCM folder
    3. Deploy workflow will deploy selected application pages from versioned artifacts

Supported Versions

  • 4.2 +
  • 5.0 +

Key Features

  • Supports multi language
  • Deploy applications or REST Services

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.
  • There is an excellent open source product called APEX Diff ( https://github.com/OraOpenSource/apex - diff ) which creates JSON exports of an application which can be easily compared with other versions of the application. This product is one of the best alternatives for comparing different releases of an application. Merging of application export files, or in any way modifying the application export script files is not supported by Oracle.
  • See JDBC PluginGuide to manage supporting database objects. We recommend use of Partial deployment approach.

References