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

Development for Oracle APEX is done 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 in to 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. Build The build in this case is a 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.

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

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

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 languageDeploy 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 version s 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

• http://www.oracle.com/technetwork/developer-tools/apex/learnmore/apex-life-cycle-management-wp-3030229.pdf

• https://www.insum.ca/oracle-apex-version-control/

• http://joelkallman.blogspot.com/2016/01/oracle-apex-development-and-multiple.html

• http://www.explorer.uk.com/apex-version-control-team-working/

• https://jeffkemponoracle.com/2014/01/parallel-development-in-apex/