...
- 4.x
- 5.x
- 18.x
- 19.1
- 19.2
- 20.1
- 20.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
Info |
---|
Partial Deploy with APEX needs to have an install.sql file in the SCM. This can either be created by hand, or will happen automatically if you allow FlexDeploy to handle the export from APEX |
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 plan to use partial deployment model, make sure to check Partial Deployments checkbox and select Oracle APEX as project type.
Plugin Operations
Child pages (Children Display) |
---|
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
- http://www.oracle.com/technetwork/developer-tools/apex/learnmore/apex-life-cycle-management-wp-3030229.pdf
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/