In this section:

Introduction

Environment Manager is an interface in Parasoft Continuous Testing Platform (CTP) for rapidly configuring and provisioning instances of your test environments. The Environment Manager Plugin for Jenkins enables you configure various actions needed for automated, continuous testing across your software delivery pipeline. You can configure build steps for:

• Provisioning environments into the specific states needed for automated testing.
• Replicating environments and associated assets to different Virtualize servers, including servers provisioned dynamically from Docker or other container technologies.
• Executing Parasoft test scenario jobs (tests suites that execute vs. specific environment configurations).
• Destroying "dirtied" test environments to ensure that subsequent tests always begin with a clean slate.
• Disconnecting a Virtualize server from CTP to remove unnecessary connections.
• Publishing test execution results to Parasoft DTP.

Requirements

• CTP 2.7.4 or higher
• Virtualize 9.9.4 or higher
• Jenkins 1.625.3 or higher
• JUnit Plugin v.1.10
• DTP 5.4.0 or higher (for publishing test execution XML report to DTP) 
• DTP 5.4.2 or higher (for publishing test execution environment information to DTP) 

Configuration

Each Jenkins server communicates with one instance of CTP, but multiple Jenkins servers can communicate with the same instance of CTP.

1. Go to Manage Jenkins > Configure System.
2. In the Parasoft Environment Manager area, enter your Environment Manager URL, username, and password. You can click Test Connection to ensure that Jenkins is successfully communicating with Environment Manager.
   
3. If you want to add a build step to publish test execution results to DTP, specify the URL, username, and password for your DTP server in the Parasoft DTP section.
    

Adding an Environment Manager Build Step to a Job

You can add any number of Environment Manager build steps to a Jenkins job.

1. Open the job you want to configure and choose Configure.
2. In the Build area, click Add build step and select one of the available Parasoft Environment Manager build steps:

Configuring a Deploy an Environment Build Step

This build step provisions environments into the specific states needed for testing. As an additional option, it can also replicate environments and associated assets to different Virtualize servers (including servers provisioned dynamically from Docker or other container technologies). When you add a "Deploy an environment" build step, several new fields are available.

To configure this build step:

1. Choose a system, environment, and instance you want to provision (and optionally replicate to a new Virtualize server) from the respective menus.
2. If you want to replicate the environment and associated assets (virtual assets, proxies, JDBC controllers, and so on) to a new Virtualize server before provisioning:
   1. Enable Copy the environment and assets before provisioning.
   2. (Optional) Specify a name for the new environment. If this field is empty, a name will be assigned automatically. You can also use variables, for example, Env${BUILD_NUMBER}
   3. Specify the target Virtualize server. See the guidelines below this procedure for help selecting and configuring one of the available options.
3. If you are copying an environment and you also want to duplicate the associated data repositories before provisioning:
   1. Enable Duplicate associated data repositories before provisioning.

   2. Specify where you want the data repositories to be copied. You can configure the following options:
      
      

      On the current Data Repository server	Creates a new copy on the same Data Repository server where the repositories currently exist. If you select this option, specify the Data Repository port, username, and password.
      To a Data Repository server on the same host as the target Virtualize sever	Creates a new copy on the target Virtualize server specified in the area above the Duplicate associated data repositories before provisioning option. If you select this option, specify the Data Repository port, username, and password.
      To a Data Repository server on a specific host	Creates a new copy on the specified Data Repository. If you select this option, specify the Data Repository host, port, username, and password.

4. If you want the job to stop if the provisioning fails, enable Abort on provisioning failure.

Choosing Between the Various Environment Copying Options

This plugin provides three different environment copying options to suit various needs. The first option requires the Virtualize server to be registered with Environment Manager when the job executes. The second and third will wait for the Virtualize server to be registered and is thus the preferred option when you're dynamically deploying Virtualize servers via Docker or other container technologies.

When Virtualize Server has a Dynamic IP

As long as the Virtualize server has a consistent name, you can configure the build step to copy to the Virtualize server with the specified name (for example, the name it uses to register with Environment Manager). If the named Virtualize server is not yet registered with Environment Manager, the build step will wait for it, then perform the copy operation once that server is registered.

Configuring an Execute a Test Scenario Job Build Step

This build step executes one of the test scenario jobs (tests suites that execute vs. specific environment configurations) available on the connected instance of Environment Manager. You can also publish the test execution results to DTP.

You can configure the following options:

• Enable By name to specify the name of a test scenario or From list and choose a test scenario from the menu. If By name is enabled, you can use a Jenkins environment variable, for example, ${JOB_NAME}, to use the same name as the Jenkins job.
• By default, Abort the build on test failure is disabled. Enable this option if you want to stop the build if a test fails.
• Enable Abort the build if it's stuck and specify the number of minutes in the Timeout minutes field that Jenkins should wait before the job times out.
• Enable Publish test execution results to DTP and specify the DTP project, build ID, and session tag if want to be able to view the results in DTP.
• Enable Append variable set environment to session tag if configured if you want to include the execution environment setting (exec.env) in the test results when SOAtest publishes to DTP. This enables you to aggregate test data according to execution environment, which can be displayed in DTP widgets and reports, for example:
  
  Refer to the DTP documentation for additional information about projects, build IDs, session tags, and other metadata associated with test and development artifacts.

Configuring a Destroy an Environment Build Step

This build step deletes "dirtied" test environments to ensure that subsequent tests always begin with a "clean" test environment. When you add a "Destroy an environment" build step, two new fields will appear.

To configure this build step:

1. Choose the system from the System menu that includes the environment you want to destroy.
2. Enter the name of the environment you want to destroy. You can enter the name of an environment that does not exist yet (for example, an environment that will be spun up dynamically). You can also use variables, for example, Env${BUILD_NUMBER}

Configuring a Disconnect a Virtualize Server Build Step

This build step de-registers a specified Virtualize server from Environment Manager. When you add a "Disconnect a Virtualize server" build step, two new fields will appear.

Enable one of the options and specify the host IP or server name in the field provided to disconnect a Virtualize server.

Reviewing a Build Step's Progress and Results

To view the console output for an in-progress job, click the progress bar in the Build History area. This opens a page with status details and links to the associated Environment Manager host and environments. To see details on a completed job, use the Console Output pull-down in the Build History area.

Change Log