About the Application Lifecycle with Oracle WebLogic Server for OKE

Learn about deploying and managing applications for a domain that was created with Oracle WebLogic Server for OKE.

A common practice is to create separate Oracle WebLogic Server domains to support development, testing, and production. A traditional development workflow typically includes the following tasks:

1. Update the development domain, including patches, data sources, and applications.
2. Apply the same changes to the test domain. You might use a combination of OPatch, the WebLogic Server administration console, and the WebLogic Scripting Tool (WLST).
3. After testing, apply the same changes to the production domain using the same tools.

Oracle WebLogic Server for OKE promotes a different workflow based on the principles of Continuous Integration and Continuous Delivery (CI/CD).

When you create a domain with Oracle WebLogic Server for OKE, all of the files that are required to run your domain in Kubernetes (binaries, patches, configuration, applications, and so on) are stored in the Docker image for your domain. If you want to change the domain, you must update the Docker image. Any temporary changes you make to the running domain will be lost if you restart the pods in the Kubernetes cluster.

Oracle WebLogic Server for OKE deploys Jenkins to the Kubernetes cluster along with your domain, and configures a sample project in Jenkins to implement the recommended development workflow. This workflow includes the following tasks:

1. Update domain image with applications, resources, libraries, WebLogic patches, JDK updates.
2. Build a test domain with the updated domain image and then validate the test domain.
3. Apply the updated domain image to replace the current domain and then validate the domain.
4. If applying update domain image to the current running domain fails, then it automatically rolls back to the previous working domain image.

With this approach, you can easily share the latest domain with your entire development team, and also ensure that everyone uses a consistent configuration. You also don't need to manually replicate changes in different environments, like testing and production.

You can customize the sample Jenkins project to meet your specific CI/CD requirements.