Ever since the concept of automation made its way to Quality Assurance and testing, things have never been the same. From improving the process to preventing ineffective and not-so-sustainable developments, automation frameworks and tools have redefined the entire scenario.
Oracle TaaS has proven to be one such revolutionary technology that has fueled all the steps of the test automation process. From efficiently delivering automation testing services through shared private cloud infrastructure to rich capabilities like web interface enabling end-to-end orchestration and self-service options, it has taken testing to another level.
Coming to the concept of Oracle Fusion Patching, the traditional Software Development Lifecycle defines Patch as a fix or a quick repair job where programming is done to overcome functionality issues, advance security, or add new features. Since software throughout its lifetime encounters various issues or bugs creating unexpected results, a patch provides an immediate fix to all those concerns.
Oracle Patching is therefore can be defined as the process of applying modifications to the Oracle Fusion Applications Environment. Patching is usually required to overcome security threats, enhance performance, error-fixing, and sustainable implementation of any new features. Continuous patch application allows preventing incidents of any bug encounters and thus aids the instance of Oracle Fusion Application for efficient performance and improved security.
Since BugRaptors aims to deliver maximum value to the idea of Quality Revolution within the existing digital transformation landscape, this blog will aim at underlining Oracle Fusion Patching and Testing Readiness.
Oracle Fusion Patch Categories
Before we dig into the details of understanding Oracle Fusion Patching, we must begin with the knowledge of Fusion Patch Categories. Broadly categorising, it can be divided into two main categories called Functional Patches and Technical Patches. While the functional patches are meant to work on the addition of new and fixing of existing functionalities within fusion apps, the technical patches are used to work on the addition of new and fixing of existing technical capabilities associated with fusion middleware components where the fusion app exists.
To mention more clearly, the functional and technical patches could be listed as:
Functional Patches: One-off Patch, Aggregated One-off patches (AOO), & Bundle Patches (PB)
Technical Patches: One-off Patch, Critical Patch Update (CPU), Batch Bundle (P4FA)
Oracle Fusion Patching Tools
Depending on the category and type of patch, different tools are used for application. And before we jump on learning which Patching category requires what tool to lead the implementation, let us quickly run through understanding the available tools for their function and purpose.
OPatch: OPatch is a utility tool that is made to simplify the process of applying or rolling back the patches to Oracle’s software.
FASPOT: FASPOT is another important tool made to simplify the installation of P4FA bundle patches and comes with guided preparation steps to streamline the application of bundle patches.
To highlight, here are the categories for which FASPOT can be used to apply patches:
-
Fusion Middleware Components like atgpf, BI, ECM, ODI, Oracle Common, SES, SOA webtier, wls, & WebCenter.
-
Access Management (including OHS & OID) and Identity Management
As far as the RDBMS patch is concerned, FASTPOT does not support the installation and thus needs manual installation through Database Administration (DBAs).
Oracle Fusion Application Patch Manager: Simply called Patch Manager, this tool is meant to support the application of functional standard patches and bundle patches. It not only allows validation of the patches for their application but even aids to justify whether a patching report can be generated or not. Patch Manager has a command-line interface that assists in systemizing the patching functions.
With a brief idea of the motivation and purpose behind the Fusion Patching tools, let us quickly jump to learning which tools are suitable to use for which patch categories:
For Technical Patches:
OPatch can be used to implement both Technical One-Off and Critical Patch Updates (CPU). However, the Technical Patch Bundle (P4FA) needs FASPOT under the P4FA section to meet the implementation goals.
For Functional Patches:
As described in the Apply One-Off Patches section, Fusion Applications Patch Manager could aid the application of a Functional One-Off Patch. However, to Apply a Functional Patch Bundle section, the Functional Patch Bundle (BP) is used. Coming to the Aggregated One-Off patch, Fusion Applications Patch Manager can be used to meet the implementation goals.
Planning Patching Activity For Oracle Fusion Applications Environment
Once you have the right team with you to foster your Oracle Fusion patching initiative, it is necessary that you must take every right step to streamline the task. It can be a team of expert ISTQB certified QA testers or Oracle Fusion experts who can then aim for the following steps:
-
Patch Planning
-
Define Patching Tools
-
System Backup Planning
-
Patch Impact Analysis
-
Patch Test Planning
When Patches Must Be Applied?
For Technical Patches
-
One-Offs: Only applied for critical issues. Otherwise, it is recommended to wait for patch bundle releases
-
Aggregated one-offs (AOO): Not Applicable
-
CPU: Immediately applied upon release
-
Patch Bundles: In the ideal situation, it is applied every month as it is recommended to apply less frequently than every month.
For Functional Patches
-
One-Offs: Only applicable for critical issues. Else it is recommended to wait for the patch bundle release.
-
Aggregated one-offs (AOO): Only applied when project timelines are affected. Otherwise, the team should wait for the updated bundle
-
CPU: Not applicable
-
Patch Bundles: Applied monthly upon release or is done alternately based on the project requirements.
Wondering why cloud testing is essential for Digital Transforamtion Goals?
Read our blog: Cloud Testing for Digital Transformation
Oracle Cloud Fusion Patching: Best Practices & Guidelines
Most digital entities these days are quickly adopting the cloud to run their operations and administration. And therefore, Oracle Fusion has placed itself so well in the market that it has become one of the primary choices for big and mid-sized enterprises. To keep up with the varying needs of the market, Oracle pushes new software and hardware updates every quarter which can be chosen based on Opt-in or Opt-out options.
Coming back to patching, is a process of modifying Oracle Cloud Applications with new functionalities, UI changes, customer enhancement requests, and bug fixes. And since most of these updates are necessary, testing is required to ensure that all the functionalities align well with operations. Moreover, testing even allows checking on the BAUs for any impact that rolling updates have caused.
Therefore, enterprise clients need to consider complete testing of the software to analyze the implementation for any issues for a given period of time as Oracle opens the testing window for a limited period of 2 weeks.
And if you have the chance to foster testing, there are a few fundamentals that must be kept in check for effective outcomes:
-
Quarterly Release Schedule: To know the patch release date for quarterly patch testing
-
To Know What’s New: The next thing that you need to check is the Oracle Cloud Readiness website to have a clear idea of available new features and capabilities. This helps you process timely checks on the required features and have early access to important dates that might help improve the test cycle.
-
Opt-in Expiration: To have insights of features falling under Opt-in extension to plan to test for the existing or upcoming quarterly update.
-
Test Case Readiness: This includes planning on common test cases for every patch, having an understanding of features and capabilities that come with a particular quarterly patch, & to check for test cases that are made to work at features that are automatically migrated to production from existing releases.
-
Quarterly Patch Application: A quarterly patch is implemented in the non-production instance before it is moved to production. Thus, it is vital that all the test cases are executed within the given two-week window before the patch is applied to the PROD instance. And even if the patch gets applied to PROD, all the test cases must deliver positive results. For failure, the tester should raise Oracle SR while putting the PROD patch of the application on hold.
Good Luck!
Need help implementing an Oracle Fusion Patch? Struggling to keep up with the pace of testing within the limited two-week window? Our experts at BugRaptors could help you keep things in check.
For any information or queries, reach us through info@bugraptors.com
