This README.md serves as temporary documentation for the WebLogic Deploy Tooling-Continuous Testing (WDT-CT) project. It is targeted at developers, and covers all the topics you need to be aware of when building and installing it, plus how to run the smoke tests that are included in the WDT-CT installer .zip file.
The WDT-CT is essentially an extension of the WDT, which provides the functionality for creating and running different types of tests (e.g. smoke, system, integration, regression, what-if, etc.) on the WDT components (create, discover, deploy).
As implied by its name, the WDT-CT is an approach for doing continuous testing on the components of the WDT.
The WDT-CT differs from the system tests subsystem for testing the A2C components, in several ways:
- It is mostly written in Python as opposed to Java, and runs on the Python/Jython interpreter used for running WLST scripts.
- It only uses Maven to create the WDT-CT installer
.zipfile. - It uses metadata models (metamodels) to define the test definition types (e.g. smoke, system, integration, etc.). These metamodels govern the settings and stages (e.g. discrete actions) used for a given test definition type.
- It uses Wercker to orchestrate the steps for a test. How it does this will be described in detail, later in this document.
placeholder-paragraph
The WDT-CT provides a system-test test definition type for creating A2C-style system tests, like singleApplicationTest. The key difference is that there is no need for a Java or Python class named singleApplicationTest, because the test definition file contains all the data (or pointers to it) needed to run the test. This includes ENVVAR aliases, source and target domain settings, as well as @@PROP:xxx@@ expressions for substitution variables defined in an overrides .properties file.
The similarities are in what happens when a test is run using the singleApplicationTest[.json|.yml] test definition file:
- placeholder-item
- placeholder-item
- placeholder-item
placeholder-paragraph
The source code and test definition files used in the WDT-CT project, are in the following private GitHub repository:
https://github.com/wercker/weblogic-deploy-tooling-ct
If you don't have access to it, please send an e-mail to Derek Sharpe requesting access.
As mentioned earlier, the WDT-CT is an extension of the WDT.
com.oracle.weblogic.lifecycle:weblogic-deploy-core is the Maven identifier for WDT, so at build-time, WDT-CT uses com.oracle.weblogic.lifecycle:weblogic-deploy-core:[0.10) in the applicable <dependency> elements of it's pom.xml files. This works fine for compiling the Java code, but assembling the installer zip requires that the actual .py files from that Maven identifier, be included as part of the zip. This means that the WDT-CT installer .zip file contains everything needed to install and run the WDT-CT, as well as the WDT.
Doing a mvn clean install inside the WDT-CT's project directory, should result in the following installer .zip file being generated:
$REPO_DIR/installer/target/weblogic-deploy-tooling-ct-installer.zip
Again, that installer .zip file includes all the files you'd find in the WDT installer .zip, plus the ones for the WDT-CT.
The weblogic-deploy-tooling-ct-installer.zip contains the weblogic-deploy-core.jar and weblogic-deploy-tooling-ct-core.jar files, in the lib directory. Both are added to the CLASSPATH environment variable used when running WLST, so it is able to resolve all run-time references to Java classes and resources inside those two .jar files. The .py files are not in those two .jar files, so WLST must read them from the $INSTALL_DIR/lib/python directory.
See "Special Note About the $REPO_DIR/.mvn/config" for specifics.
You need to have Apache Maven 3.3+ installed in order to build the installer .zip for the WDT-CT. Afterwards, just open a command prompt, change directory to where you did the git checkout to, and type in the following:
mvn clean install
This should result in the $REPO_DIR/installer/target/weblogic-deploy-tooling-ct-installer.zip file being generated.
To install the WDT-CT, you just need to unzip the weblogic-deploy-tooling-ct-installer.zip file into a directory, on a host where Oracle WebLogic Server is already installed. This host can be a local machine, local VM, docker image or an OCI compute instance.
WDT-CT runs on the Python/Jython interpreter that comes with that Oracle WebLogic Server install, so the WDT-CT will need to be told the values of the following environment variables, from that:
| OS Env Variable | Remarks |
|---|---|
| ORACLE_HOME | If the host is a docker image, you can use a docker inspect command to get the value from the docker images .Config.Env area. There is a get-docker-config-info.sh shell script in the weblogic-deploy-tooling-docker project, which contains a function to get the value of ORACLE_HOME from this .Config.Env area. |
| JAVA_HOME | If the host is a docker image, you can use a docker inspect command to get the value from the docker images .Config.Env area. There is a get-docker-config-info.sh shell script in the weblogic-deploy-tooling-docker project, which contains a function to get the value of JAVA_HOME from this .Config.Env area. |
The WDT-CT is used to perform an aspect of DevOps referred to as continuous testing. Continuous testing is an activity that plays a key role in achieving continuous integration, which is another aspect of DevOps.
As the name implies, continuous testing is an activity that involves performing tests on a code base, to ensure it is ready to be used to create a release...at anytime...not just at the end of a sprint.
The test being performed are generally triggered by an event in the code repository, like a push or pull request. When this occurs, a web hook configured in the repository triggers some type of technology that can manage the execution of the test, and report the test results.
The following table presents the technologies used to implement the WDT-CT, and the role each plays:
| Technology | Remarks |
|---|---|
| Docker | The Oracle WebLogic Server installs that are used when running a test, are containers created from docker images. These docker containers provide the execution environment for the tests.
They are built and managed by members of the WDT development team, and stored in a private container registry on GitLab. |
| Git Hub | For the WDT-CT, the code repository is |
| Wercker | The GitHub web hooks trigger Wercker pipelines, which have steps to:
|
| Hudson | placeholder-paragraph |
Once the WDT-CT is installed, you can execute a "smoke test" to ensure it is ready to be used, from a Wercker pipeline step. You'll find the smoke tests in the following directory:
$WDTCT_HOME/testing/smoke_tests/certified
The default overrides file for all the smoke tests is in the directory above that:
$WDTCT_HOME/testing/smoke_tests/default-smoke-test-overrides.properties
Edit the values assigned to entries in that file, to match where Oracle WebLogic Server and the JDK are installed. The OOTB smoke test test definition files use this properties file, so pay careful attention to where you say things are. Once you've finished editing and saving the file, you should be ready to run a smoke test.
| IMPORTANT: | Remember to change the paths for the model, archive or variable files cited in the |
Let's start by opening a terminal and running a smoke test using the create-smoke-test.json test definition file:
$ WDTCT_HOME=<path to where you unzipped the installer.zip>
$ cd $WDTCT_HOME
$ bin/runTest.sh -test_type system-test -test_def_file testing/smoke_test/certified/create-smoke-test.json -test_def_overrides_file testing/smoke_test/default-smoke-test-overrides.properties -oracle_home <path to where Oracle WebLogic Server is installed>
The smoke test will send output to the terminal, and create log files in the $WDTCT_HOME/logs directory.
The $WDTCT_HOME/bin/runTest[.cmd|.sh] script is the executable used to run a WDT-CT test. It supports the following command-line options:
This is the directory where Oracle WebLogic Server has been installed. It is a required option.
This identifies the "type" of test to run. Specify one of the following as the option value:
smoke-testsystem-testintegration-test
This is a required option.
NOTE: This WIP release is only implementing the functionality associated with the smoke-test and system-test choices.
This is the path to the test definition file to use for the test. It is a required option.
This is the path to a .properties file that contains property names used in test_def_file. It is only required if test_def_file contains @@PROP:xxx@@ expressions.
This is the name of a test definition file verifier to use. A verifier ensures that test_def_file conforms to the test definition metadata file associated with it. If not present, a built-in verifier will be is used.
NOTE: This WIP release will only be using the built-in verifier.
This is the path to a test definition metadata file to associate with the test_def_file file. If not present, the test definition metadata file inside $WDTCT_HOME/lib/weblogic-deploy-tooling-ct-core.jar file will be used.
Flag indicating to only perform the test definition verification step(s). If not present, the verification and test steps will be performed.
| Command-Line Option | Remarks |
|---|---|
-oracle_home |
|
-test_type |
|
-test_def_file |
|
-test_def_overrides_file |
|
-test_def_verifier_name |
|
-test_def_metadata_file |
|
-verify_only |
placeholder-paragraph
placeholder-paragraph
placeholder-paragraph
placeholder-paragraph
//TODO: Continue working on this README.md, after we get more of the Wercker pieces in place and able to run a smoke test.