Databases Reference
In-Depth Information
You might experience naming conflicts if your files are also used by APEX itself in a later release. For
example, APEX 3.0 was shipped with 18 themes included (
theme 1
…
theme 18
). You could have created
the directory
images/themes/theme 20
for your local theme. In APEX 4.0 this would cause a naming
conflict since the directory
theme 20
is now used by an internal APEX theme.
Even if you don't run into any naming conflicts, this approach is opaque and difficult to maintain.
The difficulty is identifying your files compared to the files provided by APEX itself. You need to make
sure to copy all of your files to the new directory tree once you upgrade the APEX release. Being a
manual process, this approach is inherently error prone. Also, you will have to remember that this is a
required step during an APEX upgrade; you cannot simply follow the upgrade instructions shipped with
APEX.
It is better to create a separate virtual directory to store application-specific files, for example,
/apex custom/
.
There you have subdirectories for the themes and the application-specific files. Make sure to
include all files that are required for the application. We even recommend storing a possibly shared
library like jquery multiple times in the application-specific directories, which adds transparency and a
higher level of control to the overall process. The main intention is to make it easy to move an
application from one server to another. What are the required files and libraries that you need to
propagate? Usually this is not easy to figure out.
Requirements for Designing the Server Environments
Before you can design and implement a version control strategy for team development in an APEX
project, you have to consider some important technical restrictions.
How many different server environments should you set up to support the regular development
process? You should have at least three different APEX environments for development, test, and
production. They should be installed in separate database instances (see Figure 9-3).
Figure 9-3.
The regular development instance setup
Here you can see that you propagate the changes from the development environment first to the
test environment and from there to the production environment. You do this by creating a patch script
based on the objects in the development instance (e.g., scripts for DDL, DML, and APEX application
export files). Figure 9-3 represents the flow of events; you test the application before you use it in
production. Nevertheless, for the production install you use the exact same scripts from the
development environment that you used for the test installation.
You can consolidate the environments, but at a bare minimum, the production system should be
physically separated from the development and test environments.
■
Tip
Keep the workspace name, workspace id, application id, and parsing schema identical in all the
environments.
