Master environment This environment is used for the main configuration
setup of the system. Although it does not contain any transactional data, it
is important that the master environment is managed by a very strict change
control as this environment contains production (master) setup.
Development environment This is where developers design and build
extensions and customizations. The developers are usually granted very
powerful access rights for both E-Business Suite and the operating system
that hosts the system. For instance, the developers may be granted System
Administrator or Application Developer responsibilities.
Testing environment (also known as UAT) Developers usually do not
have an APPS database schema password to this environment. This is where
users sign off on customizations and configuration changes.
Deployment environment Once the users have finished their User
Acceptance Testing on a UAT instance, patches/scripts can then be
promoted to a Deployment instance for final checks. Effectively, applying
patches on a Deployment instance is a dry run before applying code
changes to a Production instance.
Patching environment Oracle delivers their code changes, bug fixes,
and product updates through patches. The patches can be downloaded
from the Oracle Support website and applied by E-Business Suite database
administrators (Apps DBAs). Apps DBAs can use the patching environment
to perform sanity checks for patches delivered by Oracle.
Support environment If a user reports an issue on the production system, it is
a good idea to reproduce the problem on a copy of the production system. Such
copied instances are referred to as clones. The support environment is exclusive
to the support staff, where developers do not make changes directly. This
environment is usually the most frequently cloned environment in cases where
E-Business Suite implementation is running a live production instance. Frequent
cloning helps the E-Business Suite support staff to reproduce production issues.
CRP environment The conference room pilot environment is where
someone, usually an implementation team, gets buy-in to their product offering
from the wider user and business community during an implementation. This
environment is usually used for sign-off during new implementations.
Migration environment For new implementations of Oracle Applications,
developers are tasked with migration of data from the old legacy systems
into Oracle E-Business Suite. This is where repeated data migration can take
place before the migration code gets frozen and ready for user testing.
Production environment This is where the business runs its day-to-day
operations.
Generally, E-Business Suite technical developers shouldn't be too concerned
about the variety of environments, as their focus is predominantly concentrated on
the development environment. In very simple terms, the life cycle of extensions and
customization could be summarized as follows: the developer performs the
development and unit testing in the development environment, and the code gets
promoted to the testing environment. Following successful testing, the changes are
applied to the production environment.
setup of the system. Although it does not contain any transactional data, it
is important that the master environment is managed by a very strict change
control as this environment contains production (master) setup.
Development environment This is where developers design and build
extensions and customizations. The developers are usually granted very
powerful access rights for both E-Business Suite and the operating system
that hosts the system. For instance, the developers may be granted System
Administrator or Application Developer responsibilities.
Testing environment (also known as UAT) Developers usually do not
have an APPS database schema password to this environment. This is where
users sign off on customizations and configuration changes.
Deployment environment Once the users have finished their User
Acceptance Testing on a UAT instance, patches/scripts can then be
promoted to a Deployment instance for final checks. Effectively, applying
patches on a Deployment instance is a dry run before applying code
changes to a Production instance.
Patching environment Oracle delivers their code changes, bug fixes,
and product updates through patches. The patches can be downloaded
from the Oracle Support website and applied by E-Business Suite database
administrators (Apps DBAs). Apps DBAs can use the patching environment
to perform sanity checks for patches delivered by Oracle.
Support environment If a user reports an issue on the production system, it is
a good idea to reproduce the problem on a copy of the production system. Such
copied instances are referred to as clones. The support environment is exclusive
to the support staff, where developers do not make changes directly. This
environment is usually the most frequently cloned environment in cases where
E-Business Suite implementation is running a live production instance. Frequent
cloning helps the E-Business Suite support staff to reproduce production issues.
CRP environment The conference room pilot environment is where
someone, usually an implementation team, gets buy-in to their product offering
from the wider user and business community during an implementation. This
environment is usually used for sign-off during new implementations.
Migration environment For new implementations of Oracle Applications,
developers are tasked with migration of data from the old legacy systems
into Oracle E-Business Suite. This is where repeated data migration can take
place before the migration code gets frozen and ready for user testing.
Production environment This is where the business runs its day-to-day
operations.
Generally, E-Business Suite technical developers shouldn't be too concerned
about the variety of environments, as their focus is predominantly concentrated on
the development environment. In very simple terms, the life cycle of extensions and
customization could be summarized as follows: the developer performs the
development and unit testing in the development environment, and the code gets
promoted to the testing environment. Following successful testing, the changes are
applied to the production environment.
No comments:
Post a Comment