APEX Development Container

Last year I wrote the Blogpost: “How to create a Continuous Delivery Pipeline for APEX via OCCS”, now one year later, I give an Update based on the very Blogpost. 

I talked to a lot of people (not “just” APEX Developers btw) and collected Feedback on the approach described in the article. The Feedback was almost always positive, but there was one major topic always coming back up: ORCAS! 

In the container, ORCAS is responsible for export and import the Schema Objects as tables, packages, views, sequences and so on. But the critics about it is: “Sometimes ORCAS just don’t exports what I defined in SQL Developer”. I recognized this critic and worked on a solution. 

With this article, I like to inform you about the new features in the “apexdeploy”-image.

REMINDER: The Container should support you as an APEX Developer by export and deploy your APEX Application. The Container can deploy the APEX Application and schema in every target system you want, as long as the container could establish a connection to the target.

So, what is new in the apexdeploy-Image: As prequel, the name has changed. You will find the Image here: winkelsjan/apexdeploy. 

First: The new-image now comes with a precompiled ORCAS build, that increases the performance like from 3-4 Minutes per deployment down to ca. 20 seconds. 

Second: The image no longer exports the schema objects. With this, I react to the statement above: “Sometimes ORCAS just don’t export what I have defined in SQL Developer”.

 Third: Instead of exporting the schema objects, the image now creates a directory structure where you as an APEX Developer can place your SQL Code.

 

The pictures show the initial directory structure as it is generated by the first start of the container. The install.sql file already calls sql scripts like ‘packages.sql’, ‘trigger.sql’ and ‘views.sql’. You just have to place your code into the subdirectory and customize the main-script, for example packages.sql, to call your sql-file. The wercker.yml file is just needed, when you want to use wercker, to create a docker image for automatic deployment.

Now you could ask: Where’s my Application? See below.

Fourth: You can extract your APEX Application by restarting the container. You are no longer forced to “bash” into the Container and execute the Export-Script. For deploy-manual this is still the recommended way. 

HINT: create a simple bash-script to restart your container. (docker restart <containerId/Name>)

Fifth: There are updates in the Environment Variables.


Remember you need to run the image with the “-it” option to fill the other Variables as well. 

 

IMPORTANT: If you want to use your local filesystem to save the sources you need to use a shared volume. In this case the shared volume path in your container is equal to the path you declared as EXPORTPATH.

Sixth: If the container couldn’t establish a connection to the database, you will be notified about it in the docker logs.

To get started in manual deployment:

1. Set up your apex development environment
2. Create a container of the apexdeploy-image and configure it to connect to your development environment (Environment Variables: DBHOST etc.), I call it dev(elopement)-container 
3. Create a container of the apexdeploy-image and configure it to connect to your target system (test, pre-production, production), I call it deploy-container
4. Place all your sources in the directory structure the dev-container created for you. Keep in mind to customize the install.sql script for your needs
5. Export the APEX Application by restart the dev-container
6. For manual deployment, bash into the running deploy-container, switch user to ‘apple’, go to path /home/apple/<APPNAME> and execute deploy_f<APPID>.sh 

Coming article will cover the automatic deployment of APEX Applications using Oracle Cloud Services.

Until then: Stay curious! Stay connected!