APEX Application Lifecycle and Deployment 20220714.pdf
0 likes38 views
The presentation by Richard Martens outlines a feature-based deployment strategy for Apex applications, emphasizing easy deployment, modular development, and a standardized workflow for database management. It introduces tools like Flyway for version control of database objects, Git for branching strategies, and details the deployment process across various environments. Key challenges include managing simultaneous developments and ensuring thorough integration testing before production deployment.
APEX Application Lifecycle and Deployment 20220714.pdf
- 1. APEX Application Lifecycle with feature based deployment
- 2. I am Richard Martens Welcome to this presentation. You can find me at ◉ @rhjmartens ◉ smart4solutions.nl/blog Hello!
- 3. The world according to SMART4Solutions
- 4. Agenda • Objectives • Requirements • Development Methodology • Solution • Branching Strategies • Workflow • Project Folder Structure • Deployment • Assumptions • Challenges
- 5. Objectives What are we trying to achieve? 1
- 6. “ Our customers expect and need a way to deploy an APEX application based on a single feature Objectives
- 7. “ Easy deployment throughout the application lifecycle Objectives
- 8. “ Development of new features may not be stopped Objectives
- 9. Objectives ◉ Our customers expect and need a way to deploy an APEX application based on a single feature ◉ Easy deployment throughout the application lifecycle ◉ Development of new features may not be stopped
- 10. Requirements What conditions must be met? 1
- 11. Requirements • No dependency on specific project-management tools ○ Jira, Wrike, MS-Project ○ Confluence, Sharepoint ○ Bitbucket, Gitlab, Github • Using our standard development methodology • 1 core schema ■ for data and business-rules • 1 apex schema ○ for APEX specific views and packages ■ This is the schema our APEX workspace looks at also known as “parsing schema” • Optional a VPD layer or other “external” schemas involved • DB deployment-tool using regular SQL / Command scripts that every DB developer understands (learning curve)
- 13. Standard infrastructure • The basic idea ○ APEX does not “touch” tables directly ○ A view / package for each individual APEX page ○ A view / package for each individual REST module • We pushed it a bit further ○ A view for each individual region ○ LOV’s compilable in the database! ○ Naming standards for objects: ■ prefix_app_page_description_suffix ○ UI and Business should not be mingled, Modularising code ○ Enforces the question: what is business logic, what is not
- 14. Standard infrastructure dev CORE-schema (s4sbo_core_dev) ORDS Reverse Proxy static project files static APEX files (/i) other (s4sbo_other_dev) other (s4sbo_other_dev) APEX-schema (s4sbo_apex_dev) Each new interface gets its own schema APEX-schema (s4sbo_apex_dev)
- 15. Standard infrastructure tst CORE-schema (s4sbo_core_tst) ORDS Reverse Proxy other (s4sbo_other_tst) other (s4sbo_other_tst) APEX-schema (s4sbo_apex_tst) Each new interface gets its own schema static project files static APEX files (/i)
- 16. Standard infrastructure prd CORE-schema (s4sbo_core_prd) ORDS Reverse Proxy other (s4sbo_other_prd) other (s4sbo_other_prd) APEX-schema (s4sbo_apex_prd) Each new interface gets its own schema static project files static APEX files (/i)
- 18. Introducing Flyway CE Flyway run 1. Scan folder- structure 2. Execute Versioned files by version increment (ie alphabetically) 3. Execute Repeatable files alphabetically
- 20. Project Folder Structure • Each db-object deserves a file ○ Separate package (or type) spec and body ○ Project dependant (ie indexes at table creation) • Predefined structure • Naming method for Flyway ○ R__xxx ○ VYYYYMMDDHHMI__xxx • We’re not using an “install_all” script ! 20
- 21. Flyway at work • Flyway CE § only allows “.sql” file-extensions § No SQL*Plus commands • “prep4flyway.sh” renames all files § Extensions to “.sql” § Prefixes files according to folder-number § Enforces order of spec and body • Flyway only sees the renamed files
- 22. • We can now build all our DB objects • What do we feed Flyway to get a proper builds ? • Introducing: GIT and branching Flyway at work
- 25. Branching Strategies main hotfix acceptance develop feature 1 feature 2 test S4S-FLOW
- 27. Deploy DB Objects • We’re now able to deploy a specific branch • Including all DB-objects • Including data • The deployment contains the features that were merged into the build branches (Test, Acc, Prod) • What is missing?
- 28. Integrating APEX into the build • A special component-export application
- 29. Integrating APEX into the build • The generated ZIP contains an installer for the exported components
- 30. Integrating APEX into the build • The developer unzips the ZIP into the GIT-branch • f100.zip unpacks in f100 folder § Mac users need a tool to merge folders • Application folder contains entire application but only exported files are “new” • The included installer cannot be used • Extra build-step: “create_cmp_install.sh” § Generates a new application-installer • Extra build-step to deploy static files (*.js, *.png etc)
- 31. Deployment • The deployment process is as follows (DTAP) § D for Docker, an environment that gets reset (to the latest production version) before each build § Because we build all environments automatically we have tested our deployment-scripts 3! Times by the time we deploy to production 1. Checkout the branch 2. Start “prep4flyway” script for CORE (1st) and APEX (2nd) schema 3. Copy static files (rsync) 4. Start “create_cmp_install” script for each application (D & T) 5. Invoke flyway for CORE (first) and APEX (second) schema 1. Uses callbacks to check for invalids, invalids break the build! 6. Start the generated install script from step 4 (D & T) otherwise full-app install 7. Full App export (T) 8. Place full-app export on the Test Branch GIT Checkout Start Docker APEX Deploy APEX Export DB Deploy A DB Deploy C Commit & Push prep4 flyway copy static files Create CMP Install
- 32. Team 2 Team 2 The deployment street Integration deploy (dev) TEST deploy ACC deploy PROD deploy Team 1 Team 2 1 2 3 4 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 MAIN branch
- 33. Team 2 Team 2 2 a The deployment street Integration deploy (dev) TEST deploy ACC deploy PROD deploy Team 1 Team 2 1 2 3 4 1 a 1. Feature branch merged into DEV branch a. Feature merged into DEV brach (REVIEW) After it was built in docker and reviewed 2.DEV branch merged into TEST branch a. Full application export pushed into TEST and DEV branch 3.TEST branch merged into ACC branch 4.ACC branch merged into MAIN branch
- 35. • Create Feature Branch (FB) • Lock page before start • Save changes on the Feature Branch (DB / APEX) • Push to Remote Feature Branch • Build Docker instance to test integration • Check work on Docker instance • Create Merge Request § Is review step by colleague / QA • Unlock page when merged into Development Branch Working Flow
- 36. Ready!
- 38. Assumptions • We don’t use the built-in static menu-list in our applications § Overcome by using build-options • NEVER EVER touch a versioned file after it has been merged into DEV branch • Btw, never ever touch a versioned file after it has been merged into DEV branch!!
- 40. Challenges • A shared development instance § Simultaneous development on single Database objects • Corrections for versioned files should go in a new versioned file • Commits and Merges preferably on the local filesystem push as late as possible • Get to know your tools § IDE (PL/SQL Developer) § Gitkraken / Sourcetree / Fork / Tower / TortoiseGit • Get to know your process § Git for teams
- 41. Recap • All software is stored in the GIT repository • A proven branching strategy • Standard directory structure • Deployment-tools are stored inside the repo • Tools used § A ticket system (Jira/Wrike etc) § A GIT server (Bitbucket/Gitlab/Github etc) § A GIT Client (any will do) § IDEs for PL/SQL and CSS, images Javascript etc. § Flyway Community Edition
- 42. 42 Any questions ? You can find me at ◉ @rhjmartens ◉ [email protected] Thanks!