Use a New Workspace Following Product Upgrades

An effective way to minimize the potential for workspace corruption AND streamline test assets is to start with a fresh workspace after every upgrade of your DevOps Test products.  Once the new workspace is created, you can easily populate it with the assets from your previous workspace(s).

Be Aware of the Current Workspace

For most of you, when you open the tool, this dialog appears:

The key is to be aware of the path to the workspace. Ex. D:\Example\MyWorkspace

Just for some detail, this workspace was created with v10.2.1 and contains a few different projects.

The project names are a bit of a clue to what will happen to them during this process.

Each project has an assortment of tests and schedules and results and datasets, although likely nowhere near the volume that would be associated with a real test project.

Create a New Workspace

What is the best way to move forward after an upgrade? The best practice is to start with a fresh workspace. For this example, it’s an upgrade to version 10.5.1, but the steps are valid for any upgrade.

The “V10510” choice as a suffix on the workspace name provides an opportunity to visually associate workspaces with a product version. This can be important as workspaces accumulate, but naming conventions are entirely up to users to manage as appropriate for the environment at hand.

To begin, the new workspace is empty; there are no test assets to display in the Test Navigator panel.

Import the Old Project

1. File > Import
   
   
   
   
2. General > Existing Projects into Workspace
   
   
   
   
3. Click the Next button.
   
   
4. Use the Browse button to navigate to the OLD workspace directory.
   
   
   
   
   
   
   
5. Click the Select Folder button.
   
   
   
   The Projects box is populated with all the projects that exist in MyWorkspace. This is an excellent opportunity to prune older, no-longer-needed projects. Note that DiscardableProject is not selected.
   
   
6. Important: Check the box next to “Copy projects into workspace”.
   
   
   
   Doing so forces the import process to create new physical copies of the imported project and test assets and rebuilds the metadata connecting the test assets. It allows these test assets to be updated to the newer version of the DevOps Test product, while leaving your older test assets in the current state (accessible by the older version of the product should the need arise).
   
   If the box is NOT checked, no new copies are made; the new workspaces uses softlinks to the old workspace. Anything done in the new workspace will also happen in the old workspace and the old workspace will no longer be usable with the older version of the product.
   
   
7. Click the Finish button.

In the new workspace, KeeperProject has been imported.

The informational message “The workspace contains resources produced in a previous release” is expected and certainly accurate. When the “Click here” link is used, there is a period when assets are being updated; it will vary based on quantity and size of test assets. Once all assets are updated, the message will disappear.

The new workspace and imported/upgraded project are now ready for use.

A Practical Example

Recently, a customer upgraded from Rational Performance Tester v10.2.2 to DevOps Test Performance 11.0.2. That’s a sizeable jump in versions; the product releases quarterly and 10.2.2 arrived in February of 2022. They jumped right in, using their 10.2.2 workspaces and test assets with their newly installed 11.0.2. They were prompted to upgrade their test assets, as happens whenever old test assets are noticed. After the test assets were upgraded, they made an interesting discovery: they could still run all their schedules, but they could not run individual tests.  Any time they tried to run a standalone test, java crashed. That’s certainly weird behavior, so weird that upon reading the description, the support team thought, “Sounds like workspace corruption.”

Because the customer had used an old workspace and updated all the test assets therein to 11.0.2, they could not go back to 10.2.2 with that workspace. Fortunately, they had made some backups. Creating a new workspace and importing the existing projects into the new workspace corrected the issue.

Do note that your mileage may vary in terms of how a workspace corruption issue manifests itself. Rather than going on that adventure, make a new workspace.

Summary

Again, this is a best practice because it provides the greatest integrity and flexibility.

1. The new workspace is free of old, unnecessary, obsolete test assets.
2. The old workspace is unchanged and available in case there is a need to revert to the previous product version.
3. The metadata of the new workspace is freshly rebuilt, hopefully staving off any potential workspace corruption over time.