DevOps Automation

Have you ever looked at that directory? Let’s take a look at D:\tmp\AgentTesting.

The deployment_root directory is what the name suggests; it’s the root directory for files that will be deployed to this agent by its workbenches.

Mine is a single-user machine; no one else is running tests using my machine as an agent, but the deployment_root will have subdirectories correspond to each user that runs tests using this deployment directory. If sharing an agent, it’s a good idea to establish a uniformity to declaring the Deployment directory. You do not want to have to search the file system randomly when it’s time to clean up.

As people leave the organization, you should remove their respective directories. Their once-deployed test assets are of no use to anyone else.

If we drill deeper, into the JERALD.SHENGULETTE directory, we see one or more sub-directories with very long, seemingly random names.

On the workbench, navigate to Window > Preferences > Test > Server. There is a checkbox for “Delete deployment directory on the agent after execution”. That will perform the action described.

There are two reasons NOT to check this box.

1. 1)    The most significant reason is deployment time. The playback engine generally does not copy files to the agent, if the current version already exists. Copying everything to the agent every time can add a few minutes to the beginning of the schedule run.  
2. 2)    The other reason involves debugging. If you run into an issue with playback on an agent, there are log files in the “long-named” directory that can be helpful. When you automatically delete the directories, these are deleted, too.

I am a hands-on sort. I like to be directly involved in my clean-up activities. If I create an agent, I make it part of my agenda to clean up that agent periodically, usually monthly.

To summarize, cleaning the agent amounts to:

1. 1)   Making sure all users are consistent in their use of the Deployment directory on the agent.
2. 2)   Removing no-longer-valid users from the <DeploymentDirectory>\deployment_root\ directory.
3. 3)  Removing all but the newest subdirectory from <DeploymentDirectory\deployment_root\<userid>\.

Workbenches

Maintaining the sanctity of your workbench(es) is more esoteric. Sure, you want to keep track of your overall disk space and things like that, but the assumption is that you are working on your workbench. You will be more aware of those sorts of issues as part of daily business. What you might not be considering is workspace corruption.

If you use your favorite search engine to search on “What causes Eclipse workspace corruption?”, you will land upon some common reasons:

·       You ran out of memory while doing something.

·       You ran out of disk space while doing something.

·       You lost power in the middle of something.

This is not an all-inclusive list. Other, less obvious, contributing factors can be age of workspace, size of workspace, file interdependencies with a workspace; the list goes on. Some have joked that phase of the moon might be a factor.

In general, files in an Eclipse workspace have pre-defined interrelationships. Corruption is the blanket term we apply to anything that disrupts these relationships. The testing products rely upon a particularly complex web of these interrelationships.

That same search activity likely brought you in contact with a few of the recommended potential solutions for workspace corruption. We will not go into those here though they are certainly available for you to try.

Practical experience has shown that “fixing” a corrupt workspace is not as successful as replacing a workspace.

Without further ado…

• Open Eclipse, specifying a new workspace.