Wednesday, 21 December 2016

Phased APEX migrations

While looking through the comments regarding 5.1 features it occured to me how many different ways the Oracle APEX team enable us to phase our applications into any new APEX version, thereby minimising risk and introducing new IDE features to developers earlier.

I've always thought APEX does a really good job of leaving our applications alone during upgrades. It normally depends on how much the boundaries have been pushed, and how much the theme has been modified, or templates added. In fact, most of the work is in upgrading the theme, which is why the Universal Theme came about.

So that that masterpiece may start the list:
  1. Universal Theme
    Designed to remove need to migrate themes in future. Instead, theme templates re-subscribed on demand as long as you kept your theme locked to the repository.
  2. Compatibility mode
    A relict from Oracle Forms, this feature allows you to prepare your app for behavioural changes between APEX versions. This great write up from Carsten describes how asynchronous developments in 5.1 may apply to your applications.
    Check this setting on any applications borne out of earlier APEX versions.
  3. jQuery MigrateTo keep libraries lean, older functions are removed over time. Older references can sustained until they're refactored, as described by Marko.
  4. Utilities -> Upgrade Application
    APEX will leave deprecated features alone, until you're ready to upgrade each instance. The classic example is the old datepicker from 3.1. All your items called the horrible window until you replaced them all. This feature makes this process quicker and this older reference from Dimitri still applies. I may translate my mentioned of it in this presentation (as it applies to charts) to a blog post.
  5. Multiple concurrent versionsIt's not here year, but 5.2 may see the introduction of the ability to run two different APEX versions on the same database instance.
  6. apex.oracle.com
    This will always be a sandbox for the latest version or patch, so why not try your applications out in there? You can script up your tables, generate some data and import your app. Start preparing now and see how much your application won't break.
    Let's not forget apexea.oracle.com, when the latest major release is in early adopter mode.
If you can think of any others, let me know and I'll add them to the list.

Or do you have any stories of nasty surprises? I haven't heard of too many serious issues with APEX upgrades.

Edit:


#letswreckthistogether

4 comments:

Mathieu said...

Another consideration is when you use a plugin in your application and in the new APEX version the same functionality is replaced by a built-in.
Do you replace the plugin or keep using it?

For instance in APEX 4.2 we used the Skillbuilder modal page plugin.
In APEX 5.0 this had to be replaced by the APEX modal page built-in.
It took some effort to replace it in our applications. But it was worthwhile.

Scott Wesley said...

That's a very good point, Mathieu.
We had the opportunity to cease all development in anything non-UT, and just use declarative where possible.

I wonder if all the notification plugins will fade away with the APIs available in 5.1

Vladimir said...

Dear Scott. Have you tried to run your experiment application "APEX releases" within APEX 5.1? Does it run without any change of the source code according to your book? Thank in advance.

Scott Wesley said...

Hi Vladimir,
My example at https://apex.oracle.com/pls/apex/f?p=73000:28 still works fine, and I have not changed my sample application at all, despite it desperately needing attention.

I couldn't imagine why there would be an issue.

I should also work that into a plugin...