APEX Version Control & Team Working

I recently had the pleasure of presenting at UKOUG TECH16 last December. It was, as always, a fantastic experience to be able to meet APEX developers and to hear the latest about the APEX 5.1 new features.

My presentation was entitled “APEX Version Control & Team Working” – a topic which has become a key interest of mine over much of last year. This presentation being a culmination of research and ideas pooled in to a 50-minute talk.

As we all know; APEX is a wonderful rapid application development environment allowing PL/SQL developers to build professional looking production ready applications. Over time, your APEX application will increase in size, complexity and will be adopted by a wider user base. That user base will request more and more features and you may notice a growing demand for live support. To support your users your team will need to expand. Your development team will need skills in PL/SQL, (and to some extent) CSS and JavaScript. You may also need a UI Developer or perhaps an Integration specialist. Above all you need to standardise how developers operate within a development team.

Over the years, developers of PL/SQL, Oracle Forms and other file based programming languages have benefitted from version control software. Its adoption has great benefits for the team and for exercising control over the whole application development lifecycle. We have taken for granted terms like Branching, Merging, Commits and Pulls as version control software is custom made for file based languages.

Oracle APEX however, unlike file based languages, stores all application definitions inside the Oracle Database as meta-data (visible in the data dictionary). Therefore, each time a developer clicks “Save” in Page Designer, they are making modifications to the underlying Meta-Data and not to physical source files.
Instead of checking out page components through your version control software, APEX provides a multiple developer interface and it’s this flexibility which is a proven enabler for rapid maintenance and creation of data centric applications.

So far – we’ve just read of the benefits of using version control software to manage software development. We’ve also read about the flexibility of APEX providing a multi developer environment. The question is now how can we successfully integrate SVN, git, CVS or any of the many other version control software applications with Oracle APEX.

The quick answer is: You have to adapt your development flow to APEX rather than trying to fit APEX in to an existing process.

Within my consultant role at Explorer, I encounter many companies; some just starting out in APEX and some with much more mature development practices. In this presentation, I draw from this experience and describe some of the better methods I’d encountered whilst also mentioning case studies and blogs found across the internet.

At Explorer we’ve assessed many tools which accompany the development process and we have favoured some for APEX development over others. The Oracle Developer Cloud Service (ODCS) for example provides a hub for Source Control Management together with Issue Tracking which allows development tasks/defects to be monitored. It also provides a Continuous Integration facility (for testing releases) and a Wiki.

Another notable tool is the Team Development feature within APEX which allows Milestones, Features and Tasks to be created to support the development lifecycle. This tool is used by the APEX Team for management of new versions of APEX and it also has the unique feature of being able to highlight Features, To-Dos, Bugs or Feedback Entries directly in page designer.
At Explorer we make use of these types of tools for multi developer application development and task management. We primarily use git as our version control software and exercise many of the APEX collaborative working features such as named developers, build options, page locking, etc.

Before I move on to the details of the team working features, it’s worth talking a little about environments.

Ultimately you are going to need to test your application before it reaches production. The amount of test phases is up to you. Build, Staging, System Test, UAT, pen-test, pre-prod… to name just a few, and it’s up to you what you decide. The recommendation here is to use separate environments, whether these are physical, virtual or PDBs it doesn’t matter.

Your development instance has most likely the “Full Development Environment” configuration of APEX installed; meaning you have access to the APEX login screen, Internal Workspace, Page Designer etc. Your non-development environments are more likely to have the “Read Only” environment installed which means you’ll need to install APEX applications at the command line. To do this I prefer to import the workspace which I’ve exported from development (without any developer users) this way I can avoid the use of APEX_APPLICATION_INSTALL. This technique is also excellent if your DBA or Release Controller (or better still your automated Continuous Integration Build Agent) performs application releases through the command line.

When it comes to multiple developers working on an application or suite of applications. APEX supports this and even on the same page at the same time! – a warning appears if two developers change the same component/attribute. The video goes in to more detail however in summary the following features are mentioned:

• Page Locking
• Build Options & Conditional Compilation
• Consider multiple applications for applications over 50 pages
• Subscribe from a Master Application
• Use Team Development
• Frequently Backup your applications
• Consider Continual Integration & Automated Testing Tools

When it comes to releasing; separation of database components (packages, scripts, etc.) from your APEX Applications is key here and avoid the use of supporting objects for in-house applications. Always exporting your application from development and always releasing from version control. Master scripts can simplify things here tremendously.
Managing concurrent projects, phases or deliverables whilst also supporting production – or even multiple site installations, each with different versions – can be addressed by use of Build Options or Parallel Development techniques. Build Options are simple switches which are extremely beneficial to APEX application development.

A Build Option is assigned a:

• Name – so it can be identified when assigning it to an APEX component.
• Status – which controls which APEX components are included or excluded at run-time.
• Default on Export – which reassigns the “Status” flag when the application is Exported.

For example; I can assign a Build Option (Status=Include & Default on Export=Exclude) to a new feature I’m working on. However, when that same application is exported for a hotfix, the status is automatically changed to Exclude. This results in the hotfix being applied to production but the work-in-progress feature is not present at run-time.

The video discusses several ways of exporting and importing your applications; all of which have their strengths and some things to be aware about.

You can watch the YouTube video presentation in the link above or if you are attending DOAG APEX Connect then you can see me present an updated version of this presentation at on 11th May 2017 1:30pm in Music Hall 2.

Author: Matt Mulvaney

Job Title: Senior Oracle APEX Development Consultant

Bio: Matt is an experienced APEX solution designer having designed numerous complex systems using a broad range of Oracle Technologies. Building on his previous experience of Oracle Forms & PL/SQL, he is entirely focused on providing functionally rich APEX solutions. Matt promotes APEX as a software platform and openly shares best practises, techniques & approaches. Matt has a passion for excellence and enjoys producing high quality software solutions which provide a real business benefit.