FlexDeploy doesn't perform any automated tests directly. This job is delegated to the great number of various testing frameworks. FlexDeploy orchestrates the testing process by performing two primary functions:
- Execute tests
- Import test results
The integration with 3rd party testing tools is implemented by the use of plugins. If FlexDeploy doesn't provide a plugin for some testing tool out-of-the-box then the Shell plugin can be used instead. It allows to execute batch scripts in order to interact with the testing tool. The plugins act as adaptors for various testing tools. They command testing tools to run tests and they import test results into unified test result storage. This allows users to analyze test results using the dashboard reports, abstracting away from the exact testing tool.
Viewing Testing Tools
To view the list of testing types defined within FlexDeploy, select Administration -> Test Automation -> Testing Tools from the menu.
Figure 17.54
Creating/Editing Testing Tools
To create a testing tool click the Create button. To edit a testing tool, select an existing testing tool and click the Edit button.
Figure 17.55
Enter values for the following fields:
Field Name |
Required |
Description |
Id |
N/A |
System generated identifier (read-only). |
Name |
Yes |
Name for the testing tool. |
Figure 17.56
It is also possible to define a set of properties for the testing tool. Values of the testing tool properties are going to be set up at the testing instance. This is useful for testing tools like OATS or Load Runner when there is a dedicated instance of the testing tool working on a separate server.
Figure 17.57
Click the Save button to save the changes to the testing tool and return to the list of FlexDeploy testing tools.
Issue Tracking Systems
The Issue Tracking System page, which can be accessed through the Administration menu, allows management of integrations into third-party issue tracking systems. FlexDeploy currently provides outbound integration with Atlassian Jira.
To configure the Jira issue tracking system, select Jira and click the Edit button.
Figure 17.58
You can provide global customizations for the Jira integration here, or override the settings at the project level. The customizations available are as follows.
Field Name |
Required |
Description |
Id |
Yes |
System generated identifier (read-only). |
Name |
Yes |
Name of the issue tracking system (read-only). |
Description |
No |
Description of the issue tracking system. |
Ticket Number Pattern |
No |
Pattern of the issues within the issue tracking system, used to associate FlexDeploy builds with particular issue(s). If not specified here, the pattern will need to be defined on each project which associates to your issue tracking system. For Jira, the pattern of tickets is the key is the Jira project Key, followed by a dash (e.g. "MYPROJ-"). All tickets created for this project are prefixed by this key, making it the pattern. |
Update Tickets on Build |
No |
Check this box if you want to globally update any tickets associated to FlexDeploy builds. Can be overridden at project level. |
Build Update Comment Pattern |
No |
Applicable only if Update Tickets on Build is checked. The value of this property is a groovy script which evaluates to the comment you wish to update associated tickets with when a build completes successfully. Groovy variables available to the script are provided in the (x=) dropdown to the right. Can be overridden at project level. |
Update Ticket Status on Build |
No |
Applicable only if Update Tickets on Build is checked. Check this box if you want to globally update the status of any tickets associated to FlexDeploy builds. Can be overridden at project level. |
To (Build) |
No |
Applicable only if Update Ticket Status on Build is checked. Any associated ticket will be updated to this status whenever the build completes successfully. Can be overridden at project level. |
Update Tickets on Deploy |
|
Check this box if you want to globally update any tickets associated to FlexDeploy deployments. Can be overridden at project level. |
Deploy Update Comment Pattern |
|
Applicable only if Update Tickets on Deploy is checked. The value of this property is a groovy script which evaluates to the comment you wish to update associated tickets with when a deployment completes successfully. Groovy variables available to the script are provided in the (x=) dropdown to the right. Can be overridden at project level. |
Update Ticket Status on Deploy |
|
Applicable only if Update Tickets on Deploy is checked. Check this box if you want to globally update the status of any tickets associated to FlexDeploy builds when they are deployed. Can be overridden at project level. |
To (Deploy) |
|
Applicable only if Update Ticket Status on Deploy is checked. Any associated ticket will be updated to this status whenever the deployment completes successfully. Can be overridden at project level. |
Figure 17.59
Issue Tracking System properties provide the definition of configuration parameters that are required to integrate with that system. Values for these properties will be provided when Issue Tracking System Instances associated with the system (e.g. Jira) are configured in the FlexDeploy topology. See the Topology section of this guide for more information.
Figure 17.60
Issue Tracking System statuses identify the statuses within your Jira system, and allows FlexDeploy to update your issues to those values at build or deployment time. You will add the statuses from the Jira workflow(s) associated to your Jira project(s). Click the 
and 
buttons to add or remove statuses from the list.
Figure 17.61
To identify the statuses to add, from within your Jira system as seen in Figure 17.62, view the workflow(s) associated to your Jira project(s). Switching to the Text view of the workflow editor/viewer you can identify the workflow statuses and transition ids.
Figure 17.62
It is critical that the ids entered match the transition ids within your Jira workflows, otherwise, FlexDeploy will be unable provide the desired updates.
Click the Save button to apply any updates.
Resource Types
Resource types provide the ability to designate an endpoint to be of a specific type of server. Once the resource types are created and associated to an endpoint, they can be utilized on script based plugins (Shell, Windows Shell, Groovy,…) to direct workflow activity to endpoints that match the requested resource type.
Resource types can be accessed through the Administration menu.
Figure 17.63
The resource types listed above are pre-defined resource types by the WebLogic and EBS plugins and can't be modified.