Test-to-Production Movement

2. Test-to-Production Movement Renga RengarajanDirector of Product Management Thomas Jose Director of Development

3. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

4. 12c Test-to-Production (T2P) Movement – Agenda • T2P Use Case • T2P Artifacts • Rewiring • T2P Flow.

5. Test to Production (T2P) Use Case User creates a test environment, installs required Fusion Middleware products, configures them and customizes various settings. User tests this environment and maybe applies a few patches. User would now like to create an equivalent production environment without going through all the different steps that were done at the test environment.

6. What is Test to Production (T2P)? • The test-to-production movement capability allows one to create a new Fusion Middleware (FMW) environment from an existing environment. • The T2P movement moves all the configuration settings, customizations and patches thereby eliminating the need to start from scratch and redo all the changes that were done at the source environment • It is a generic capability that could be used for any source to target movement such as test-to-stage, stage-to-production and production-to-test

7. How does T2P differ from full Cloning? • T2P creates a target environment that is identical to the source in terms of configuration. Specifically, it does not copy any transactional data. • Cloning, on the other hand, creates a target environment that not only carries over the configuration information from the source environment but also the transactional data. Note: Focus of this presentation is T2P.

8. T2P Automation • Implements the steps that are required to move Fusion Middleware components • Provides a uniform tooling for all Fusion Middleware components • Implements a uniform procedure and eliminates component specific steps

9. Scope of T2P Automation • Green field movement • Target FMW environment is assumed to not exist and it is created afresh from the source FMW environment • Full Movement • Everything in the source environment is moved to the target and there is no ability to “pick and choose” what is to be moved

10. T2P Characteristics • Source and target environments have to be similar. • Same Platform (Operating System) • Same architecture (32-bit/64-bit) • Target topology created is same as source topology • Target topology could be altered post T2P (such as scaling up a cluster)

11. T2P Unit of Movement • For binary movement, it is an Oracle Home • For configuration movement, it is a WebLogic Server domain (or a Standalone domain) along with all the components configured in that domain

12. Artifacts Handling in T2P Movement What is moved? • Installed binaries and patches • Configuration and metadata • WLS domain config • Configuration of all Fusion Middleware components – whether in DB schemas or file system • Metadata in MDS – such as SOA composites and non-user layer customizations (e.g., site or enterprise level ADF customizations) • Configuration of all system components • Security config such as OWSM and OPSS policies

13. Artifacts Handling in T2P Movement What is not moved? • Transactional data – these are assumed to be relevant only for the source environment • Transient data – such as job status, process status, etc. • Content data (such as UCM data, wiki pages, discussion forums, etc) – if required, one could use data movement tools • ID store (LDAP) – if required, export/import tools exist • Any config or metadata associated with individual users – users are assumed to be local to the environment and they may not be present in the target environment • User layer customizations in MDS • Config (such as HWF work group) associated with specific users

14. Rewiring in T2P – Move Plan Mechanism • Environment specific values need to be changed in T2P movement such as: • Data source definitions – need to change from source DB to target DB • Host names and port numbers • End point addresses, URLs for external services • File system location for external products • T2P uses the “Move Plan” mechanism for this • An XML file that has environment specific parameters • User edits this using any standard text editor or XML editor and supplies values that are appropriate for the target environment

15. Move Plan – XML Snippet <configProperty> <name>Url</name> <value>jdbc:oracle:thin:@dbhost:1579:d8b4lfc2</value> <itemMetadata> <dataType>STRING</dataType> <scope>READ_WRITE</scope> </itemMetadata> </configProperty> <configProperty> <name>DataSource Name</name> <value>mds-owsm</value> <itemMetadata> <dataType>STRING</dataType> <scope>READ_ONLY</scope> </itemMetadata> </configProperty> <configProperty> <name>Driver Class</name> <value>oracle.jdbc.OracleDriver</value> <itemMetadata> <dataType>STRING</dataType> <scope>READ_WRITE</scope> </itemMetadata> </configProperty>

16. High Level T2P Flow for Green Field Movement

17. T2P Flow – Binary Movement

18. T2P Flow – Config Movement

19. Sample Artifacts handled by T2P

20. Post T2P Movement Tasks • Binary and config propagation to all machines • If shared disk is not used for Middleware Home, perform pasteBinary on each of the machines to create Middleware Home locally • Use pack/unpack tools to propagate the domain config to all machines in the domain • Topology changes such as scaling up • RAC configuration

21. More Information: T2P Documentation 11.1.1.7 • Oracle® Fusion Middleware Administrator's Guide • Chapter 20: Using the Movement Scripts • Chapter 21: Moving from a Test to a Production Environment 12.1.2 • Administering Oracle Fusion Middleware • Chapter 20: Moving from a Test to a Production Environment