Understanding the Deployment Process

24.2 Understanding the Deployment Process

Learn about different approaches and best practices when deploying applications.

About Suggested Environments
Learn about the best practices in development, testing, and production environments.
Deployment Scenarios to Consider
Review common deployment scenarios for APEX applications.

Parent topic: Deploying an Application

24.2.1 About Suggested Environments

Learn about the best practices in development, testing, and production environments.

Oracle recommends developers follow standard system development life cycle practices when developing applications by having three environments: development, testing, and production. As a best practice, developers should only make changes to applications and related database objects in their development environment. To further enforce this policy Oracle recommends using a runtime environment for both testing and production environments. This approach will prohibit developers from accessing the App Builder and SQL Workshop in these environments. As a general rule, your administrators (DBAs) should be the only ones with permission to update the test and production environments. DBAs should use the appropriate provided APIs and import applications from a SQL interface, such as SQL*Plus or Oracle SQL Developer Command Line.

24.2.2 Deployment Scenarios to Consider

Review common deployment scenarios for APEX applications.

When you develop an application, you create the application within a specific workspace. Each workspace has a unique ID and name. A common scenario is to create the application in a development instance and then deploy it to a production instance.

Deployment options to consider include:

Use the same workspace and same schema. Export and then import the application and install it using a different application ID. This approach works well when there are few changes to the underlying objects, but frequent changes to the application functionality.
Use a different workspace and same schema. Export and then import the application into a different workspace. This is an effective way to prevent a production application from being modified by developers.
Use a different workspace and different schema. Export and then import the application into a different workspace and install it so that it uses a different schema. This new schema needs to have the database objects required by your application.
Use a different database with all its variations. Export and then import the application into a different APEX instance and install it using a different workspace, schema, and database.

Whether to Copy the Workspace

Deciding whether to copy an existing workspace is a matter of preference. Keep in mind that the production version must have access to all the appropriate objects. For example, you might want to copy a workspace in the following situations:

When you want to keep the same application identifiers between development and other environments.
When the application relies on APEX authentication. Copying the workspace automatically migrates all the required user data.

Whether to Copy the Database

When deciding whether to copy the database, remember that the schema against which the application runs must have access to the same objects as the development instance. The actual name of the schema is unimportant. You can change it during the import process.

About the Application ID

It is not necessary to have matching application IDs for a development version and production version of an application. In fact, as a best practice, never hard code the application ID into your application. Instead, use the application alias (defined on the Edit Application page), or use a built-in substitution string (such as APP_ID and APP_ALIAS). Using a substitution string is the better approach because it enables you to change the application ID without affecting any application functionality.