Databases Reference
In-Depth Information
Figure 9-5.
Consolidating the environments
Regular Development/Test
: On this machine both the regular development
environment and the test environment are installed. It is important that the
application id (e.g.,
100
) of the development version matches the application id in
production. The parsing schema for the development environment (e.g.,
FM
) is also
identical to the production environment. The application will be made available to
the test team on the development server, only in a different database schema (e.g.,
FM TEST
) using the application id
200
. Once tested, the development version is
installed in production.
Hotfix Development/Test
: This environment works analogously to the regular
test/development environment, only that it is used for hotfix development and
testing production issues.
Production
: This is the regular production environment.
If you implemented the setup as suggested, you might still have to find a way to deal with different
configuration settings on the application server side for the development and test environments. For
example, suppose you are using css, image, and Javascript files to support the application, and the
Javascript file
script1.js
needs to be modified. You need to be able to modify this file while the same file
remains unchanged for the version in the test environment (application id
200
).
The easiest and most flexible approach is to store these files within the APEX workspace. You can
upload the files to the workspace (to be referenced in the application as
#WORKSPACE IMAGES#script1.js#
) or to each application in the workspace individually (to be referenced
in the application as
#APP IMAGES#script1.js#
). The latter approach allows you to have two different
versions of
script1.js
within the same workspace.
Nevertheless, there are at least two good reasons to store the files on the HTTP server. If you have
many concurrent users accessing the application, your performance will suffer and you should avoid
