This document discusses continuously delivering APEX applications. It outlines managing source code using feature branches and merging into development, test, acceptance, and production branches. Flyway is introduced for database version management and tracking changes. The development process involves locking pages during development, exporting on completion, and merging to remote branches. Integration builds involve checking out code, installing the database with Flyway, importing and exporting APEX, and using Docker and Jenkins for automation and rollback capabilities.

1. Continuously Delivering
APEX Applications
APEX World 2018 Rotterdam

2. Agenda
• Introduction
• Managing source code
• Flyway
• APEX
• Jenkins

3. Partner SMART4Solutions
smartens@smart4solutions.nl
Sergei MartensFrans Jacobs
Software Architect VTTI
fja@vtti.com

5. Customer requirements
1. Every forth night a deployment of the software to production
2. Shared development database
3. Multiple teams working on the same application(s)
4. Be able to bring a specific features to test as soon as possible

6. Challenges
• APEX application exports insufficient (includes work in progress from other developers)
• DEV instable due to working drafts from other developers
• Many iterations of deployments
• Deal with failing deployments
• Deployment should be in a transaction (rollback when failing)

7. Managing the source code
Branch Strategy:
1. Every developer programs in own
Feature Branch
2. When finished merge request for review
3. When review ok, Feature is merged to
Develop
4. Develop merged into Release when
enough features developed for a release
after QA

8. Demo Feature request

9. Demo Feature request

10. Branch strategy
• Each environment has its own branch
• The features become more stable the higher the environments
1. Development
2. Test
3. Acceptance
4. Production

11. Deployment street
Team 1
Team 2
Integration
Deploy
(dev)
TEST
deploy
ACC
deploy
PROD
deploy
1. Feature branch merged into DEV branch
2. DEV branch merged into TEST branch
3. TEST branch merged into ACC branch
4. ACC branch merged into master
1. 2. 3. 4.

12. Database version management
• To know what has been deployed on the database
• To know what will be deployed, before actually doing it
• Track changes in the database after deployment

13. Introducing Flyway
• Open source project for migrating databases
• Flyway keeps track of what has been
installed
• Light weight
• URL: https://flywaydb.org/

14. Flyway – versioned scripts
Used for:
• Structural changes
• i.e. “create”, “alter”, “drop” …
• Insert of reference data
• User data corrections
Prerequisites:
• Must have a unique version.
• Is executed only once
• Script filename should be like:
V<version>__<name>.sql
• Applied in order of version
CREATE TABLE employee (
id NUMBER NOT NULL PRIMARY KEY,
name VARCHAR2(255) NOT NULL,
salary NUMBER NOT NULL
);
V1_Employees.sql

15. Flyway – repeatable scripts
Used for:
• Everything with “create or replace”, like
packages, views, triggers, etc.
Prerequisites:
• Does not have a version.
• Is executed when checksum changes
• Script filename should be like:
R__<name>.sql
• Applied alphabetical order
• Are applied after the versioned migrations
CREATE OR REPLACE view employees_v
AS
SELECT * FROM employees
R_Employees_v.sql

16. Flyway – metadata

17. Demo

18. DemoDemo

19. CD with APEX - Setup
• Every developer is a Workspace developer.
Used for page locking
• Workspace export to each environment
All workspaces need to have the same ID in all environment so deployment
does not break
• Start with empty application
Deleted pages are removed automatically during installation

20. Project setup
• Divide into folders based on technology
• Sub divide based on functionality

21. CD with APEX – Developing process
1. Create Feature Branch
2. Lock page before start
3. Export page to FB when finished (with same ID’s)
4. Push to Remote Feature Branch
5. Create Merge Request
6. Unlock page when merged into Development Branch

22. Demo APEX

23. Demo APEX

24. Rule #1
If you can do it in the database, do it in
the database!
-Use database package for List of Values
-Navigation in separate table
-…

25. Integration Build steps
Start Docker Stop DockerGIT Checkout DB
installation
Copy filesAPEX import QA Export APEX

26. Why Docker?
• Easy rollback of failing deployment and/or automated tests
• Docker is a application “virtualizer” (mini vm with one application)
• Each time a new container is started, the database is in the “initial” state
• You want to test the “real” migration as it should happen on the target environment

27. Jenkins
• Open Source automation server
• Plugin architecture:
• GIT
• Docker (start/stop containers)
• Flyway
• ssh (static files)
• Shell script (sqlcl APEX import/export)

28. Build sequence
Director job, perform GIT checkout
Migrate core schema with flyway
Migrate APEX UI schema with flyway
Copy static files to Docker
Import APEX components into Docker
Check with APEX Advisor
Export Applications to GIT

29. Demo

30. Demo

32. Thank You!