Release Command Center dashboard

22 minute readData analytics

The Release Command Center dashboard provides a “birds-eye” view of a single product or release across all of its phases. These phases include initial planning with tools (such as JIRA or Rally) to groom the backlog, target stories, and tasks. The dashboard displays the high-level metrics for release activities such as release planning, continuous integrations, and deployments to various environments. It combines the release data in CloudBees Software Delivery Automation with data that it can pull from various external tools.

This dashboard includes metrics for application deployments and independent (project-level) microservice deployments. (It does not include metrics for microservices within applications.)

Following is a typical example of the dashboard. This example is for a release that is in progress with no major issues:

Figure 1. Release command center

Following is a typical example for a release that is in progress but has issues with deployments. In this example, the Deploy cell is colored red, which indicates that too many deployments are failing in the last 10 days for the release to proceed satisfactorily:

Figure 2. Release command center with issues

Filters

The Release Command Center dashboard provides several filters to customize the view:

Figure 3. Release Command Center filters

1

Select the desired release for which data is presented.

2

Additional filters to refine the data.

3

The beginning date for which metrics are shown.

4

Additional parameters to refine the data. Out of the box, Time Slice is available. This is the number of days relative to the Show as of date used to calculate the relative date range for reporting the release metrics. Defaults to 10 days.

Metrics

Figure 4. Release Command Center metrics
  • Release Plan Metric

    This metric displays the percentage of release stories that are complete. The percentage is calculated using the latest feature data associated with the release for type story. Records with status closed are considered to be completed. This metric includes a trend indicator arrow, which shows the general direction of an already-formed trend. This metric uses the underlying Release Plan Completed widget.

  • Open Defects Metric

    This metric displays the number of open defects for the release. The open defects are calculated using the latest defect data associated with the release. Records with a resolution that is either not set or empty are considered as open. This metric also includes a trend indicator arrow, which shows the general direction of an already-formed trend. This metric uses the underlying Open Defects In Release widget.

  • Days to Delivery Metric

    This metric displays the number of days remaining in the release. This metric uses the underlying Days Remaining in the Release widget.

Columns and Cells

Each column displays a particular category of metrics. This lets you estimate the work in terms of story points or time all the way through deploying and running in production. Data is presented at the following levels:

  • Column (such as Dev, Build, or Test)

  • Column level summary (measures in upward or downward trends)

  • Column level details

    The color thresholds are defined for the column summary widgets for the Planning, Dev, Build, Test , and Deploy columns. By default, the thresholds are the same based on the percentage value displayed for their corresponding widgets:

    • Less than 50%: Red

    • Between 50 and 75%: Yellow

    • Between 75 and 90%: Blue

    • 90% or greater: Green

Below is a list of each column with a description of each cell in that column.

Drilling down into columns

Drill-down lets you take a closer look at the data in the Release Command Center dashboard. You can drill down by clicking on widgets in each of the columns.

Depending on the widget, drill-down will take you to the source of the metrics being displayed, which can either be an external system such as JIRA or ServiceNow or CloudBees Software Delivery Automation itself. Drill-down details are provided below.

Planning phase

WidgetDescription

Percentage Of Stories With Story Points

Percentage of release stories that have story points assigned. This metric includes a trend indicator arrow, which shows the general direction of an already-formed trend.

Total Stories

Total count of release stories.

Estimated Stories

Total count of release stories with story points.

The planning phase metrics are collected from systems such as JIRA or Rally. Pre-configured support for collecting data for CloudBees Analytics to visualize through the Release Command Center is provided for JIRA software using the EC-JIRA plugin. Clicking any cell (widget) in this column where the data for the metrics to display came from JIRA opens JIRA.

Dev column

WidgetDescription

Percentage Of Dev Complete Stories

Percentage of release stories that have exited development.

Dev Completed or Resolved Stories

Percentage of release stories that are development complete.

Unit Test Success Rate

Percentage of successful unit tests out of the total unit tests run through CI builds for the release in the selected date range (the last 10 days by default).

The Dev column metrics are collected from systems such as JIRA or Rally. Pre-configured support for collecting data for CloudBees Analytics to visualize through the Release Command Center is provided for JIRA software using the EC-JIRA plugin.

Build column

WidgetDescription

Build Success Rate

Percentage of successful builds out of the total builds for the release in the selected date range (the last 10 days by default). This metric includes a trend indicator arrow, which shows the general direction of an already-formed trend.

Total Successful Builds

Number of successful builds out of the total builds for the release in the selected date range (the last 10 days by default).

Average Build Duration

Average time taken by builds associated with the current release to complete in the selected date range (the last 10 days by default).

The Build column metrics are collected from systems such as Jenkins. Pre-configured support for collecting data for CloudBees Analytics to visualize through the Release Command Center is provided for Jenkins using the EC-Jenkins plugin.

Test column

WidgetDescription

System Test Success Rate

Percentage of successful tests out of the total tests that were run for the release in the selected date range (the last 10 days by default). This metric includes a trend indicator arrow, which shows the general direction of an already-formed trend.

System Test Automation Percentage

Percentage of automated tests out of total tests that ran for the release.

Average System Test Duration

Average test duration in the selected date range (the last 10 days by default).

Drill-down in the Test column collects data from a plugin such as EC-ALM. Clicking any cell in this column opens HP ALM in a browser window, from which you can drill down for more information.

Deploy column

WidgetDescription

Deployment Success Rate

Deployment success rate in the selected date range (the last 10 days by default).

Total Application Successful Deployments

Number of successful application deployments out of the total completed deployments in the selected date range (the last 10 days by default).

Total Successful Service Deployments

Number of successful microservice deployments out of the total completed deployments in the selected date range (the last 10 days by default).

Average Deployment Durations

Average deployment duration in the selected date range (the last 10 days by default).

Clicking to drill down into Successful Application Deployments opens the Application Deployments page, which shows application deployments for the selected release. Note that you can also open the Application Deployments page by clicking Applications > Application Deployments from the Home menu.

Following is an example of the Application Deployments page when opened from the Release Command Center:

Figure 5. Application deployments page

This is a page that is filtered by successful deployments for the selected application. You can filter the list of deployments according to status by using the filter buttons.

Following are the available filters.

All deployments

Running deployments (gray highlighting)

Successful deployments (green highlighting)

Deployments that stopped because of one or more errors (red highlighting)

Deployments that finished with one or more warnings (yellow highlighting)

Aborted deployments (gray highlighting)

For example, you can view only the successful deployments by clicking the Successful button:

To view the details of a deployment, click the deployment, which opens the Applications / View Run page. For more information, see Deploying and Troubleshooting Applications.

Clicking to drill down into Successful Microservice Deployments opens the Microservice Deployments page, which shows independent (project-level) microservice deployments for the selected release. Note that you can also open the Microservice Deployments page by clicking Microservices > Microservice Deployments from the Home menu.

The filter buttons for microservice deployments work in a manner similar to the filter buttons for application deployments as described above.

Feature Flags column

You must have a CloudBees Feature Management license in order to source feature flag data. Refer to About feature flags for further information about CloudBees Feature Management.

The Feature Flags column shows metrics associated with feature flags configured for the current release. The CloudBees Software Delivery Automation EC-FeatureFlags plugin sources data from CloudBees Feature Management, which in turn supplies data to widgets in this column. You configure the desired set of feature flags for your CloudBees Software Delivery Automation release from CloudBees Feature Management.

WidgetDescription

Total number of flags that are in this release

The number of updated flags based on the Show as of date and the Time Slice parameter.

Number of flags with targeting enabled

Number of flags with targeting enabled, updated during the time period, based on the Show as of date and the Time Slice parameter.

Average time slice flag creation

Average time since flag creation, updated during the time period, based on the Show as of date and the Time Slice parameter.

Operate column

The Operate column shows incident metrics associated with the deployed release (post-production). This column collects data periodically from incident management system such as ServiceNow. See Setting Up the Release Command Center Dashboard for details on setting up data sources to collect data from systems such as ServiceNow for the Release Command Center.

WidgetDescription

Total Incidents

Total number of incidents opened against the release.

Resolved Incidents

Number of resolved incidents out of total incidents for the release.

Average Resolution Time

Average time to resolve an incident for the release.

You can drill down into this column. Clicking the Total Incidents cell in this column opens a ServiceNow page that lists all incidents associated with the release. For example:

Figure 6. An example of a ServiceNow page when clicking the Total Incidents cell.

Clicking the Resolved Incidents cell or the Average Time to Resolve cell in this column opens a ServiceNow page that lists all resolved incidents associated with the release. For example:

Figure 7. An example of ServiceNow page after clicking the Resolved incidents cell.

Accessing the Release Command Center dashboard

The Release Command Center dashboard is available from CloudBees Analytics:

  1. From the CloudBees navigation, select CloudBees Analytics.

  2. From the main menu, go to Analytics Dashboards. The dashboard list displays.

  3. Select Release Command Center from the dashboard list.

Changing the effective date and relative date range

By default, the Release Command Center dashboard displays the release metrics as of the current day and uses a date range (a time slice) of the last 10 days.

You can change the effective date and date range to view a relevant timeline of your choice to see more meaningful, historical data. For example, you can:

  • Change the Show as of date to compare a 10-days-ago snapshot of the dashboard with a 20-days-ago snapshot to analyze the progression of the release.

  • Set a 14-day time slice to see the information for an entire two-week sprint.

  • Compare a currently-running release to the last release that was completed a month ago.

Changing the effective dates

  • To change the Show as of parameter, click Show as of and choose a new date from the calendar that appears.

  • To change the time slice parameter, click the Choose parameters button and enter a positive integer for the number of days to use as the time slice in the dialog box that appears:

Setting Up the Release Command Center dashboard

The Release Command Center dashboard shows release data that it collects and aggregates for tools such as JIRA and Jenkins. When you first view the dashboard for a release, each cell contains a message indicating that there is no data to display (except that you might see data in the Deploy column if you are already using CloudBees Software Delivery Automation itself as your deployment tool).

You can set up the Release Command Center by adding data sources for different external tools that you are using in your release. The supported tools are based on the installed plugins that support collecting data for the Release Command Center to send to the CloudBees Analytics server. As installed, the following external tools are supported for the Release Command Center:

Source typeSupported external tool

User Stories

JIRA

Continuous Integration

Jenkins

Test Automation

HP ALM

Defects

JIRA

Deployment Automation

None. (Deployment automation is done by CloudBees Software Delivery Automation so no additional setup is required for it for the Release Command Center. CloudBees Software Delivery Automation automatically sends deployment data for the release to the CloudBees Analytics server)

Incident Management

ServiceNow

Release Orchestration

None (Release Orchestration is done by CloudBees Software Delivery Automation so no additional setup is required for it for the Release Command Center. CloudBees Software Delivery Automation automatically sends deployment data for the release to the CloudBees Analytics server)

Feature Flags

CloudBees Feature Management

Support for a tool, such as Rally or Team City, that is not already supported by the Release Command Center can be added using a plugin that can collect data from the third party tool and send it to the CloudBees Analytics server.

Copying data sources to populate the dashboard

When you create a new release, often the configurations for the release command center will be very similar to the previous release, with minor updates to the filters and searches that you are using. To avoid time repeating the configuration steps when you create a new release, you can copy the configurations to data sources for the Release Command Center dashboard from an existing release, rather than creating a new setup from scratch. This feature lets release managers set up their Release Command Center dashboards more easily.

  1. Select Release Orchestration Releases. The Releases listing page appears.

  2. Select New Release. The New Release from Existing dialog box appears.

  3. Select the Copy Data Source checkbox and then select OK.

    When you check this checkbox, you are asked to copy data sources from the existing release to the newly copied release on the next screen.

    Note that if this checkbox is grayed-out, data sources do not exist for the release that you are copying:

  4. Click Copy for a data source in the Copy Data Sources dialog box.

  5. Select Close.

    The data sources are now available for adding to the Release Command Center dashboard.

Adding data sources to populate the dashboard

CloudBees Software Delivery Automation supports several data sources that you can select to collect data periodically from external tools and to send it to the CloudBees Analytics server for displaying in the Release Command Center dashboard.

To add a data source:

  • From within the Release Command Center dashboard, click Dashboard Editor. The Release Command Center dashboard editor appears.

  • Click Setup. The Command Center Setup dialog box appears.

    This dialog box shows every available data source type (such as User Stories). Also, for each data source type, it shows the source, the list of widgets (such as Assigned Story Points or Total Stories) that correspond to that data source type and the group or column to which each widget belongs (such as Planning or Dev).

  • Click Add to add a data source for the data type of your choice for the current release. The Source Configuration dialog box appears:

  • Select a data source from the Select Data Source pull-down menu. The fields that are relevant to the specific data source that you selected will appear in the dialog box.

  • Complete the parameter values for the data source that you selected. For details about these values, see Entering Parameter Values for Data Sources .

  • Click Close. The new data source appears in the Command Center Setup dialog box.

    After closing the dialog box, you will see the icon for the data source type displayed on the widgets for the newly-added data source.

Entering parameter values for data sources

The Release Command Center dashboard provides the following data source types. The following table lists these data source types and the data sources that you must configure to collect data for each cell.

Data source typeDescriptionTool(s)Type(s) of data collectedFor details, see…

User stories

Application lifecycle management products used to manage enhancements, user stories, features, epics, and so on

JIRA

Feature (JIRA stories)

Defect (JIRA defects)

Continuous integration

Products used for continuous integration, unit test execution, and so on

Jenkins

Build (Jenkins builds)

Test automation

Test automation products

HP ALM

Quality (test runs from HP ALM)

Deployment automation

Products used for application, artifact, or container deployments

CloudBees Software Delivery Automation

Feature flags

Feature flag management

CloudBees Feature Management

Feature flag configuration

Incident management

Incident management products

ServiceNow

Incident (ServiceNow incidents)

Defects

Application lifecycle management products used to manage defects

JIRA

Defect (JIRA defects)

Parameters for user story data sources

ParameterRequiredDescription

Type

Yes

Type of data source. This parameter is pre-selected and “grayed out” if you are adding a data source from the Widgets tab of the Command Center Setup dialog box.

Source

Yes

Actual source of the data.

Source Name

Yes

Name of the data source. This name must be unique within the release.

Configuration Name

Yes

Name of the JIRA plugin configuration to use. This plugin configuration is created if it does not exist, and you must complete the following fields in the dialog box that appears.

  • Configuration —Unique name for the plugin configuration

  • (Optional) Description —Description of the plugin configuration

  • URL —URL to use to connect to a JIRA server. For example, https://10.10.10.10:8080 or https://myJIRAserver

  • Auth Type —Type of authorization to use: None, Basic (the default), or OAuth 1.0

  • Login as —User name and password to use to connect to the specified JIRA URL. For OAuth, use the OAuth token as the username and a private key (in PEM or DER format) as the password

  • (Optional) Log Level —Debug level for logs. For Info (the default), only summary information is logged. For Debug, debug information is logged. For Trace, entire requests and responses are logged

  • (Optional) Check Connection? —If checked (the default), the credentials are checked before the configuration is saved

  • (Optional) HTTP Proxy —Proxy to use for connections

  • (Optional) Proxy Authorization —Username and password for the proxy

Filter Type

Yes

Type of JIRA filter used to identify issues in the release. You can specify JIRA fields or a JIRA query (in JQL).

JIRA Project

No

(When filtering by JIRA field) The JIRA project key that identifies the project in JIRA.

JIRA Fix Version

No

(When filtering by JIRA field) The fix version in JIRA that identifies the JIRA issues of type “bug” that are part of the release.

JIRA Query (JQL)

No

(When filtering by JIRA query) JQL to use to search issues. Either this parameter or “JIRA filter ID” must be specified. For example, project = MYPROJ and issuetype = Bug will retrieve all bugs for the specified project.

For information about using JQL, see https://support.atlassian.com.

Polling Frequency

Yes

(When filtering by JIRA query) JQL to use to search issues. Either this parameter or “JIRA filter ID” must be specified. For example, project = MYPROJ and issuetype = Bug will retrieve all bugs for the specified project.

For information about using JQL, see https://support.atlassian.com.

As part of the data source creation, a schedule is created in the same project as the release that runs at the specified polling frequency to get the user stories from JIRA based on the parameters specified in the data source and send it to the CloudBees Analytics server. The schedule is named using the format releasename _ datasourcetype _ uniqueid .

Parameters for continuous integration data sources
ParameterRequiredDescription

Type

Yes

Type of data source. This parameter is pre-selected and “grayed out” if you are adding a data source from the Widgets tab of the Command Center Setup dialog box.

Source

Yes

Actual source of the data.

Source Name

Yes

Name of the data source. This name must be unique within the release.

Continuous Integration Schedule Project Name

Yes

(When using CloudBees Software Delivery Automation as the data source) Name of the project containing the continuous integration schedule that is associated with the release.

Continuous Integration Schedule Name

Yes

(When using CloudBees Software Delivery Automation as the data source) Name of the continuous integration schedule that is associated with the release.

Configuration Name

Yes

(When using Jenkins as the data source) Name of the Jenkins plugin configuration to use. This plugin configuration is created if it does not exist, and you must complete the following fields in the dialog box that appears.

  • Configuration —Unique name for the plugin configuration

  • (Optional) Description —Description of the plugin configuration

  • URL —URL to use to connect to a JIRA server. For example, https://10.10.10.10:8080 or https://myJIRAserver

  • Auth Type —Type of authorization to use: None, Basic (the default), or OAuth 1.0

  • Login as —User name and password to use to connect to the specified JIRA URL. For OAuth, use the OAuth token as the username and a private key (in PEM or DER format) as the password

  • (Optional) Log Level —Debug level for logs. For Info (the default), only summary information is logged. For Debug, debug information is logged. For Trace, entire requests and responses are logged

  • (Optional) Check Connection? —If checked (the default), the credentials are checked before the configuration is saved

  • (Optional) HTTP Proxy —Proxy to use for connections

  • (Optional) Proxy Authorization —Username and password for the proxy

Jenkins Project

Yes

(When using Jenkins as the data source) Name of the Jenkins project that does continuous integration builds for the release.

Test Results URL

No

(When using Jenkins as the data source) Relative URL for retrieving test results from the Jenkins build. If this is not set, then test data is not retrieved. The default is /testReport.

Polling Frequency

Yes

(When using Jenkins as the data source) (When filtering by JIRA query) JQL to use to search issues. Either this parameter or “JIRA filter ID” must be specified. For example, project = MYPROJ and issuetype = Bug will retrieve all bugs for the specified project.

For information about using JQL, see https://support.atlassian.com.

As part of the data source creation, a schedule is created in the same project as the release that runs at the specified polling frequency to get the builds from Jenkins based on the Jenkins project specified in the data source and send it to the CloudBees Analytics server. The schedule is named using the format releasename _ datasourcetype _ uniqueid.

Parameters for test automation data sources

ParameterRequiredDescription

Type

Yes

Type of data source. This parameter is pre-selected and “grayed out” if you are adding a data source from the Widgets tab of the Command Center Setup dialog box.

Source

Yes

Actual source of the data.

Source Name

Yes

Name of the data source. This name must be unique within the release.

Configuration Name

Yes

Name of the ALM plugin configuration to use. This plugin configuration is created if it does not exist, and you must complete the following fields in the dialog box that appears.

  • Configuration —Unique name for the plugin configuration

  • (Optional) Description —Description of the plugin configuration

  • URL —URL to use to connect to a JIRA server. For example, https://10.10.10.10:8080 or https://myJIRAserver

  • Auth Type —Type of authorization to use: None, Basic (the default), or OAuth 1.0

  • Login as —User name and password to use to connect to the specified JIRA URL. For OAuth, use the OAuth token as the username and a private key (in PEM or DER format) as the password

  • (Optional) Log Level —Debug level for logs. For Info (the default), only summary information is logged. For Debug, debug information is logged. For Trace, entire requests and responses are logged

  • (Optional) Check Connection? —If checked (the default), the credentials are checked before the configuration is saved

  • (Optional) HTTP Proxy —Proxy to use for connections

  • (Optional) Proxy Authorization —Username and password for the proxy

HP ALM Server Timezone

No

Timezone offset for the HP ALM server. 0000 is the default and stands for GMT. This is used for converting datetime fields retrieved from the HP ALM server to UTC before sending them to the CloudBees Analytics server.

HP ALM Filter

No

Filter to retrieve test runs. For information about HP ALM filters, see https://admhelp.microfocus.com/alm/en/12.60/online_help/Content/Resources/_TopNav/_TopNav_Home.htm .

Polling Frequency

Yes

(When filtering by JIRA query) JQL to use to search issues. Either this parameter or “JIRA filter ID” must be specified. For example, project = MYPROJ and issuetype = Bug will retrieve all bugs for the specified project.

For information about using JQL, see https://support.atlassian.com.

As part of the data source creation, a schedule is created in the same project as the release that runs at the specified polling frequency to get the system test results from HP ALM based on the parameters specified in the data source and send it to the CloudBees Analytics server. The schedule is named using the format releasename _ datasourcetype _ uniqueid .

Parameters for feature flags

Sourcing data from CloudBees Feature Management requires a CloudBees Feature Management license.

Some items for the CloudBees Analytics feature flags data source configuration come from your CloudBees Feature Management application.

Figure 8. CloudBees Feature Management application UI
  1. Access CloudBees Feature Management.

  2. In the left navigation panel, select the current application.

  3. In the dialog that opens, select the desired application from the dropdown list.

  4. To the left of your screen, in the navigation panel, select App Settings Integrations.

From the Integrations tab, locate and note the following two items. They are used in the data source configuration in CloudBees Analytics:

  • User Token

  • Application ID

In the CloudBees Analytics data source configuration dialog, complete the configuration by entering values listed in the table below.

ParameterRequiredDescription

Type

Yes

The type of data source. This parameter is pre-selected and grayed out if you are adding a data source from the Widgets tab of the Command Center Setup dialog box.

Source

Yes

The actual source of the data. Select FeatureFlags from the dropdown list.

Source Name

Yes

The name of the data source. This name must be unique within the release and is pre-populated with FeatureFlags.

Configuration Name

Yes

The name of the configuration created in CloudBees Software Delivery Automation to access CloudBees Feature Management. Choose a configuration from the dropdown list, or create a new one:

  • Name: Enter a user-defined name for this configuration.

  • Project: Select a CloudBees Software Delivery Automation project from the dropdown list.

  • Description: Enter a user-supplied description.

  • Autofill from existing configuration: Ff checked, select a configuration from the dropdown.

  • Runtime Credential: Enter the User Token required to connect to the CloudBees Feature Management instance. From CloudBees Feature Management:

  • Debug Level: Ses the debug level for logs:

    • Info: Summary information

    • Debug: Limited debug information

    • Trace: All requests and responses

Application Id

Yes

The CloudBees Feature Management application id for the app from which flags are retrieved. From CloudBees Feature Management:

Environment Name

Yes

The application environment from which flags are retrieved. From CloudBees Feature Management:

  1. To the left of your screen, in the navigation panel, open Flags in environments.

  2. Copy an environment from the environment list.

Filter by flag name

No

A regular expression used to filter feature flag names. Default is no filter.

Filter by flag label

No

A regular expression used to filter feature flag labels. Default is no filter.

Metadata property path

No

The CloudBees Software Delivery Automation property sheet where run metadata is stored. If omitted, /mySchedule/EC-FeatureFlags-%JobName%-%Report Object Type% is used for the schedule context. For all other contexts, property sheet root is /myProject.

Polling Frequency

No

The polling frequency (in minutes) for retrieving flag information from your CloudBees Feature Management application. If not specified, 30 is used.

Parameters for incident management data sources

ParameterRequiredDescription

Type

Yes

Type of data source. This parameter is pre-selected and “grayed out” if you are adding a data source from the Widgets tab of the Command Center Setup dialog box.

Source

Yes

Actual source of the data.

Source Name

Yes

Name of the data source. This name must be unique within the release.

Configuration Name

Yes

Name of the ServiceNow plugin configuration to use. This plugin configuration is created if it does not exist, and you must complete the following fields in the dialog box that appears.

  • Configuration —Unique name for the plugin configuration

  • (Optional) Description —Description of the plugin configuration

  • URL —URL to use to connect to a JIRA server. For example, https://10.10.10.10:8080 or https://myJIRAserver

  • Auth Type —Type of authorization to use: None, Basic (the default), or OAuth 1.0

  • Login as —User name and password to use to connect to the specified JIRA URL. For OAuth, use the OAuth token as the username and a private key (in PEM or DER format) as the password

  • (Optional) Log Level —Debug level for logs. For Info (the default), only summary information is logged. For Debug, debug information is logged. For Trace, entire requests and responses are logged

  • (Optional) Check Connection? —If checked (the default), the credentials are checked before the configuration is saved

  • (Optional) HTTP Proxy —Proxy to use for connections

  • (Optional) Proxy Authorization —Username and password for the proxy

ServiceNow Source Table

Yes

ServiceNow source table. Set this to incident to retrieve updated incidents from ServiceNow.

ServiceNow Filter

No

Filter in ServiceNow encoded query string format. For information about ServiceNow encoded query string format, see https://docs.servicenow.com/bundle/helsinki-platform-user-interface/page/use/using-lists/concept/c_EncodedQueryStrings.html.

Polling Frequency

Yes

(When filtering by JIRA query) JQL to use to search issues. Either this parameter or “JIRA filter ID” must be specified. For example, project = MYPROJ and issuetype = Bug will retrieve all bugs for the specified project.

For information about using JQL, see https://support.atlassian.com.

As part of the data source creation, a schedule is created in the same project as the release that runs at the specified polling frequency to get the incidents from ServiceNow based on the parameters specified in the data source and send it to the CloudBees Analytics server. The schedule is named using the format releasename _ datasourcetype _ uniqueid .

Parameters for defect data sources

This type of data source creates a schedule that runs periodically to retrieve updated defects from JIRA and send the data to the CloudBees Analytics server. This occurs via the sendReportingData Perl API command.

ParameterRequiredDescription

Type

Yes

Type of data source. This parameter is pre-selected and “grayed out” if you are adding a data source from the Widgets tab of the Command Center Setup dialog box.

Source

Yes

Actual source of the data.

Source Name

Yes

Name of the data source. This name must be unique within the release.

Configuration Name

Yes

Name of the JIRA plugin configuration to use. This plugin configuration is created if it does not exist, and you must complete the following fields in the dialog box that appears.

  • Configuration —Unique name for the plugin configuration

  • (Optional) Description —Description of the plugin configuration

  • URL —URL to use to connect to a JIRA server. For example, https://10.10.10.10:8080 or https://myJIRAserver

  • Auth Type —Type of authorization to use: None, Basic (the default), or OAuth 1.0

  • Login as —User name and password to use to connect to the specified JIRA URL. For OAuth, use the OAuth token as the username and a private key (in PEM or DER format) as the password

  • (Optional) Log Level —Debug level for logs. For Info (the default), only summary information is logged. For Debug, debug information is logged. For Trace, entire requests and responses are logged

  • (Optional) Check Connection? —If checked (the default), the credentials are checked before the configuration is saved

  • (Optional) HTTP Proxy —Proxy to use for connections

  • (Optional) Proxy Authorization —Username and password for the proxy

Filter Type

No

Type of JIRA filter used to identify issues in the release. You can specify JIRA fields or a JIRA query (in JQL).

JIRA Project

No

(When filtering by JIRA field) The JIRA project key that identifies the project in JIRA.

JIRA Fix Version

No

(When filtering by JIRA field) The fix version in JIRA that identifies the JIRA issues of type “bug” that are part of the release.

JIRA Query (JQL)

No

(When filtering by JIRA query) JQL to use to search issues. Either this parameter or “JIRA filter ID” must be specified. For example, project = MYPROJ and issuetype = Bug will retrieve all bugs for the specified project.

For information about using JQL, see https://support.atlassian.com.

Polling Frequency

Yes

(When filtering by JIRA query) JQL to use to search issues. Either this parameter or “JIRA filter ID” must be specified. For example, project = MYPROJ and issuetype = Bug will retrieve all bugs for the specified project.

For information about using JQL, see https://support.atlassian.com.

As part of the data source creation, a schedule is created in the same project as the release that runs at the specified polling frequency to get the bugs/defects from JIRA based on the parameters specified in the data source and send it to the CloudBees Analytics server. The schedule is named using the format releasename _ datasourcetype _ uniqueid .

Creating or modifying data sources directly

You can also create, modify or delete data sources for each of the data source types such as User Stories and Test Automation via the Sources tab in the Command Center Setup dialog box.

To create or modify a data source directly:

  • From within the Release Command Center dashboard, click Dashboard Editor. The Release Command Center dashboard editor appears:

  • Click Setup. The Command Center Setup dialog box appears.

  • Click the Sources tab.

  • Click the add sources link, or click the New + link on the top of the dialog box. The Source Configuration dialog box appears.

    Add data sources from within the Widgets tab in the Command Center Setup dialog box. For details, see Adding data sources to populate the dashboard .
  • Select a data source type from the Select Source Type pull-down menu.

  • Select the source from the Select Data Source pull-down menu.

    The list of available sources is based on the selected source type and the installed plugins that support collecting data for Release Command Center to send to the CloudBees Analytics server.

    The fields that are relevant to the specific data source that you selected appear in the dialog box. For example:

    If you want to return to the standard view, select the Switch to standard view button.

  • Complete the parameter values for the data source that you selected.

  • Click Close.

The new data source appears in the Sources tab in the Command Center Setup dialog box.