Continuous Delivery Director 8.5

Table of Contents

Release Notes.....................................................................................................................................12

8.5 New Features, Enhancements, and Updates........................................................................................................ 12

8.4.2 New Features, Enhancements, and Updates..................................................................................................... 13

8.4.1 New Features, Enhancements, and Updates..................................................................................................... 14

8.4 New Features, Enhancements, and Updates........................................................................................................ 15

Acknowledgments and License Agreements..............................................................................................................17

About Continuous Delivery Director................................................................................................18

Features........................................................................................................................................................................... 22

Use Cases....................................................................................................................................................................... 24

Glossary...........................................................................................................................................................................25

Continuous Delivery Solution....................................................................................................................................... 29

Workflow..........................................................................................................................................................................31

User Interface..................................................................................................................................................................32

Getting Started (On-Premise)........................................................................................................... 34

Quick Start Guide for Administrators (On-Premise).................................................................................................. 34

Quick Start Guide for End Users (On-Premise)..........................................................................................................40

User Settings.................................................................................................................................................................. 44

Release Orchestration....................................................................................................................... 46

Release Design............................................................................................................................................................... 46

Design and Create Releases....................................................................................................................................48

Create a Release...............................................................................................................................................50

Automatically-Created Releases........................................................................................................................51

Application Versions, Work Items, and Dependencies......................................................................................52

Tokens................................................................................................................................................................ 61

Create and Duplicate Phases............................................................................................................................67

Tasks.................................................................................................................................................................. 69

Complete the Release....................................................................................................................................... 73

Schedule Releases................................................................................................................................................... 73

Build Promotion......................................................................................................................................................... 76

File Sources.............................................................................................................................................................. 77

Parametrized Releases............................................................................................................................................. 77

Pipelines as Code..................................................................................................................................................... 80

Pipeline as Code Example................................................................................................................................ 85

Example REST Call: Import from File............................................................................................................... 88

Release Management..................................................................................................................................................... 90

Manage Releases..................................................................................................................................................... 90

Continuous Delivery Director 8.5

Duplicate Releases............................................................................................................................................ 93

Release Risk Score........................................................................................................................................... 94

Manage Phases........................................................................................................................................................ 97

Create On-Failure Phases............................................................................................................................... 100

Manage Tasks......................................................................................................................................................... 101

Duplicate Tasks................................................................................................................................................ 102

Release Execution........................................................................................................................................................103

Monitor and Troubleshoot Release Execution........................................................................................................106

Activity Panel...........................................................................................................................................................108

Release Notifications...............................................................................................................................................111

Track Planned vs Actual Work............................................................................................................................... 111

Release Risk Score................................................................................................................................................ 114

Rollback Management.............................................................................................................................................117

Release Tracks..............................................................................................................................................................118

Create Release Tracks........................................................................................................................................... 120

Add Releases to a Track........................................................................................................................................ 121

Manage Release Tracks......................................................................................................................................... 121

Calendars.......................................................................................................................................................................123

Release Calendar....................................................................................................................................................123

Maintenance Windows............................................................................................................................................ 124

Create Maintenance Windows.........................................................................................................................124

Environment Planner...............................................................................................................................................125

Freeze Periods........................................................................................................................................................ 125

Create and Edit Freeze Periods......................................................................................................................126

Reports.......................................................................................................................................................................... 127

Test Orchestration............................................................................................................................136

Install Continuous Delivery Director with the Test Module.....................................................................................137

Setting Up the Test Module........................................................................................................................................ 152

Create an Adaptive Testing Task................................................................................................................................153

Monitor Running Tests................................................................................................................................................ 154

Continuous Testing Agents.........................................................................................................................................154

Configure .NET Continuous Testing Agents........................................................................................................... 157

Run a .NET Continuous Testing Agent............................................................................................................161

Configure Java Continuous Testing Agents............................................................................................................162

Monitor Test Suite Executions Through APIs...........................................................................................................164

View Adaptive Testing Results................................................................................................................................... 170

Integration Testing....................................................................................................................................................... 170

Test Advisor.................................................................................................................................................................. 171

Continuous Testing Agents.........................................................................................................................................180

Configure Continuous Testing Agents.................................................................................................................... 182

Continuous Delivery Director 8.5

Configure a Java CT Agent.............................................................................................................................183

Configure a .NET CT Agent.............................................................................................................................183

Run a .NET Continuous Testing Agent............................................................................................................186

Test Module Actions.................................................................................................................................................... 187

Import and Export Test Sources................................................................................................................................ 189

Import a Test Source.............................................................................................................................................. 189

Export a Test Source.............................................................................................................................................. 189

Test Source Templates................................................................................................................................................ 190

Create Test Source Templates................................................................................................................................190

Export Test Source Templates Parameters............................................................................................................ 191

Import/Export Test Source Templates.....................................................................................................................191

Export Test Sources.........................................................................................................................................191

Import Test Sources.........................................................................................................................................191

Remove Test Source Templates............................................................................................................................. 191

Security..............................................................................................................................................193

Security Sources.......................................................................................................................................................... 193

Security Summary Report........................................................................................................................................... 194

Security Items Report.................................................................................................................................................. 195

Integrations....................................................................................................................................... 196

Integration Updates......................................................................................................................................................197

Setting up a Local Plugin Server............................................................................................................................... 237

Manage Plug-ins........................................................................................................................................................... 238

Plug-in Proxy........................................................................................................................................................... 244

Set Up a Plug-in Proxy....................................................................................................................................245

Run Plug-in Proxy With Docker Compose...................................................................................................... 250

Run Plug-in Proxy Without Docker Compose................................................................................................. 252

Register an On-Premise Plug-in with Proxy....................................................................................................254

Configure Plug-in Proxy Properties................................................................................................................. 254

Manage Plug-in Proxies...................................................................................................................................255

Containerized Plug-ins............................................................................................................................................ 256

Containerized Plug-in Manager....................................................................................................................... 257

Set Up Containerized Plug-ins........................................................................................................................ 259

Run Containerized Plug-ins using Docker Engine.......................................................................................... 260

Run Containerized Plug-ins using Kubernetes................................................................................................263

Plug-ins..........................................................................................................................................................................265

Apache Tomcat Plug-in........................................................................................................................................... 268

Atlassian Bitbucket Plug-in..................................................................................................................................... 270

Atlassian Jira Plug-in.............................................................................................................................................. 273

Configure a Jira Endpoint................................................................................................................................275

Continuous Delivery Director 8.5

Add Jira Issue Comments............................................................................................................................... 276

Create Jira Issue..............................................................................................................................................276

Get Jira Issue...................................................................................................................................................278

Update Jira Issue Status................................................................................................................................. 279

Wait for Approval (Jira)....................................................................................................................................280

Define Output Parameters (Jira)......................................................................................................................281

Import Work Items (Jira).................................................................................................................................. 282

Get Test Assets (Jira)...................................................................................................................................... 283

Automic

Continuous Delivery Automation Plug-in................................................................................................284

Configure a CDA Plug-in Endpoint..................................................................................................................287

Start Application Workflow...............................................................................................................................287

Start General Workflow....................................................................................................................................290

AWS CodeDeploy Plug-in....................................................................................................................................... 291

Configure an AWS CodeDeploy Endpoint.......................................................................................................292

Create Deployment (AWS CodeDeploy)......................................................................................................... 294

AWS Elastic Beanstalk Plug-in............................................................................................................................... 294

Azure DevOps Server Plug-in.................................................................................................................................296

Configure an Azure DevOps Server Endpoint................................................................................................ 298

Import Work Items (Azure DevOps Server).................................................................................................... 299

Get Files (Azure DevOps Server)................................................................................................................... 300

Run Build (Azure DevOps Server).................................................................................................................. 301

Create Work Item (Azure DevOps Server)......................................................................................................302

Update Work Item (Azure DevOps Server).....................................................................................................303

Wait for Approval (Azure DevOps Server)...................................................................................................... 303

BlazeMeter

Plug-in................................................................................................................................................304

Burp Suite Plug-in................................................................................................................................................... 308

Configure a Burp Suite Endpoint.....................................................................................................................308

Create Scan (Burp Suite)................................................................................................................................ 309

Checkmarx Plug-in.................................................................................................................................................. 310

Configure a Checkmarx Endpoint....................................................................................................................310

Create Scan..................................................................................................................................................... 311

Create Scan using CxFlow.............................................................................................................................. 312

Coverity Plug-in....................................................................................................................................................... 312

Cucumber JVM Plug-in........................................................................................................................................... 314

Set Up the Cucumber JVM Plug-in................................................................................................................. 316

Configure a Cucumber JVM Endpoint.............................................................................................................317

Get Test Assets (Cucumber JVM)...................................................................................................................318

Cucumber for Ruby Plug-in.................................................................................................................................... 319

Docker Plug-in.........................................................................................................................................................321

DX App Experience Analytics Plug-in.................................................................................................................... 325

Continuous Delivery Director 8.5

DX App Synthetic Monitor Plug-in.......................................................................................................................... 326

Configure a DX App Synthetic Monitor Plug-in Endpoint................................................................................328

Activate and Deactivate Monitors.................................................................................................................... 329

Activate and Deactivate Monitors by Tags...................................................................................................... 329

Run Rule Check...............................................................................................................................................330

Run Rule Check by Tags................................................................................................................................ 330

Set and Remove Maintenance Time Window................................................................................................. 331

Email Plug-in........................................................................................................................................................... 332

Endevor Software Change Manager Plug-in.......................................................................................................... 333

Flowdock Plug-in..................................................................................................................................................... 338

GitHub Plug-in......................................................................................................................................................... 340

GitLab Plug-in..........................................................................................................................................................343

Gradle Testing Plug-in.............................................................................................................................................347

Helm Plug-in............................................................................................................................................................350

Configure a Helm Plug-in Endpoint.................................................................................................................352

Install Release by Helm Chart.........................................................................................................................354

Upgrade Release by Helm Chart.................................................................................................................... 354

Rollback Release............................................................................................................................................. 355

Uninstall Releases........................................................................................................................................... 355

Jenkins Plug-in........................................................................................................................................................ 356

Configure a Jenkins Endpoint......................................................................................................................... 357

Run Build (Jenkins)..........................................................................................................................................358

JFrog Artifactory Plug-in......................................................................................................................................... 359

Karate Plug-in..........................................................................................................................................................362

Configure a Karate Endpoint........................................................................................................................... 362

Get Test Assets (Karate)................................................................................................................................. 363

Kubernetes Plug-in..................................................................................................................................................364

Configure a Kubernetes Plug-in Endpoint....................................................................................................... 365

Create Deployment.......................................................................................................................................... 367

Delete Deployment...........................................................................................................................................367

Set Image.........................................................................................................................................................368

Import Files from AWS S3 (Kubernetes).........................................................................................................368

Liquibase Plug-in.....................................................................................................................................................368

Configure a Liquibase Endpoint...................................................................................................................... 369

Run Deployment (Liquibase)........................................................................................................................... 370

Manual Deployment Plug-in....................................................................................................................................371

Maven Testing Plug-in.............................................................................................................................................372

Micro Focus ALM Plug-in....................................................................................................................................... 375

Micro Focus LoadRunner Enterprise Plug-in..........................................................................................................380

Configure a LoadRunner Enterprise Endpoint................................................................................................ 381

Continuous Delivery Director 8.5

Get Test Assets (LoadRunner Enterprise).......................................................................................................382

Microsoft Teams Plug-in..........................................................................................................................................383

Configure a Microsoft Teams Endpoint........................................................................................................... 385

Post Message (Microsoft Teams).................................................................................................................... 385

Start New Chat (Microsoft Teams).................................................................................................................. 386

Nolio Release Automation Plug-In..........................................................................................................................388

Playwright Plug-in....................................................................................................................................................392

Configure a Playwright Endpoint..................................................................................................................... 393

Get Test Assets (Playwright)........................................................................................................................... 394

Postman Plug-in...................................................................................................................................................... 395

Configure a Postman Endpoint........................................................................................................................395

Get Test Assets (Postman)..............................................................................................................................396

pytest Plug-in...........................................................................................................................................................397

Configure a pytest Endpoint............................................................................................................................ 398

Get Test Assets (pytest).................................................................................................................................. 399

Rally

Plug-In..........................................................................................................................................................400

Configure a Rally Endpoint..............................................................................................................................401

Rally Update.....................................................................................................................................................403

Check Test Case Results (Rally).....................................................................................................................404

Import Work Items (Rally)................................................................................................................................404

Get Test Assets (Rally)....................................................................................................................................407

Red Hat Ansible Plug-in......................................................................................................................................... 409

Red Hat Ansible Tower Plug-in...............................................................................................................................412

Define Output Parameters (Ansible Tower).....................................................................................................417

Red Hat OpenShift Plug-in..................................................................................................................................... 419

Configure an OpenShift Endpoint....................................................................................................................420

Create Deployment (OpenShift)...................................................................................................................... 422

Delete Deployment (OpenShift).......................................................................................................................423

Edit BuildConfig (OpenShift)............................................................................................................................423

Set Image (OpenShift)..................................................................................................................................... 424

Start Build (OpenShift).....................................................................................................................................425

REST Plug-In.......................................................................................................................................................... 425

Example: Integrate with a Third Party REST API........................................................................................... 429

Robot Framework Plug-in....................................................................................................................................... 436

Runscope Plug-in.................................................................................................................................................... 439

Salesforce Plug-in................................................................................................................................................... 441

Configure a Salesforce Endpoint.....................................................................................................................441

Run Deployment (Salesforce)..........................................................................................................................442

ServiceNow Plug-in................................................................................................................................................. 443

Slack Plug-in........................................................................................................................................................... 448

Continuous Delivery Director 8.5

SoapUI Plug-in........................................................................................................................................................ 450

Set Up the SoapUI Plug-in.............................................................................................................................. 451

Configure a SoapUI Endpoint..........................................................................................................................451

Get Test Assets (SoapUI)................................................................................................................................452

SonarQube Plug-in..................................................................................................................................................453

Configure a SonarQube Endpoint................................................................................................................... 455

Check Project Status (SonarQube)................................................................................................................. 456

Run Code Analysis (SonarQube).................................................................................................................... 457

Sonatype Nexus Lifecycle Plug-in.......................................................................................................................... 458

Configure a Nexus Lifecycle Endpoint............................................................................................................ 459

Evaluate an Application (Nexus Lifecycle)...................................................................................................... 459

Terraform Plug-in.....................................................................................................................................................460

Configure a Terraform Endpoint...................................................................................................................... 461

Create a Run (Terraform)................................................................................................................................ 461

Apply a Run (Terraform).................................................................................................................................. 462

Test Data Manager Plug-in..................................................................................................................................... 463

Configure a TDM Plug-in Endpoint................................................................................................................. 463

Run Data Generation Flow.............................................................................................................................. 464

Publish Job.......................................................................................................................................................465

TestCafe Plug-in...................................................................................................................................................... 467

Twistlock Plug-in......................................................................................................................................................469

Veracode Plug-in..................................................................................................................................................... 471

Develop Custom Plug-ins............................................................................................................................................473

Develop Custom Plug-in HTTP Service................................................................................................................. 475

Create the Plug-in Manifest.................................................................................................................................... 482

Sample Plug-in........................................................................................................................................................ 487

Build Notifications........................................................................................................................................................504

Build Notification Workflow......................................................................................................................................504

Configure Build Notifications...................................................................................................................................506

Run an Existing Release................................................................................................................................. 507

Replace the Application Version......................................................................................................................508

Create a Release from DSL............................................................................................................................ 509

Create a Release from Business Application-Related DSL............................................................................ 510

Run Tests Only................................................................................................................................................ 510

CI Tool Integrations......................................................................................................................................................511

Plug-in for Azure DevOps Server........................................................................................................................... 511

Configure Plug-in for Azure DevOps Server................................................................................................... 512

Integration with Bitbucket Cloud............................................................................................................................. 516

Plug-in for GitLab.................................................................................................................................................... 517

Plug-in for Grafana..................................................................................................................................................518

Continuous Delivery Director 8.5

Install Plug-in for Grafana................................................................................................................................521

Configure Plug-in for Grafana..........................................................................................................................522

Plug-in for Jenkins.................................................................................................................................................. 522

Configure Plug-in for Jenkins.......................................................................................................................... 525

Send Build Notifications from a Jenkins Freestyle Project..............................................................................526

Configure Jenkins to Send Git Commit IDs.................................................................................................... 529

Send Build Notifications from Jenkins Pipeline...............................................................................................530

Create Release from File Source in Jenkins Pipeline.....................................................................................532

Documentation Legal Notice.......................................................................................................... 534

Administration.................................................................................................................................. 535

Licensing and Product Usage.................................................................................................................................... 535

View Product Usage - Activity Log......................................................................................................................... 536

View Product Usage - API......................................................................................................................................536

Enable the Portfolio License Agreement................................................................................................................ 536

Enable a Classic Product License..........................................................................................................................538

Manage Users, Groups, and Roles............................................................................................................................ 538

User Permissions.................................................................................................................................................... 542

Integrate with a Directory Server............................................................................................................................544

Enable Single Sign-On............................................................................................................................................547

Configure SAML Authentication.......................................................................................................................551

Enable SAML Groups...................................................................................................................................... 552

Integration Users..................................................................................................................................................... 552

Create An Integration User..............................................................................................................................553

Register Plug-ins.......................................................................................................................................................... 553

Manage Endpoints........................................................................................................................................................554

Create Endpoints.....................................................................................................................................................555

Duplicate Endpoints................................................................................................................................................ 555

Import and Export Endpoints.................................................................................................................................. 556

Projects..........................................................................................................................................................................556

Create and Edit Projects.........................................................................................................................................556

Assign and Manage Project Access.......................................................................................................................557

Applications and Environments................................................................................................................................. 559

Manage Applications............................................................................................................................................... 560

Create Local Applications................................................................................................................................ 560

Import Applications...........................................................................................................................................561

Import and Export Applications with DSL........................................................................................................562

Manage Application Sources........................................................................................................................... 563

Set Source Control Connection.......................................................................................................................564

Set Work Items Connection.............................................................................................................................565

Continuous Delivery Director 8.5

Manage Application Versions.......................................................................................................................... 566

Business Applications............................................................................................................................................. 568

Create Business Applications.......................................................................................................................... 568

Import and Export Business Applications........................................................................................................569

Business Application Versions.........................................................................................................................570

Create Release Environments................................................................................................................................ 572

Replace Environments............................................................................................................................................ 572

Production Environment Protection........................................................................................................................ 573

Setting Up Production Environments...............................................................................................................573

Working with Log Files................................................................................................................................................574

Customize Product Settings....................................................................................................................................... 575

Load Metrics and Sizing..............................................................................................................................................581

Configure High Availability......................................................................................................................................... 583

Configure Notifications................................................................................................................................................589

Edit Notifications......................................................................................................................................................590

Notification Management and Parameters............................................................................................................. 591

Configure Secrets.........................................................................................................................................................593

Configure Shared Tokens............................................................................................................................................596

Configure the Home Folder.........................................................................................................................................598

Change Home Folder..............................................................................................................................................599

Activity Log................................................................................................................................................................... 600

Configure Data Export to Grafana............................................................................................................................. 601

Installation.........................................................................................................................................603

System Requirements..................................................................................................................................................603

Installation Best Practices.......................................................................................................................................... 606

Install Continuous Delivery Director..........................................................................................................................609

Secure Communications............................................................................................................................................. 615

Upgrade Continuous Delivery Director......................................................................................................................618

Uninstall Continuous Delivery Director..................................................................................................................... 619

Reference.......................................................................................................................................... 621

REST API Reference.................................................................................................................................................... 621

Example REST Call: Get All Releases...................................................................................................................624

Troubleshooting............................................................................................................................................................629

Troubleshoot LDAP Configuration.......................................................................................................................... 629

Troubleshoot SAML Configuration.......................................................................................................................... 633

Product Tutorial Videos............................................................................................................................................... 646

Product Names and Abbreviations............................................................................................................................ 650

Product Accessibility Features...................................................................................................................................651

Terms of Service and Privacy.....................................................................................................................................653

Continuous Delivery Director 8.5

Usage Data (Telemetry)................................................................................................................................................ 654

Documentation Legal Notice.......................................................................................................................................655

Continuous Delivery Director 8.5

Release Notes

Continuous Delivery Director augments application deployment capabilities with advanced features to help manage

complex and maturing continuous delivery pipelines.

Continuous Delivery Director works with Automic@ Continuous Delivery Automation and popular SaaS deployment

automation tools. Continuous Delivery Director offers an easily configurable, visual control point to manage, orchestrate,

and optimize continuous delivery pipelines. Continuous Delivery Director includes the following capabilities and benefits:

•

Efficiently design and release multi-app, multi-team, composite applications from agile output through production.

Composite applications help avoid conflicts, drive collaboration, and increase visibility.

•

Track content, such as user stories, across releases to connect delivered content with business goals.

•

Integrate and orchestrate your continuous delivery pipeline tools to leverage preferred tool chains.

•

A flexible, visual interface that helps plan and execute releases, and provides complete control over your release cycle.

•

Define and enforce continuous delivery best practices to improve quality of processes, teams, and applications.

For more information about the value of adding Continuous Delivery Director to your continuous delivery pipeline,

see About Continuous Delivery Director.

8.5 New Features, Enhancements, and Updates

This release includes all features and cumulative maintenance up to 8.5 plus the following new features and

enhancements.

For up-to-date information about our product integrations, see Integration Updates.

Continuous Delivery Director includes all features that are described on this site and summarized in Features.

Enhancements

Modular Release Templates

This feature eases the management of DSL components that repeat in multiple release templates (for example, the phase

or task that are included in many release templates). You can create DSL files that contain a set of objects (for example,

Phase, Task, Tokens) and refer to these files from the release DSL.

Export Phases and Tasks

You can export a single task or phase as a DSL file. This will ease the creation of phase or task DSL template files which

will be referred from a Release DSL, or to import a single phase or task into an existing release.

Security Summary Report - Show by Project

Users can now create a view that lists all the application versions of the current project, selected project or all the projects

which the user is permitted to view the security details report.

Security Report - Search by Reference ID (CVE)

Users can identify if a certain vulnerability is present in the application versions. A new filter by reference ID (CVE) was

added to the "Security Summary" and the "Security Items" reports. Using this filter, users can locate the application

versions which contain the specified vulnerability.

Continuous Delivery Director 8.5

8.4.2 New Features, Enhancements, and Updates

This release includes all features and cumulative maintenance up to 8.4.2 plus the following new features and

enhancements.

For up-to-date information about our product integrations, see Integration Updates.

Continuous Delivery Director includes all features that are described on this site and summarized in Features.

New Features

Grafana – Support Multi-Value Variable

Grafana now allows you to define a variable as a multi-value variable. You can select more than one value for the multi-

value variables. For more information, see the Variables section in Plug-in for Grafana.

Approve and Start ASAP a stage in the release track

A new option was added to the action menu of a production stage – “Approve and Start ASAP”. This option is used when

the track owner would like that unapproved stage will start as soon as the predecessor stage is completed.

Selecting this option clears the start time and approves the production stage.

Tags

Added a new field called 'Tags' to CDD entities. You can now add tags to identify a release, task, phase, application,

business application, environment, endpoint, application version, business application version and security source,

in addition to the existing capability to use tags with Tests. Use the same tags across all CDD entities that are associated

with different projects.

Tags are also added to the grid pages as a new column. Click the filter icon in the Tags column to filter your search.

Grafana - Add Query Parameters using Tags

Added a new query parameter field called 'Tags' to group the information. For example, you can now tag several

applications with the same tag name, and by specifying the tag in the query, you can fetch results that are relevant to the

tagged applications.

Endpoints

In the Endpoints home page, the endpoint names are now displayed in an alphabetical order.

You can now filter the endpoints by selecting a plugin name from the list of registered plugins.

Added an option to duplicate endpoints. To duplicate an endpoint, select an endpoint row, click the row actions (three-dot)

menu, then click Duplicate. For more information, refer to Duplicate Endpoints section under Manage Endpoints.

Added two new columns to the Endpoints home page named "Last Modified" and "Last Modified by." You can now view

when an endpoint was created and last modified, and the name of the user who created or modified it.

Switch Project Enhancements - Unauthenticated User

New functionality was added to ease users to access a release that is not associated with their default project - when

clicking on a release URL, after the authentication, CDD will switch the user's project and the release page will open.

Continuous Delivery Director 8.5

Changed Manifest Fields

Improved tracking of changes to Tasks, Endpoints, and File Sources: The activity which is generated while editing Tasks,

Endpoints, and File Sources is enhanced to include the old and new values of the input fields.

Build Notification Visibility and Auditing

You can now view the latest build that exists for a specific application version so that you know which build will be

processed next when the first phase starts.

8.4.1 New Features, Enhancements, and Updates

This release includes all features and cumulative maintenance up to 8.4.1 plus the following new features and

enhancements.

For up-to-date information about our product integrations, see Integration Updates.

Continuous Delivery Director includes all features that are described on this site and summarized in Features.

New Features

Mandatory Task

A new option was added to the task editor to set the task as “Mandatory.” A mandatory task must complete with success -

only permitted users can disable, skip and edit the task.

For more information, see Create Tasks.

Manage Test Sources from the Release Page

A new tab was added to the side panel, “Tests.” Users can define new tests source, sync the tests and view the test

source status without leaving the release page.

For more information, see Manage Test Sources from Releases.

Enable / Disable Phase

You can enable or disable the phase for execution. Disabling excludes the phases from the release execution.

For more information, see Manage Phases.

Grafana Metrics - Active Users and Automated Tasks

Two new metrics were added to the Grafana plugin - “Active Users,” which presents the number of users logged into CDD

per day; “Number of Automated/Manual Tasks in Active Releases,” which allows you to track the maturity level of your

releases.

For more information, see Plug-in for Grafana.

A new permission "Can delete design release"

New permission added, allowing users to delete only releases in design status (releases that never ran). With this new

permission, users can delete releases that are in Design mode but cannot delete if the release is in "Running" (also

Running with failure) or "Done" mode.

Continuous Delivery Director 8.5

Adaptive Testing Result by Framework Improvements

Search field is added on the "Adaptive Testing Result by Framework" page. You can search for the required test suites

using this field.

UI Enhancements to Application Editor

Added support to associate an application with Business Application from the application page.

For more information, see Create Local Applications and Create Business Applications.

Allow Multi-lines in the Secret Password field

When using "Local" secret, you can store multi-line confidential information such as SSL certificates as Secret Passwords.

For more information, see Configure Secrets.

8.4 New Features, Enhancements, and Updates

This release includes all features and cumulative maintenance up to 8.4 plus the following new features and

enhancements.

For up-to-date information about our product integrations, see Integration Updates.

Continuous Delivery Director includes all features that are described on this site and summarized in Features.

New Features

Secret Management

Secrets are variables that store confidential information such as passwords or API Keys and can be used in the

Endpoints. Using secrets, users can create endpoints without being exposed to the password value. Users can share

passwords across multiple endpoints in the project. The secret value can be defined locally in CDD or, using a plugin, can

get values from the external privilege access management systems.

For more information, see Configure Secrets.

New Release Calendar UI

The Release Calendar is now preset in a modern Gantt chart. Users can select the desired releases to view in the

Release Calendar UI. The performance of the calendar is also improved.

For more information, see Release Calendar.

Grafana Metrics - License Usage

A new metric was added to track the number of active releases in a time range.

For more information, see Plug-in for Grafana.

License Usage Report

A new report with the high watermark of the monthly license usage is made available to the users.

For more information, see Usage Data (Telemetry).

Continuous Delivery Director 8.5

Endpoint Usage Report

The new report provides visibility on the usage of the endpoints in the project. In this report, users can also view the

endpoint assignments in the Tasks, Tests Source, Files Source, Work Item Connections, Source Control Connections,

Application Sources, and Secrets.

For more information, see Reports.

Checkmarx Plugin

Checkmarx Plugin is now enhanced with a new Source code scanning task (CxSAST).

For more information, see Plug-in for Checkmarx.

Enhancements

Recurrent Freeze Period

Added support to create repeatable events for the freeze period. You can create daily, weekly, or monthly events or can

use the custom option to define any repeating pattern.

For more information, see Create and Edit Freeze Periods.

Release Track Changes

The new enhancements allow the users to re-order the production stages and apply changes to the production stage date

as long as the stage has not started. The track owner can define that certain production stages require the user's approval

to start. In addition, to simplify the release tracks creation, the duplicate track functionality was added.

For more information, see Manage Phases.

Enhancements to Phase Scheduling

Added support for the custom recurrent option in the phase schedule. Using this option, users can define any repeating

pattern. In addition, users can see the scheduled/planned dates of the phase in the Phase header.

For more information, see Schedule Releases.

Add Pause Option to Phase

The phase owner can pause a phase while running. The phase is paused immediately upon completion of the running

tasks. The user can resume the phase, and the subsequent tasks start running.

For more information, see Manage Phases.

New Swagger OAS3

The new swagger APIs are available now and use the OpenAPI Specification. Users can use these APIs in the

documentation and code generation tools to generate servers and clients in various programming languages, testing

tools, and many other use cases.

Sonatype Nexus Lifecycle (IQ Server) Plugin

New task that invokes nexus policy evaluation is included in the Sonatype Nexus Lifecycle (IQ Server) Plugin.

For more information, see Plug-in for Sonatype Nexus Lifecycle (IQ Server).

Continuous Delivery Director 8.5

DX App Synthetic Monitor Plugin

New capabilities are added in the DX App Synthetic Monitor Plugin:

•

Rule check for multiple monitors or by tags

•

Activate/Deactivate multiple monitors or by tags

•

Create/remove immediate maintenance window

For more information, see Plug-in for DX App Synthetic Monitor Plugin.

Cucumber JVM Plugin

Enhanced the plugin to view the execution report even if all the tests are skipped.

For more information, see Plug-in for Cucumber JVM.

Playwright Plugin

Enhanced to view the execution report even if all the tests are skipped.

For more information, see Plug-in for Playwright.

Acknowledgments and License Agreements

Click the following links to access TXT format documents that contain license agreement information for third-party

software that is used in Continuous Delivery Director.

•

Core Product

•

Test Advisor

•

Adaptive Testing Catalog

•

Adaptive Testing Results

Continuous Delivery Director 8.5

About Continuous Delivery Director

Continuous Delivery Director is a powerful pipeline planning, release orchestration, test orchestration, and analytics

solution that enables effortless continuous delivery of high-quality, innovative applications from high-performance teams.

To learn more about Continuous Delivery Director, click the tiles below:

Release Design Release Orchestration Release Management Release Execution Reports Test Orchestration https://

techdocs.broadcom.com/us/en/ca-enterprise-software/devops/continuous-delivery-director-integrations/1-0/integrations-

overview.html Release Notifications

Overview

Rapid and reliable deployment of new high-quality release content is essential to drive business agility and reduce

time-to-market. As your processes mature, the speed of your enterprise release cadences and the scale of automated

deployments increase. These changes can result in the following challenges:

•

Increased release complexity, including releases with different requirements and that consist of multiple applications,

teams, and timelines.

•

Increased release velocity makes it more difficult to detect conflicts and bottlenecks.

•

A more agile release process that must support business goals, and application content that is easy to track.

Tools such as Automic

Continuous Delivery Automation automate application deployments to help reduce deployment

times and errors. Continuous Delivery Director offers advanced capabilities to help you manage a complex continuous

delivery pipeline.

Continuous Delivery Director 8.5

Continuous Delivery Director offers an easily configurable, visual, strategic control point to help plan and direct the

processes and content of multi-team, multi-app releases from development through production. Continuous Delivery

Director helps you transition to the next phase of continuous delivery maturity, and move from automated application

deployment to a fully managed and optimized release pipeline.

Typical continuous delivery pipelines incorporate sophisticated sets of tools that include:

•

Application lifecycle management

•

Change management

•

Continuous integration

•

Artifact storage

•

Intelligent test automation

•

Infrastructure automation

•

Deployment automation

These tools perform key functions to ensure fast, high-quality releases. Release pipeline management provides insight

into, and control of, all continuous delivery functions. Continuous Delivery Director adds more advanced, broader pipeline

orchestration to Automic

Continuous Delivery Automation functionality. This enhanced scope helps to manage the end

to end process from development to production. Enhanced release cycle management drives a cross-functional culture of

shared ownership between development, test, release, and operations teams.

Review the content in this section to understand product use cases, concepts, and recommended workflows.

Product Tutorial Videos

These videos are extracted from the following official product training courses:

•

Release Orchestration

•

Test Orchestration

These courses provide extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

Release Orchestration in 60 Seconds

This video provides a 1-minute overview of how release orchestration works in Continuous Delivery Director.

Test Orchestration Overview

This video describes how you can orchestrate tests with your release pipeline. Continuous Delivery Director provides

integration with common testing tools, plus test intelligence and heuristics that automatically select the right tests to run

and return data about release quality based on test results.

System Architecture

You determine the architecture for your CDD instance depending on your specific business needs. The following is a

representation of a typical Continuous Delivery Director system architecture:

Continuous Delivery Director 8.5

The following is a representation of the Continuous Delivery Director object model architecture:

Continuous Delivery Director 8.5

Figure 1: CDD Object Model Architecture

Features

The following section is a summary of Continuous Delivery Director key features:

Plan and Design Releases

Release Design

Continuous Delivery Director provides an interactive interface with the following capabilities:

•

Design flexible, multi-application releases

•

Create releases

•

Add applications to releases

•

Integrate other continuous delivery tools,

•

Divide releases into phases (such as development, QA, and production) and tasks

Continuous Delivery Director 8.5

Release Scheduling

You can schedule planned release executions that require no manual start. Release scheduling lets you execute releases

during off hours to minimize the risk of outages during peak usage times. You can schedule releases in the context of

release design, or through an intuitive release calendar interface.

Integrations

Local and Remote Application Model

As a part of frequent, complex releases, you can import application and environment models from CA Continuous

Delivery Automation to orchestrate deployments. You can also create local applications and environments for proof of

concept, testing, and for tracking purposes.

Phase Approval Gates

You can configure an approval gate for all release phases. The approval gate ensures that the completion of the current

phase is approved before the next phase starts. You can set automatic, scheduled, or manual approval gates. Approval

gates provide a logical separation between phases. Approval gates also prevent releases from deploying the next phase,

such as from Dev to QA, without authorized user verification.

User Management

Continuous Delivery Director lets you create users and add users to groups that are associated with specific product

roles. Permissions range from full administration to read only. These permission levels provide stakeholders with insight

into application and environment release cycles, and eliminate unnecessary infrastructure risks.

Integrate and Collaborate

Continuous Delivery Plug-ins

Continuous Delivery Director uses packaged plug- ins to invoke the functionality of many popular continuous delivery

tools. For example, the CA Continuous Delivery Automation plug-in lets you import applications and run CA Continuous

Delivery Automation application deployment plans in the context of larger releases. This capability provides the flexibility

to deploy multiple applications in the context of a single, release-level entity. Other key integration types include testing,

lifecycle management, and change management tools.

Content Source Integrations

Continuous Delivery Director uses packaged plug-ins to integrate with CA Agile Central (formerly CA Rally) and Atlassian

JIRA. These integrations let you automatically import content from these tools into releases to provide clear, focused

visibility into release content. You can also manipulate content items directly from a release.

Collaboration Features

Continuous Delivery Director provides opportunities for collaboration during release design and deployment. You can add

users and stakeholders to a release to provide visibility. You can also add content to a release to link release orchestration

with application change history and other application activities. You can also view the release activities in the Activity

Panel.

Continuous Delivery Director 8.5

Release Execution

Execute Releases

Continuous Delivery Director lets you execute multi-application releases with a dynamic interface that provides instant

feedback on progress and results. The user interface takes you through each task and phase of the release. The interface

lets you intervene to fix errors, stop tasks, skip tasks, and move to the next phase. Release execution is automated and

interactive in key ways that provide the appropriate level of oversight for all scenarios.

Monitor Releases

Release Dashboard

The Release Dashboard provides widgets to help you track release trends over time. You can configure the dashboard to

set up role-specific views.

Use Cases

Continuous Delivery Director gives release managers and DevOps professionals comprehensive insight into all tasks

and content across all phases of release cycles in the continuous delivery pipeline. While Automic

Continuous Delivery

Automation and other application deployment tools provide robust, application-level deployment automation, Continuous

Delivery Director enables the following functionalities at the pipeline level:

•

Define release content that spans multiple teams and multiple applications

•

Define deployment order and dependencies between applications

•

Configure approvals across applications and phases

•

Use global environments to configure a clear promotion path

•

Respond to release status in real time to ensure success

•

Track release content for visibility into what gets deployed

•

Visualize your entire continuous delivery pipeline to manage multiple releases simultaneously

The following examples show how these functionalities map to high-level continuous delivery use cases:

•

You can effectively manage the complexity of cross-application releases in a content-driven manner that directly

supports underlying agile processes. Tie release content to releases to efficiently map user stories, customer

feedback, and other agile artifacts to the completed release. This level of insight in a single tool lets you anticipate

dependencies, and fully understand how your processes work together.

•

Managing releases from a single tool lets you enforce consistency across the enterprise, and creates a repeatable

release process blueprint.

•

Continuous delivery pipeline optimization becomes simpler when teams have end-to-end transparency. End-to-end

transparency helps avoid conflicts, detect bottlenecks, and fix problems. End-to-end transparency provides visibility

into trends to understand where future problems might occur.

•

You can orchestrate deployments of applications to SaaS, on premises, and hybrid deployment models from a single

tool.

Example Use Case

Consider as an example, a financial company that maintains a complex payment processing system. This system consists

of four discrete applications that always have to run and work together:

•

A front-end user interface application

•

A back-end batch processing application

•

A database for account and transaction storage

•

An application that secures and monitors all transactions

Continuous Delivery Director 8.5

These applications include application dependencies, and the teams and stakeholders responsible for each application.

These applications might be modeled as separate applications in the baseline application deployment software. These

applications can also contain the following continuous delivery artifacts:

•

Deployment plans

•

Development, test, and production environments

•

Build processes

•

Regression tests

•

Performance tests

•

Virtual services

•

Change management data

Release owners can model continuous delivery activities for the payment processing application into a single release

pipeline workflow. This capability unlocks the following key benefits and use cases:

•

Organize the release activities into phases for a global environment view

Ensures that all application phases are complete before they move to the next phase.

Example: You model a Development phase that contains all activities to deploy applications into your Development

environment. If the Development environment includes different systems for each application, the phases in

Continuous Delivery Director give you a global environment view.

•

Add all stakeholders to a release

Ensures that everyone responsible for aspects of the release has the necessary level of insight.

Example: If the build fails for the front-end application, the responsible development team and all relevant personnel

are notified. This notification provides insight into current status to allow stakeholders to adjust their plans accordingly.

•

Model a sequential task-based workflow in each phase

Lets you assemble a logical order of events at the release level to allow for application dependencies and other

factors.

Example: If the batch processing application regression tests or deployment fails, the front-end application updates do

not run.

•

Integration with lower-level continuous delivery tools

Lets you effectively orchestrate the process from a single tool. You can configure Continuous Delivery Director to kick

off deployment plans after you confirm the completion of prior tasks.

•

Collaborative features

Provides increased release insight. For example, you can add release content that tracks the work items that are

addressed in a given application update.

•

Management at scale

Consider the payment processing system as one of dozens of composite applications that the financial services

company manages. Each application has multiple applications, releases, and teams. Continuous Delivery

Director makes it possible to maintain an efficient continuous delivery pipeline at scale. Continuous Delivery

Director detects release conflicts and shows scheduled releases and the environments that they deploy in a single

calendar view. The product also provides teams with one location for collaboration.

Glossary

The following list defines key Continuous Delivery Director terms

account owner The person who signs up for a Continuous Delivery Director subscription.

NOTE

Applies to SaaS only.

Activity Panel A panel on the Releases page that shows all release activities, such as execution events, warnings, and

error messages.

API key A unique alphanumeric key to authenticate user access to REST APIs.

Continuous Delivery Director 8.5

application An entity that you can add to a release and act on using tasks. Applications represent the deployable

units of software that are part of a release. They are often the same as the applications you create in

Automic Continuous Delivery Automation. However, you can also create local application models for proof

of concept and testing purposes or correspond with SaaS-based applications that you deploy with other

tools, such as AWS CodeDeploy.

For more information, see Manage Applications and Environments.

application model A design element that represents an automated configuration and deployment for a server architecture. The

user permissions, actions, and server types must be associated with the application to design processes.

An application model can contain multiple server types and architectures, multiple components to represent

application tiers, and multiple environments.

application source An endpoint providing access to a source control project repository where your application source code files

are stored.

application version An identifier that is assigned to an application.

approval gate An entry gate that lets release owners specify how release phases begin execution. The following approval

gates are available for release phases:

•

Manual - Requires manual execution.

•

Automatic - No approval gate, the phase starts automatically when the previous phase is complete.

•

Scheduled - Starts at the scheduled time.

application version A number that is provided manually at the beginning of a release to indicate the version of an application.

This number is not an auto-generated number, which is given by a build server or source control. This

number is the version number of the application at the end of the release.

blue/green deployment A technique for deploying applications by shifting traffic between two or more production environments at

runtime. This technique lets you switch quickly and easily between staging and production environments

to reduce downtime. You can also roll back to an alternative production environment if changes to a

production environment cause errors.

build notification A DSL file containing build event information sent from a continuous integration tool, such as Jenkins, to

Continuous Delivery Director. The file can contain coded commands to trigger activities within CDD, such

as create or update releases.

build promotion A capability that enables successful builds to automatically advance across the pipeline in Continuous

Delivery Director. You use this capability to promote successful builds across release phases. Application

build numbers are included in and can be automatically tracked across, the lifecycle of a release.

business application A set of applications that represent a meaningful entity to an enterprise or a user (such as a mobile banking

app).

business

application version

An identifier assigned to a business application.

code churn A heuristic that shows the number of code changes in a time range. A large number of changes indicates

code volatility. Measuring the rate of code change is especially relevant in the week before the end of a

release. At this point, the codebase should be stable.

commit source A source control repository in which commit metadata is stored, such as a GitHub repository.

containerized

plug-in manager

A tool that enables you to work with container management platforms such as Docker and Kubernetes.

continuous testing

agent (a.k.a. ct_agent)

An automated service that checks to see if specified test suites have been updated.

custom role A user-defined role containing project and cross-project permissions that do not match the default roles.

Permissions include the following categories

designer The default Continuous Delivery Director user role. Designers can:

•

Edit releases, phases, and tasks if they are owners

•

View releases if they are members

•

Export releases

DSL A specialized programming language for the Continuous Delivery Director system landscape. The

Domain-specific Language (DSL) functionality lets you create and import/export Continuous Delivery

Director objects such as releases, phases, tasks, applications, environments, and so as JSON code. This

functionality reduces the time spent on modeling release pipelines through the user interface.

Continuous Delivery Director 8.5

e-mail template A preformatted document for email notifications sent to users that are automatically triggered by system

events. Templates include parameters that hold data related to the notification purpose, such as release

status updates.

endpoint A connection that a user establishes to remote components, such as Rally

. You can establish multiple

endpoints to a single plug-in.

For more information, see Manage Endpoints.

environment A design element that represents a context in which deployed applications run. When using Continuous

Delivery Director with Automic

Continuous Delivery Automation, they are typically the same as the

environments you create in Automic

Continuous Delivery Automation. Like applications, you can create

local environments for proof of concepts, testing, and use in SaaS-based deployments with other tools,

such as AWS CodeDeploy.

For more information, see Manage Applications and Environments.

external application An application model that exists in a remote component, such as Automic

Continuous Delivery

Automation.

file source An endpoint providing access to files that represent releases in JSON format, stored in a source control

repository.

freeze period A time frame in which a deployment (or similar tasks) cannot take place in specified environments.

Indication Panel A user interface container that docks to the Activity Panel. The Indication Panel contains icons that indicate

the following release events:

•

Pending tasks

•

Errors

•

Warnings

The panel is activated when the release starts to run.

integration testing A test method designed to expose defects in the interactions between applications and subcomponents that

are integrated into a business application.

integration user A dedicated user that manages integrations with other products and services. You use an integration user

to prevent loss of access if employees whose user credentials are used to authenticate to integrations

leave the company.

local application An application model that only exists in the context of Continuous Delivery Director and which is not

imported. You can use local applications for proof-of-concept activities.

local environment An environment that only exists in the context of Continuous Delivery Director and which is not imported.

You can use local environments for proof-of-concept activities.

maintenance window A time frame during which releases can run in a specified environment.

on-failure phase A phase that activates predefined tasks when started manually or automatically triggered by errors in a

preceding phase.

outage A period during which the system is unavailable. There are two types of outages:

•

Unplanned: Due to a problem with our services such as network unavailability or software issues.

•

Planned: Due to maintenance activities which require us to stop the service for a short period.

NOTE

Applies to SaaS only.

parameterized release A release DSL file containing a parameters section that includes release entity name-value pairs. You use

parametrization in release DSLs to create release entities as code, reducing the time spent on modeling

releases through the user interface. Each parameter is a variable that holds data related to the release.

penetration testing An activity that looks for attack paths that might be used to gain access to assets.

phase An organized collection of release deployment steps. Phases provide a global environment view for all

application activities. A typical release has development, QA, and production phases. These phases consist

of the steps necessary to deploy applications in each phase.

NOTE

More Information:

Continuous Delivery Director 8.5

•

Create Phases section in Design and Create Releases

•

Manage Phases

phase gate A setting that specifies how a phase is triggered to run. You can configure phases with the following phase

gates:

•

Manual (default): Runs a phase when a button is selected.

•

Automatic: Runs a phase when the previous phase is complete. Automatic phases that are the first

phase in a release must be started manually.

pipeline as code A Domain-specific Language (DSL) representation of a release pipeline in JSON code. This functionality

reduces the time spent on modeling release pipelines through the user interface.

plug-in Plug-ins allow you to customize Continuous Delivery Director with the integration of remote components.

Each plug-in integrates with a remote component that lets you instrument continuous delivery operations

in release workflows. Plug-ins provide the integration with each component, and endpoints are the

connections to the servers where the remote components reside. For example, the Automic

Continuous

Delivery Automation plug-in lets you configure multiple endpoints to Automic

Continuous Delivery

Automation servers.

For more information, see Integrations.

plug-in proxy A gateway between Continuous Delivery Director SaaS and on-premise plug-in services that run behind

a firewall, such as your corporate GitHub or JFrog Artifactory. The proxy can enable authentication of the

user and then let traffic flow through the proxy despite the firewall.

project segregation A separation between different teams in a project to ensure that different stakeholders are restricted to their

designated releases and releases assets (applications, environments, endpoints, and so on).

release A representation of a workflow for the deployment of applications in one or many environments. Releases

are the core of Continuous Delivery Director.

For more information, see Releases.

release as code A configuration that provides access to Domain-specific Language (DSL) representations of releases stored

in a source control repository.

release conflict An automatically-generated alert that appears in the user interface during release design to indicate a

scheduling conflict. The notification does not prevent the scheduled execution. The alert lets you see the

point in the release where the conflict occurs.

release idle time An analysis of periods of inactivity, such as manual hold-ups, in a release process.

release manager A Continuous Delivery Director user role. Release managers can:

•

Add, remove, and edit releases, phases, and tasks

•

Import and export releases

•

Add releases to release tracks

release member A set of user permissions for a release. Release members can only view releases and cannot perform

release tasks or actions. All owners of release components are automatically added to the release

members list.

release score A statistical measure that quantifies the likelihood of release failure based on the average of a set of

heuristics.

release track A group of releases that are bundled together to deliver all the bundled releases into production

simultaneously.

For more information, see Release Tracks.

releases over time The number of releases marked as done within a specified time frame.

relevant task A task mapped to applications that have changed since the last deployment on the phase environment.

sample release A preconfigured release that appears in the releases list after the first login. Users can configure a sample

release for product onboarding and proof-of-concept.

shared token A placeholder that is replaced with a value during release execution. Unlike other Continuous Delivery

Director token types, such as built-in tokens and local tokens, these tokens are available to all Continuous

Delivery Director users who have access to the workspace. You can use shared tokens to automate

updates to parameter values used across your organization by multiple users.

Continuous Delivery Director 8.5

SMTP An internet standard for electronic mail (email) transmission. System administrators configure SMTP to

enable e-mail messages to alert users to new activities in Continuous Delivery Director.

source control

connection

An endpoint providing access to a source control tool.

subscription An agreement to purchase an account to use Continuous Delivery Director according to the terms and

conditions on the cddirector.io website.

NOTE

Applies to SaaS only.

task A unit of work that represents activity workflows in a release. You add tasks to phases in a specific order to

piece together your release pipeline workflow. Tasks can be manual, such as a change request approval.

Tasks can also enable the automated execution of remote activities like the run of an Automic

Continuous

Delivery Automation deployment plan.

NOTE

More information:

•

Create tasks section in Design and Create Releases

•

Manage Tasks

telemetry A service that monitors a Continuous Delivery Director environment and collects data to provide to

customers and Broadcom. The collected data is used to improve the customer experience and to achieve a

greater return on investment.

tenant ID A unique numeric identifier to authenticate workspace access to REST APIs.

test source An endpoint providing access to test suites stored in an external testing tool.

test source template An endpoint configuration that is predefined by users to help test designers quickly create test sources.

Test source templates are similar to regular test sources except that a test source template can only be

assigned to a single application.

trigger phase A phase with errors that initiates an on-failure phase.

token A reusable placeholder that is used to create generic releases with dynamic task fields such as build

number and issue ID.

work item A record of work in an agile project to be fulfilled. The current state and progress are tracked in an agile

planning tool, such as Rally, and can be integrated with Continuous Delivery Director release pipelines.

work items connection An endpoint providing access to an agile tracking tool.

Continuous Delivery Solution

Continuous Delivery Director (CDD) offers an easily configurable, visual, and strategic control point for planning and

directing the processes and content of multi-team, multi-application releases, from agile development through production.

The Automic

Continuous Delivery Automation (CDA) plug-in lets you apply the core Automic

deployment modeling and

deployment capabilities. This plug-in lets you start both Application and General workflows directly from the Continuous

Delivery Director interface. You can also import applications and environments from an Automic

instance. You can

include Automic

applications and their environments in releases, phases, tasks, reports, and widgets.

This topic includes the following:

Continuous Delivery Director and Automic

Continuous Delivery Automation

The Automic

Continuous Delivery Automation plug-in lets you leverage core deployment capabilities by importing the

application model from the integrated CA CDA instance. This plug-in also lets you start both Application and General

Workflows directly from the Continuous Delivery Director user interface.

Continuous Delivery Director 8.5

What is Automic

Continuous Delivery Automation?

Automic

Continuous Delivery Automation (CDA), part of the CA Automic

One Automation Platform, is an end-to-end

solution for planning, coordinating and automating software release processes, including automated deployments of

complex multi-tier applications and configurations across heterogeneous large-scale server environments.

The purpose of CDA is to unify enterprise application and infrastructure automation functionality onto a single platform

- without the need of managing multiple tools. Users first architect and control the execution of application process

workflows and then orchestrate the underlying infrastructure to meet the required service levels.

Benefits of Using Continuous Delivery Tools: CDD + CDA

Using CDA for defining Application Deployments and CDD for orchestrating them provides you with the ability to configure

critical building blocks of a continuous delivery and release automation pipeline. By combining both tools, you can model,

deploy, and visualize the application pipeline. Furthermore, you can automate the entire delivery and release pipeline

between development and production, supporting emerging use cases such as containers, microservices, test data

management, and vulnerability tracking.

The following diagram shows you how both products work together in a continuous delivery pipeline:

CDA Roles

Application Developer

Application developers create the entities and set up the infrastructure that underpins the workflows, from build to test,

deploy, and release phases.

They build templates, modify existing deployments, create action packs, schedule and execute workflows.

Operator

The release operator is responsible for keeping the production environment running.

Operators perform first level error analysis, compare deployments, and monitor related environments and deployment

targets.

Manager

Release managers coordinate the delivery process and routines, monitor the release status and inform stakeholders.

Continuous Delivery Director 8.5

Administrator

The release administrator implements, reviews, and executes the infrastructure system to support the development

release pipeline.

Administrators create environments. deployment targets, agents, and other infrastructure components, so that an

application developer can use them for deployments.

Configuring the Integration

To configure the Automic

Continuous Delivery Automation plug-in, you register the plug-in in the Continuous Delivery

Director user interface and create endpoints to all necessary Automic

Continuous Delivery Automation systems. You can

then use the Start General Workflow or Start Application Workflow tasks to run a CDA deployment plan in the context of

Continuous Delivery Director phases and releases. The Start General Workflow and Start Application Workflow tasks let

you orchestrate core CDA activities at a high level. For example, a Continuous Delivery Director release might include

multiple applications that you can deploy through the CDA deployment workflows. A phase might also contain specific

tasks for other activities automated through CDA.

NOTE

Automic recommends using Continuous Delivery Director for orchestrating Release Plans for single and multi-

tier Application platforms. For fresh installations, the Release Planner perspective is disabled by default. You

can enable this perspective manually in the customer.config file (Automic\Release.Manager\WebUI

\customer.config ). The Release Planner and Release Management features have been deprecated and

will not be available in future versions.

NOTE

•

About Automic

•

About CA CDA

•

Automic

CDA Documentation

•

Automic

Continuous Delivery Automation Plug-in

Workflow

The Continuous Delivery Director workflow consists of initial installation and administration, followed by iterative release

creation and execution.

The following diagram shows the product workflow and the associated roles:

Continuous Delivery Director 8.5

Figure 2: This diagram shows the product workflow and the associated roles

1. Install the product - system administrator

2. Perform initial configuration - administrator

An administrator must configure the integrations, applications, and users before continuous delivery pipeline

management can begin.

3. Design releases and release tracks - authorized user

Authorized users design releases and release tracks that consist of applications, phases, tasks, and content.

Note: Release Tracks are groups of releases that are bundled for simultaneous execution.

4. Schedule release execution - authorized user

5. Execute releases - authorized user

The authorized user uses the intuitive product interface to executes releases and release tracks. The authorized

user monitors the release progress from start to finish and takes corrective measures where needed.

6. Repeat release design as needed, and schedule and execute phases - authorized user

Release pipeline management is an iterative process that repeats on the cadence of your continuous delivery process.

For example, weekly releases require a new release and proper execution of that release.

7. Monitor release activity - authorized user

Interested personnel can view release progress and historical release trends. To view the history, go to the Releases

page or Release Over Time report. To view the application, go to the Application report or Environment report.

For more information about roles and permissions, see Manage Users, Groups, and Roles.

User Interface

Continuous Delivery Director provides an interactive, intuitive user interface that contains the following pages as tabs at

the top of the UI:

The UI provides a brief Tour, or review, of UI functionality for each page. To enable the tour, click the yellow question mark

icon.

Continuous Delivery Director 8.5

Releases

The RELEASES page provides tools to create and monitor your continuous delivery releases. The RELEASES page

consists of the following interactive components and information:

•

All releases, phases, and tasks

•

A panel with all release applications, Stakeholders, and Tokens

•

An Activity Panel that shows all release activity

For more information, see Releases.

Tracks

The TRACKS page lets you bundle several releases into a track to deliver the bundled releases into production together.

For more information, see Release Tracks.

Calendar

The CALENDAR page provides a real-time, interactive overview of all planned and running releases. You can use the

release calendar to view, drill down into, and manage release components and scheduling.

For more information, see Release Calendar.

Reports

The REPORTS tab lets you create, save, and access the following reports for your releases:

•

Application

•

Content

•

Release analysis

•

Environments

For more information, see Reports.

Administration

The ADMINISTRATION tab lets you manage the following Continuous Delivery Director components from a drop-down

list:

•

Applications and Environments

•

Endpoints

•

Plug-ins

•

User Management

•

Maintenance Windows

•

Settings (On-premises only)

For more information, see Administration.

Continuous Delivery Director 8.5

Getting Started (On-Premise)

All new users of the on-premise version of Continuous Delivery Director should read this section to understand how to set

up and work with the product. This section includes the following information:

Quick Guide for End Users

A brief tutorial on how to access and interact with the product.

Quick Guide for Administrators

A brief tutorial on how to configure the product.

Quick Start Guide for Administrators (On-Premise)

As an administrator, you configure Continuous Delivery Director and manage applications, environments, users, and

integrations. Only administrators and authorized users see the ADMINISTRATION tab which is where you configure and

manage the product.

In this section, we divide the process of getting to know Continuous Delivery Director into three stages:

•

Design

•

Setup

•

Test

Design

During the design stage, you collect your business requirements and plan your release pipeline.

Consider the following:

•

Integrations – Continuous Delivery Director supports a large number of plug-ins and other integrations. Which

integrations will you use?

•

Endpoints – Which will you use? What access do you want to provide?

•

Applications – Mandatory. You cannot execute a release that does not contain at least one application. Which

applications do you want to add to your CI/CD pipeline?

•

Environments – Optional but recommended. Which environment do you want to set up?

•

Manage Users, Groups, and Roles – How will you control access to releases, phases, and tasks?

•

How does your organization manage users - local or LDAP?

•

Do you want to enable SAML?

•

Which content providers does your organization use? For example, Rally

, Atlassian Jira, Microsoft Team Foundation

Server, and so on.

Continuous Delivery Director 8.5

Set Up Your System

During the setup stage, you perform the following actions to complete product configuration:

•

Set Up Authentication

•

Set Up Notifications

•

Set Up Users and Groups

•

Set Up Applications and Environments

•

Set Up Endpoints

•

Set Up Releases

Set Up Authentication

You can configure LDAP and SAML methods to validate and authorize users to access or use Continuous Delivery

Director.

To Do This Comments

Configure SAML Authentication Select Administration, then SAML

Configuration.

Optional.

For more information, see: Enable Single

Sign-On.

Configure LDAP Select Administration, CDDirector

Settings, then User management system.

Optional.

For more information, see: Integrate with a

Directory Server.

Set Up Notifications

You can enable e-mail messages to alert users to new activity in Continuous Delivery Director.

To Do This Comments

Configure Notifications Select Administration, CDDirector

Settings, then SMTP.

Optional. To configure SMTP settings, you

must be a system administrator.

For more information, see: Configure

Notifications.

Continuous Delivery Director 8.5

Set Up Users and Groups

You can create users and add the users to groups that you can assign to specific product roles.

To Do This Comments

1 Create Users Select Administration, User

Management, then Add User.

Optional.For more information,

see Manage Users, Groups, and

Roles.

2 Create Groups Select Administration, User

Management, then Add Group.

Optional.

For more information, see

Manage Users, Groups, and

Roles.

3 Import Users Select Administration, User

Management, then the Import

Users plus sign icon on the

Users toolbar.

Optional.

For more information, see:

Integrate with a Directory

Server.

4 Import Groups Select Administration, User

Management, then the Import

Groups plus sign icon on the

Groups toolbar.

Optional.For more information,

see: Integrate with a Directory

Server.

5 Assign Roles to Users Select Administration, User

Management, then a user and

the pencil icon on the Users

toolbar.

Optional.

By default, new users are

assigned the Designer role.

For more information, see

Manage Users, Groups, and

Roles.

6 Assign Roles to Groups Select Administration, User

Management, then a group and

the pencil icon on the Groups

toolbar.

Optional.

By default, new groups are

assigned the Designer role.

For more information, see

Manage Users, Groups, and

Roles.

Set Up Applications and Environments

You can create applications and environments, and assign users to applications to control access.

Continuous Delivery Director 8.5

An application represents a deployable unit of software that is part of a release. An environment is a location where the

application runs.

To Do This Comments

1 Create Applications Select Administration,

Applications, then either Add

application or Add Application

Source.

Mandatory.

For more information, see

Manage Applications and

Environments.

2 Create Environments Select Administration,

Applications and

Environments, then an

application, and Add

environment.

Optional but recommended.

For more information, see

Manage Applications and

Environments.

3 Assign Users or Groups to

Applications

Select Administration,

Applications and

Environments, then an

application, and enter values in

the Authorized Users/Groups

field.

Optional. By default, all users

and groups can access all

applications.

For more information, see

Manage Applications and

Environments.

Set Up Endpoints

You can create endpoints, and assign applications and environments to endpoints. Endpoints represent specific instances

of remote components that are supported by a registered plug-in. For example, you can connect a release to Automic

Continuous Delivery Automation, AWS CodeDeploy, BlazeMeter, and so on.

To Do This Comments

1 Create Endpoints Select Administration,

Endpoints, Add Endpoint.

Mandatory. When you enter

an endpoint name, choose a

unique and descriptive name,

because releases can have

multiple endpoints

For more information, see

Manage Endpoints.

2 Assign Applications and

Environments to Endpoints

Select Administration,

Endpoints, Add Endpoint.

Optional but recommended.

Specify at least one application

and one environment to an

endpoint, or you will not be able

to use this endpoint inside any

tasks.

For more information, see

Manage Endpoints.

Continuous Delivery Director 8.5

Set Up Releases

Releases are the core of Continuous Delivery Director. Releases consist of phases that simulate global environments and

tasks that instrument continuous delivery operations required during release deployment.

To Do This Comments

1 Create a Release Select Releases, New Release. Mandatory

For more information, see

Design and Create Releases.

2 Assign Applications to the

Release

Select Releases, New Release,

and enter values in the

Applications field.

Mandatory – You cannot create

a release without at least one

assigned application. For more

information, see Design and

Create Releases.

3 Assign Owners and Members to

the Release

Select Releases, New Release,

and enter values in the

Members and Owners fields.

Optional but recommended.

Owners are users who own

and configure releases.

Members are users who can

be assigned release tasks. For

more information, see User

Permissions.

4 Configure Application Version In the release, expand the

APPLICATIONS tree on the left

menu, and select Set Version

next to an application.

Mandatory – Each application

in a release must have a

version number. For more

information, see Design and

Create Releases.

5 Import Application Content In the release, expand the

APPLICATIONS tree on the left

menu, and select the arrow to

the right of the version number

for an application.

Note: This option is only

available after you add a version

number to the application.

Optional – Application content

can consist of metadata or

extra information about specific

deployments in the current

release. This information

enriches your applications and

makes it easier for release

owners and members to

understand what is deployed.

For more information, see

Design and Create Releases.

6 Define Tokens In the release, expand the

APPLICATIONS tree on the left

menu, select %Tokens, then

New Token.

Optional – Tokens are reusable

placeholders. Use tokens to

create generic releases with

dynamic task fields like build

number and issue ID. For more

information, see Design and

Create Releases.

Continuous Delivery Director 8.5

7 Create a Phase In the release, select Create a

phase...

Mandatory – Phases are

organized collections of release

deployment steps in the

Continuous Delivery chain. For

more information, see Design

and Create Releases.

8 Configure the Phase In the Create Phase page,

add an environment, phase

execution type, and owners.

Optional – Use phases to

organize the sequential

deployment of a release into

the different environments

such as development, QA,

and production. For more

information, see Design and

Create Releases.

9 Create a Task At the bottom of the phase box,

select Create a task..., or select

the Add task icon in the phase

toobar.

Mandatory – Tasks are

units of work that represent

activities and workflows that

are associated with a release.

Tasks let you map the sequence

of events that are required to

deploy the release in each

phase. Tasks correlate and are

mapped to applications.

For more information, see

Design and Create Releases.

10 Configure the Task In the Create Task page, set

the task type, endpoint, and

parameters. Optionally, add

owners and applications.

Mandatory – Tasks can be

application deployments,

automated testing, build

processes, or any other activity

that occurs in your regular

release pipeline. Tasks can also

be simple activities that preclude

or follow deployments.

For more information, see

Design and Create Releases.

Test

During the Test stage, you run a sample release to ensure that you have configured the product correctly:

To Do This Comments

Run the Release Select the Run phase button in the first

phase of the release. When a release

starts, the status Running and a power

button icon appear at the top of the release.

Continuous Delivery Director provides

detailed release information and metrics

to help you monitor release progress

and troubleshoot problems. For more

information, see Monitor and Troubleshoot

Release Execution.

Continuous Delivery Director 8.5

Now you are ready to manage Continuous Delivery Director on a daily basis. If you have any questions, please contact us

at: [email protected].

Quick Start Guide for End Users (On-Premise)

This section provides the information you need to know to quickly get started and become productive with a new account.

What is Continuous Delivery Director?

Continuous Delivery Director is your entry point to all of your continuous delivery pipeline. Rather than managing multiple

means fewer passwords to remember, real-time oversight of application content (features and fixes), and easier tracking

of progress against test SLAs, standard release criteria and business priorities.

Prerequisites

Note: If you have questions about the following items, please contact your company Continuous Delivery Director

administrator.

•

You use a browser supported by Continuous Delivery Director. For more information, see System Requirements.

•

The WebSocket protocol is enabled for your client

•

Your Continuous Delivery Director has granted you access to the required applications and environments. These

access rights let you use endpoints to integrate with remote services such as AWS Elastic Beanstalk, JetBrains

TeamCity, Jenkins, and so on.

•

You have received your user credentials

•

You have a URL to log into Continuous Delivery Director.

Syntax: http://{hostname}:{port}/cdd

Example: http://catestENV123:8080/cdd

The first time you sign in to Continuous Delivery Director, you see the following page:

Continuous Delivery Director 8.5

This is the RELEASES page which opens by default. Here you can see all releases that the administrator has authorized

you to access. You work with releases according to the role assigned to you. By default, all users are assigned the

Designer role.

NOTE

If you are assigned the Designer role, the New Release button shown above is disabled.

For more information about roles and permissions, see User Management and User Permissions.

Customize Your User Settings

Your Continuous Delivery Director user account includes settings that you can modify, such as email address and API key.

You can also view your tenant (workspace ) ID. You can access your account settings in the User Settings dialog.

Follow these steps:

1. In the menu bar, select the initials of your user account, for example

then select User Settings, General.

2. View or modify your user account settings:

–

Notifications

Determines whether you receive notifications from Continuous Delivery Director by email.

–

Specifies the email address to which Continuous Delivery Director notifications are sent.

–

API Key

Specifies a unique alphanumeric key to authenticate user access to REST APIs.

Note: The key is masked.

–

Tenant ID

Specifies a unique tenant ID to authenticate user access to REST APIs.

3. Select Save.

Generate an API Key

We strongly recommend that the first time you log in Continuous Delivery Director, you select Re-issue API Key to

generate a new API key.

NOTE

Use the Re-issue API Key command with care. After your API key is reissued, any plug-ins and REST APIs

configured with the previous API key will not work. To enable these plug-ins and REST APIs, you need to specify

your new API key where applicable.

Follow these steps:

1. In the menu bar, select the initials of your user account, then select User Settings.

2. Select Re-issue API Key.

3. Select the copy

icon.

4. Open a text editor, such as NotePad, and paste the API key.

5. Save your API key to a secure location.

Continuous Delivery Director 8.5

Change Password

NOTE

Only relevant for local (non-SAML) users.

In the menu bar, select the initials of your user account, for example

then select User Settings, Change Password.

Release Overview

NOTE

Release Managers and authorized users can create a release. Other users can update existing releases. For

more information, see User Management.

Releases are the core of Continuous Delivery Director. Releases represent workflows for the deployment of applications

in one or many environments.

In this section, we will guide you through the main release concepts, and show you how to create and customize releases.

•

Applications

Represent deployable units of software that are part of a release.

•

Content

Contains the defects, user stories and features that are part of an application version and that are deployed in a given

release.

•

Phases

Represent one or more environments. Your code is promoted from one phase to another until it gets to the production

phase.

•

Tasks

Represent the individual steps needed to move the code to the next phase in the release cycle. There are different

types of tasks: deployment, testing, communication, and manual.

Tasks have owners who are ultimately responsible for the completion of that individual work item. Owners receive

notifications when they have tasks to complete.

For more information, see Releases.

Create a Release

NOTE

You can only create releases if you are an authorized user.

Follow these steps:

1. In the RELEASES page, select New Release.

2. Enter the release name and version.

Example: Quick Start Release, version 1.0.

3. Select one or more applications.

4. Add team members to this release.

5. When ready, select Create.

The release name appears in the release toolbar. You can now add phases to your release.

For more information, see Design and Create Releases.

Continuous Delivery Director 8.5

Create a Phase

Add a phase to your release pipeline.

Follow these steps:

1. In your newly-created release, select Create a Phase.

2. Set the details for the Phase.

NOTE

The Phase represents a series of related steps in the application pipeline and one or more

environments. Your code is promoted from one phase to another until it gets to the production phase.

Enter the Phase name.

3. Set the Phase to Manual.

4. Select the environment the phase will run in.

NOTE

Environments are associated with Applications when applications are imported or created.

Select the sample application environment.

5. When ready, select Create.

You can now add tasks to your phase.

For more information, see Design and Create Releases.

Create a Task

Follow these steps:

1. In your newly-created phase, select Create a Task.

NOTE

Tasks represent the individual steps needed to move the code to the next phase in the release cycle.

2. Enter a name for the Task.

3. Select at least application to associate with the Task.

4. Select a Task Type. Task types are based on the plug-ins that your administrators have configured and made

available. For now, select Manual.

5. Select Create.

Congratulations! You have created a task!

For more information, see Design and Create Releases.

Run a Release

You can run releases that contain both phases and tasks.

NOTE

To run a release, you must be a release owner.

Follow these steps:

1. In the RELEASES page, select a release with all the phases set to AUTOMATIC.

The release opens in a new page.

2. In the first phase of the release, select the Run Phase button

Continuous Delivery Director 8.5

When you select this button, the tasks will run in sequence automatically. When all of the tasks in the phase are

complete, the green check

will appear next to the phase name.

3. When all phases in the release cycle have run, select Mark as Done.

Congratulations, you have just run a release!

For more information, see Release Execution.

Getting Started Video

User Settings

You can access your account settings in the User Settings dialog.

Follow these steps:

1. In the menu bar, select the initials of your user account

then select User Settings.

2. View or modify your user account settings:

Notifications For All Projects

Determine whether you receive notifications from Continuous Delivery Director by email, and what type of notifications

you receive.

Corporate Email

Specify the email address to which Continuous Delivery Director notifications are sent.

API Key for Current Project

Specify a unique alphanumeric key to authenticate user access to REST APIs.

Note: The key is masked.

Tenant ID

Specifies a unique tenant ID to authenticate user access to REST APIs.

3. Select Save.

Generate an API Key

We strongly recommend that the first time you log in Continuous Delivery Director, you select Re-issue API Key to

generate an API key.

WARNING

Use the Re-issue API Key command with care. After your API key is reissued, any plug-ins and REST APIs

configured with the previous API key will not work. To enable these plug-ins and REST APIs, you need to specify

your new API key where applicable.

Follow these steps:

1. In the menu bar, select the initials of your user account, then select User Settings.

2. select Re-issue API Key.

3. select the copy icon

4. Open a text editor, such as NotePad, and paste the API key.

5. Save your API key to a secure location.

Continuous Delivery Director 8.5

Change Your Password

You can change the password you use to authenticate to Continuous Delivery Director, provided your organization does

not use SSO (Single Sign-On).

Follow these steps:

1. In the menu bar, select the initials of your user account

then select User Settings.

2. Select Change Password, and follow the on-screen instructions.

3. Select Change.

Continuous Delivery Director 8.5

Release Orchestration

Releases consist of phases that simulate global environments and tasks that instrument continuous delivery operations

required during release deployment.

During the design phase, you create releases and populate the releases with phases and tasks. During the execution

phase, you execute and monitor the release, troubleshoot issues, and complete the release deployment.

NOTE

For more information, see Release Design and Release Execution.

Product Tutorial Video

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

Release Orchestration Overview

This video summarizes the artifacts, components, and processes of release orchestration in Continuous Delivery Director.

More Information:

•

Release Design

•

Release Management

•

Release Execution

•

Release Tracks

•

Calendars

•

Reports

Release Design

Administrators and Release Designers design releases to drive deployments that release software

into environments across applications and teams. The Release Design page helps you create cross-functional releases

that can consist of multiple-applications and versions.

Note: You can only see releases that you are a member of.

You can use the RELEASES page to:

Continuous Delivery Director 8.5

•

Create and manage releases and memberships

•

Create and manage phases and tasks

•

Assign applications

•

Add users and stakeholders to a release to provide visibility

•

Add content to a release to link your release orchestration with application change history and other application

activities

•

View your releases, and view releases that you are a member of

•

View release activity in real time

•

Manage stakeholders

•

Manage applications

•

Synchronize Conflicts

•

Manage release Tracks.

–

Remap release track phases

–

Return to a release track in the TRACKS page

–

Remove a release from a release track

Note: To open and close a list of keyboard shortcuts, use the question mark (?) key.

Click the RELEASES tab in the top of the UI to show an overview of all releases. Each release is displayed on a separate

line and shows the following release information:

•

Status

•

Name

•

Owners

Note: To filter the page to show only your releases, click the Show my releases box at the top right.

•

Applications

•

Version

Click a release name to open the release and show and manage the release phases and tasks. In the open release, you

can drill down to see and manage the release Applications, Stakeholders, Tokens, and the release status.

Use the following basic workflow to create releases in Continuous Delivery Director:

1. Create a Release

2. Create Phases within the Release

3. Create Tasks within each Phase

The following diagram shows an example of the structure of a release with phases and tasks:

Continuous Delivery Director 8.5

Figure 3: This image shows an example of a typical release structure with Phases and Tasks

Design and Create Releases

Use the following workflow to design and create releases in Continuous Delivery Director

Continuous Delivery Director 8.5

Create Release Tracks Complete the Release Tasks Create and Duplicate Phases Add Tokens to Releases

Application-Related Work Items Set Up Application Version Dependencies Create a Release

Continuous Delivery Director 8.5

TIP

Release design is a flexible process. The following scenario shows a typical release design workflow. After you

create the release, other activities can occur in any sequence. Use the workflow that best fits your release and

working model. Leave comments on this page to suggest or contribute other design workflows.

More Information:

•

Create a Release

•

Replace Application Version

•

Automatically-Created Releases

•

Application Versions, Work Items, and Dependencies

•

Create Phases

•

Tasks

•

Complete the Release

Create a Release

You use the RELEASES page to manually create and manage releases for deployments in Continuous Delivery Director.

You have been granted the Can create release permission.

Releases are repeatable plans that you use to drive deployments to your release environment. Access to releases is

application and project-based. When you create a release, you must ensure that:

•

At least one application or business application is assigned to the release

•

All release owners and members are authorized to access the applications assigned to the release

You can view the applications assigned to releases from the RELEASES page.

1. On the RELEASES page, select the New Release button on the upper right.

The CREATE RELEASE dialog opens.

2. Select and populate the following fields to configure the release:

•

Release Name

Specifies the name of the release.

•

Version

Specifies the release version. Use the version number to correspond to the release number, sprint number, or any

other important differentiator.

NOTE

The version is a required property. Versions are important to differentiate multiple release versions.

•

Description

(Optional). Specifies a description of the release details.

NOTE

This field allows you to format the description text. You can also add links to external systems, resources,

and references that are specific to the release.

•

Application Type

Select either Application or Business Application.

Application

–

Applications

Indicates applications that are linked to the release. Add any application to the release that you plan to deploy or

act on in some other way. You can only view and assign applications that you are authorized to access.

Continuous Delivery Director 8.5

IMPORTANT

You cannot create a release without at least one assigned application. For more information, see

Applications and Environments.

–

Business Application

Add a business application to the release that you plan to deploy or act on in some other way. You can only view

and assign business applications that you are authorized to access.

•

Owners

Specifies users who own and can configure the release.

NOTE

The release creator is the default release owner.

•

Members

Specifies users who can be assigned release tasks. Users can only see releases that they are members of.

Owners of release components are automatically added as release members and can view the entire release.

NOTE

You can only add owners and members from the users and groups that exist in Continuous Delivery

Director. For more information, see Manage Users, Groups, and Roles.

For more information about the difference between release owners and members, see User Permissions

and Activities.

•

Planned Dates

(Optional). Specifies the planned dates for the release.

•

Tags

(Optional). Specifies the tags for a release. Select or create one or more tags to label the Release.

NOTE

The release owner can select or create new tags.

To create a new tag, enter a value (numeric or alphanumeric) into the Tags field and then select Create New.

3. Select Save.

The release is created and saved, and you can add phases and tasks to the release.

Create a Release with Continuous Delivery Director

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows the process for creating a release in Continuous Delivery Director. The release is the core

of Continuous Delivery Director and provides the ability to orchestrate and execute nearly every aspect of

application development and testing through each phase of your release pipeline.

Releases open in a panel in the middle of the page. You can also view the release in the RELEASES tab. The activity

panel on the right of the release shows all release activity. The panel on the left of the release shows and lets you manage

applications, stakeholders, and tokens.

Select Stakeholders in the left column to verify that the release owner and members are correct.

Automatically-Created Releases

You can save manual effort by integrating Continuous Delivery Director with your source control system and CI tools so

that releases are created automatically.

Continuous Delivery Director 8.5

Let us assume that the source control system is GitHub and the CI tool is Jenkins.

In a typical DevOps workflow, developers edit, stage, and commit changes to a feature branch. You can define feature

branches for applications or an entire business application and automatically create releases for each application/

business application version.

The process is the following:

•

Automatically trigger a build on Jenkins when source files are changed in a feature branch

•

Build the project at the given feature branch

•

Notify Continuous Delivery Director that a new build has been created

•

Create a new release in Continuous Delivery Director

The integration with Jenkins supports both Freestyle projects and Cloudbees pipeline syntax. There are two ways in which

Jenkins integrates with GitHub:

•

A GitHub webhook on your repository. Github sends an HTTP request to Jenkins every time a code change is pushed.

•

Jenkins polls GitHub at specified intervals to check if any files have changed.

An automatically-created release using the Continuous Delivery Director plug-in for Jenkins can contain the following

information:

•

Application name

•

Application version

•

Release token values

•

Source control connection parameters

•

Test sources

For more information, see Plug-in for Jenkins.

Application Versions, Work Items, and Dependencies

Release owners can define dependencies between applications to use application versions across different releases.

Each application in your release should have a version number. The application version can be an indicator of the

application version build that you deploy with this release. The application version plays the following roles:

•

Helps differentiate deployments of different application versions across releases and creates version persistence

when deploying the same version across releases. For example: If you add the same version of the application to two

releases, the version retains the content from both releases.

•

Lets you add content to an application. An application must have a version number for you to be able to add content to

it.

•

Lets you assign applications and their content to a specific task within a release. An application must have a version

number to be associated with a task.

•

Lets you manage dependencies across applications and releases.

After you define a version, you can assign application dependencies to the version. Dependencies help you to ensure

successful releases by enforcing links between applications. For example, to deploy successfully, version 2.0 of

Application A requires that an API is added to version 3.0 of Application B. In this case, you could define version 3.0 of

Application B as a dependency of version 2.0 of Application A. When you define this dependency, Continuous Delivery

Director detects dependency issues and sends a warning. A warning is also sent if version 3.0 of Application B is planned

for deployment in the same environment as version 2.0 of Application A.

More Information:

Continuous Delivery Director 8.5

•

Set Up Application Version Dependencies

•

Manage Dependencies Conflicts

•

Manage Business Application Versions in Releases

•

Replace Application Version

•

Application-related Work Items

•

Real-time Work Item Status

•

Tokens

Set Up Application Version Dependencies

Define a dependency between application versions.

1. In a release, click the Applications tab in the left panel, and select Set Version next to an application.

2. Enter the version number for the application. The CREATE NEW APPLICATION VERSION window opens.

NOTE

To edit or to delete a version of an application, select the version number.

•

(Optional) Under Copy Settings, enter an existing application version number. This action copies the settings

(work item source, dependencies and source control connection) from the specified application version to the new

application version.

3. Select Create.

4. Select the version number, and select Set Dependencies.

5. Select another application version that the current application version depends on, and select Set.

After you set a dependency, the orange dependency icon appears next to the application name in the Applications pane.

This dependency is tracked across releases and causes conflict alerts. Alerts are generated if the dependency is not

deployed. Alerts are also generated if the dependency is part of a planned deployment in the same environment before, or

that overlaps with, the dependent application deployment.

When you select an existing version, all content of that version is loaded to the application. Edits to the content of a

deployed version do not affect history. Edits only show in future deployments.

Updates to application versions and content are reflected in the user interface and are visible to other users in real time.

Manage Dependency Conflicts

After you set version dependencies, you can view and resolve dependency conflicts.

1. In the RELEASES page, select Sync Conflicts in the toolbar.

The orange dependencies conflict icon

( )

is displayed next to the phase name and in the task to indicate conflicts. The icon is only visible if there are conflicts.

2. Select the dependencies conflict icon.

The DEPENDENCIES CONFLICTS box opens and shows the conflicts.

Continuous Delivery Director 8.5

3. Edit the deployment order or times to address the conflicts

4. Select Sync Conflicts to ensure that the conflicts are resolved.

Replace Application Version

You can create a release using an existing application version to save setup time and effort.

•

The application version in the build notification is equal to the release version

•

The application is part of the release

You can configure Continuous Delivery Director to create a release using existing application versions without creating

a new application version in advance. When a build notification arrives containing new application version information,

Continuous Delivery Director replaces the existing application version in the release with the new information.

1. In a release, click the hamburger menu, then Edit Release.

2. Under Advanced, select the Replace application version when build notification arrives option.

When a build notification arrives, Continuous Delivery Director creates a new application version (if no version exists) and

replaces, in the release, the application version with the application version from the build notification.

Managing Feature Branches using Continuous Delivery Director

EXAMPLE The Web Banking business application contains the following applications: webServer, webUI,

webDB:

Figure 4: Web Banking Business Application Subcomponents

A developer in the Web Banking group is assigned to work on the F2366 feature. According to their research,

they only need to change the webServer component. Let us assume the application and file sources already

exist in Continuous Delivery Director and that DSL files have been created from the CI tool. In the source

control tool, a DSL repository exists. The developer creates a DSL parameter file:

•

Release version: F2366

•

webServer Application Version: F2366

Continuous Delivery Director 8.5

All other application versions are set to master by default. Creating a new DSL parameter file triggers the

creation of a new release in Continuous Delivery Director. In the source control tool, the developer branches

the webServer repository, names the branch F2366 , and commits the code. This action triggers a build to

run in the CI tool and sends a build notification to Continuous Delivery Director for the webServer application

version F2366 {source control branch}. The arrival of the build notification triggers the start of the release

first phase – Deploy and Run Tests. Next, a bug is opened for the F2366 feature branch. The developer

realizes that they also need to apply the changes to the webUI application. In the source control tool, the

developer branches the webUI repository, names the repository F2366 and commits the code. This action

triggers a build to run in the CI tool and sends a build notification to Continuous Delivery Director for the

webUI application version F2366 {source control branch}. When the build notification reaches Continuous

Delivery Director, the following events are automatically triggered:

1. Continuous Delivery Director analyzes the build notification

2. Continuous Delivery Director creates an application version

3. Continuous Delivery Director searches the existing releases for a release that contains the application

webUI and the release version F2366

4. Continuous Delivery Director finds the Web Banking release, version F2366 , which contains the

application webUI with the master application version

5. Continuous Delivery Director replaces the master application version of webUI with F2366

6. Continuous Delivery Director starts the first phase in the release

Manage Business Application Versions in Releases

You are assigned the Can manage business application versions permission.

NOTE

Users without this permission can assign and remove existing business application versions, but cannot create

and rename versions.

You can see which business applications and which business application versions are in use in releases in the

Applications column on the RELEASES page. You can create, rename, and replace business application versions. You

can also search for specific business application versions.

1. In a release, click the Applications tab.

2. Click the business application version name/number.

3. Click one of the following menu options:

•

Rename.

•

Replace.

NOTE

This option lets you replace the existing business application version in your release with

another business application version or create a new business application version.

Manage Test Sources from Releases

You can manage the test sources as per your Application version or Business Application version from the Releases

page.

Managing the test sources from the Releases page include:

•

Adding new test sources as needed

•

Copying the tests from another application/business application version

•

Syncing the test sources

Continuous Delivery Director 8.5

NOTE

You can also add the Test Sources from the ADAPTIVE TESTING CATALOG page.

Add Test Sources

1. In a release, select the Tests tab in the left panel.

2. Click the hamburger menu of your desired Application or Business Application.

3. Select the Add Test Source option.

The GET TEST ASSETS page opens. Configure the following input parameters:

4. Enter a name for the test source and select a plug-in and an endpoint.

A list of import and execution parameters appears for the selected plug-in and endpoint.

5. Fill in the plug-in input parameters.

6. Specify one or more tags to label the test sources.

7. Click Get Test Assets.

The test source is listed in the Adaptive Testing Catalog page under the application/application version or business

application/business application version.

Copy Tests From Another Application Version/Business Application Version

You can copy the test sources from another application version/business applicartion versions to the current application

version/business application versions.

1. In a release, select the Tests tab in the left panel.

2. Click the hamburger menu of your desired Application or Business Application.

3. Select the Copy Tests from Another Application Version option.

The COPY TESTS FROM ANOTHER APPLICATION VERSION/BUSINESS APPLICATION VERSION page opens.

4. Select the desired Source Application/Business Application Version to copy from.

5. Click Copy.

The test source is copied from the selected source application/business application version. The new test source appears

in the Adaptive Testing Catalog page under the application/application version or business application/business

application version.

Sync All Tests

You can sync the all the tests under the current application/business application version.

1. In a release, select theTests tab in the left panel.

2. Click the hamburger menu of your desired Application or Business Application.

3. Select the Sync All Tests option.

The SYNC ALL TESTS page opens.

4. Click Sync All Tests.

Sync All Tests action updates the test sources and adds the test suites that have been created since the last sync. If a test

suite is deleted from the catalog but still exists in the test framework, it appears again after the sync. This action may take

a few minutes and is performed in the background.

Application-Related Work Items

After you create a release, each application that you add to the release is accessible from the RELEASES page.

Continuous Delivery Director 8.5

You can view existing application-related work items in the left panel under the Work Items tab.

You can view the Applications list to see whether applications have source control and work items connections

configured. You can also use the Applications and Applications Management pages to add work items to applications.

Application work items can consist of metadata or extra information about specific deployments in the current release.

This information enriches your applications and makes it easier for release owners and members to understand what is

deployed.

Examples of application work items include:

•

Notes about deployment changes

•

Defects that were fixed in this deployment

•

User stories that were implemented in this deployment

•

Application lifecycle management tasks

•

New features

•

Information that is used for tracking or other purposes

Import External Work Items into Releases

You can use plug-ins to import external work items to releases from remote components that are integrated with

Continuous Delivery Director.

The following steps are prerequisites to import content from remote components:

•

Create an endpoint to connect to the remote component. The endpoint configuration depends on the plug-in. For more

information, see Manage Endpoints.

•

Create a release and specify application versions. For more information, see Create a Release in this section.

For example, you can import external work items from Rally for application deployment information from associated

stories, tasks, and defects.

TIP

Take care to only import work items that you need, and keep the number of work item sources low.

1. In a release, select the Work Items tab in the left panel, and select the application version number.

2. Select Add Work Items.

The ADD WORK ITEMS window opens.

3. Enter a name for the work items source.

4. From the drop-down lists, select a plug-in and an endpoint.

If you cannot see an endpoint, make sure that an endpoint is added for that plug-in.

5. Provide information in the required parameter fields.

The fields let you build a query that searches the source for work items that match the criteria. For example, with Rally

as a work items source, you can return all resolved defects in the sprint.

Parameters vary by work item source type.

6. Select Create.

The work items source is saved and a list of the returned items is displayed under the application. These items are now

available to assign to tasks in phases to associate important information with the release. You can then use reports to get

a holistic view of all work items deployed with a release.

Continuous Delivery Director 8.5

Import Work Items into a Release

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to import work items into a Continuous Delivery Director release. As long as you have

a working connection to an agile planning system, you can import relevant work items and monitor their status

within the release.

Add Manual Work Items

To help distinguish and track the deployment of the specific applications in a release, manually add work items to

applications.

Manual work items are work items that are not imported from a remote component. The following items are examples of

manual work items:

•

Important notes about the application that you want the release owner to see.

•

Links to external resources that contain important information but cannot yet be imported as external content.

•

Other information that optimizes the application deployment.

1. In a release, select the Work Items tab in the left panel.

2. Select Add Work Items.

The ADD WORK ITEMS window opens.

3. Select the Manual Work Items option, then click Create.

IMPORTANT

You can only use one work item source for each application. If you select Manual Work Items, you cannot

select External Work Items as well.

4. In the Work Items tab, click Add Manual Work Items..

5. Enter, or copy and paste, the content into the Add Content box.

6. Select the checkmark icon.

The manual work item is added to the application.

NOTE

Mouse over the manual work item to edit or delete the content.

Real-time Work Item Status

You can quickly see which work items have entered the CD pipeline.

The list of imported work items that appears in the Work Items panel in releases is compared to the changes that

have arrived in Continuous Delivery Director. By analyzing the commit messages of the change, Continuous Delivery

Director can indicate which work items have entered the CD pipeline. By comparing this information to the statuses in the

application lifecycle management (ALM) tool, you can see anomalies such as a work item that has entered the pipeline,

but which was not planned for this release.

NOTE

This feature currently supports integration between Rally

or Atlassian Jira as the ALM service and GitHub as

source control. Additionally, make sure that the Git plug-in is configured in Jenkins. The Git plug-in ensures that

the commit range is included in the change notifications sent from Jenkins to Continuous Delivery Director.

Continuous Delivery Director 8.5

You can configure the source control connection to use regular expressions to trace work item IDs referenced in commit

messages.

Video: Tracking Planned vs Actual Work - Part One

This two-part video explains how a four-way integration between Continuous Delivery Director, GitHub, Jenkins, and

Rally

can help release managers track planned vs. actual work in releases. Part One contains an overview and

explanation of work item status icons.

Video: Tracking Planned vs Actual Work - Part Two

Part two of this video shows the setup required to enable the integration between Continuous Delivery Director, GitHub,

Jenkins, and Rally

Update Work Items in a Release

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how Continuous Delivery Director can update the status of a work item by detecting the work item ID in

the comments of a code commit.

View Work Item Statuses

You view planned and actual work item statuses to manage risks and dependencies and to escalate and track

impediments.

A work item connection is configured.

As a release manager, you need to understand which work items are being implemented, the risk to release execution

and the probability of delivering the agreed business value on time.

Continuous Delivery Director lets you quickly see which work items have entered the CD pipeline. The list of imported

work items that appears in the Work Items tab is compared to the changes that have arrived in Continuous Delivery

Director. By analyzing the commit messages of the change, Continuous Delivery Director can indicate which work items

have entered the CD pipeline. By comparing this information to the statuses in the Agile tracking tool, you can see

anomalies such as a work item that has entered the pipeline, but which was not planned for this release.

Continuous Delivery Director lets you:

•

See which work items (features, user stories, defects, and so on) are planned to be delivered in the current release

cycle.

•

View the progress of the actual work items.

•

Observe the work items that enter the release, the work item statuses, and the completed work items.

•

Understand which work items have changes that have entered the pipeline and accordingly determine the work

progress.

You can also configure the source control connection to use regular expressions to trace work item IDs referenced in

commit messages.

Continuous Delivery Director uses icons are used to highlight the status of work items in the current release:

Continuous Delivery Director 8.5

Table 1: Work Item Status Icons

Icon Description

No icon

No progress

No updates have been detected for this work item. There are no

commits and there is no indication that this work item has been

accepted in the ALM tool. If no progress is indicated for this work

item and the release is about to end, there a risk that this work

item will not be ready in time for the release.

Accepted

This work item has been marked as Accepted in the ALM tool

Work in Progress

Continuous Delivery Director has detected commits on this work

item or on a related work item, such as a task within this user

story. Because a commit has been detected, Continuous Delivery

Director marks this work item as in progress.

Warning

An inconsistency exists because Continuous Delivery Director has

detected a commit for this work item, while the same work item is

marked as Accepted in the ALM tool. Usually, there is no cause

for concern, but the anomaly must be investigated.

Possible causes: the assigned developer has not yet updated the

work item in the ALM tool, or a developer has added some tests.

Question mark

A commit has been detected for a work item that was not planned

for the current release.

1. Open the required release.

2. Click the Work Items tab.

3. Optionally, filter the work item view.

•

All

•

Planned

•

Actual

Import External Work Items into Releases

You can use plug-ins to import external work items to releases from remote components that are integrated with

Continuous Delivery Director.

The following steps are prerequisites to import content from remote components:

•

Create an endpoint to connect to the remote component. The endpoint configuration depends on the plug-in. For more

information, see Manage Endpoints.

•

Create a release and specify application versions. For more information, see Create a Release in this section.

For example, you can import external work items from Rally for application deployment information from associated

stories, tasks, and defects.

Continuous Delivery Director 8.5

TIP

Take care to only import work items that you need, and keep the number of work item sources low.

1. In a release, select the Work Items tab in the left panel, and select the application version number.

2. Select Add Work Items.

The ADD WORK ITEMS window opens.

3. Enter a name for the work items source.

4. From the drop-down lists, select a plug-in and an endpoint.

If you cannot see an endpoint, make sure that an endpoint is added for that plug-in.

5. Provide information in the required parameter fields.

The fields let you build a query that searches the source for work items that match the criteria. For example, with Rally

as a work items source, you can return all resolved defects in the sprint.

Parameters vary by work item source type.

6. Select Create.

The work items source is saved and a list of the returned items is displayed under the application. These items are now

available to assign to tasks in phases to associate important information with the release. You can then use reports to get

a holistic view of all work items deployed with a release.

Import Work Items into a Release

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to import work items into a Continuous Delivery Director release. As long as you have

a working connection to an agile planning system, you can import relevant work items and monitor their status

within the release.

Tokens

Tokens are variables that can be used in a release to parameterize fields. Using tokens makes a release more flexible and

easy to maintain.

You can create a generic release that release managers use as the starting point for new release versions. Tokenizing

values provides increased flexibility for reusing releases.

A token:

•

Manages and updates values that might change from one build to another

•

Can be generated by Continuous Delivery Director or created manually

•

Can be updated when each phase runs or at the release level

Token Types

The following types of tokens are available:

Common Tokens

Continuous Delivery Director 8.5

•

Are not imported from a remote component

•

Are added manually by release owners and administrators

Release Tokens

•

Manage the variability of certain key values in a release

•

Tokenize values that might change from one build to another

•

Add tokens at the release level

Production Tokens

•

Protect tokens that are used in production phases

•

Contain expressions that are replaced at runtime with production environment IDs

•

Can be used across multiple releases

Syntax: [Prod]{token name}

Built-in Tokens

•

Are part of every release and are automatically created for each application in the release

•

Cannot be deleted or manually edited

•

To use built-in tokens, type "%" in the field and select the token from the dropdown list

IMPORTANT

When you create or import an application, a built-in token is automatically created specifically for that

application.

The new token appears in the %Tokens tab in a release. This token is called {application

name}.last_successful_change.

Always use this token in tasks rather than manually entering a commit or build ID.

In the %Tokens tab, under BUILT-IN TOKENS, you see the following list of tokens:

App1.last_successful_change App2.last_successful_change App3.last_successful_change

Shared Tokens

•

Can only be configured by authorized users

•

There are two types of shared tokens:

–

Shared release tokens, indicated by an [SR] prefix.

NOTE

To manage these tokens, you require the Can manage shared release tokens permission.

–

Shared environment tokens, indicated by an [SE] prefix.

NOTE

To manage these tokens, you require the Can manage shared environment tokens permission.

NOTE

If no applications have been assigned to the shared release token, any user can use that token. However, if

applications are assigned to a token, you can only add that token to releases that contain at least one of the

assigned applications.

System Tokens

•

hen you create or duplicate a release, a set of system tokens is added to that release

•

Display the state of tasks, phases, and releases in the system

•

Help make the deployment process more agile and flexible

•

To use built-in tokens, type "%" in the field and select the token from the dropdown list

Continuous Delivery Director 8.5

NOTE

You cannot add system tokens to task output parameters.

NOTE

Releases that were created prior to Continuous Delivery Director 8.0 do not include the system tokens. To add

system tokens to an earlier release, duplicate that release. The created release will contain system tokens.

NOTE

Releases that were created prior to 30th September 2020 do not include the system tokens. To add system

tokens to an earlier release, duplicate that release. The created release will contain system tokens.

Release and phase-related system tokens (regular system tokens) appear in regular phases and are populated during

phase start.

Continuous Delivery Director includes the following regular system tokens:

•

cdd.release_name

Contains the name and the version of the current release.

NOTE

If the release name or the release version is changed before release execution, this token will contain the

new name and version.

•

cdd.release_url

Contains the full URL of the release. This URL can be copied to a web browser and provides a user with an access link

to the release. Syntax: <host and port>/cdd/releases/<release id>

•

cdd.release_id

Contains the current release ID that is used in REST calls to Continuous Delivery Director.

•

cdd.phase_id

Contains the current phase ID that is used in REST calls to Continuous Delivery Director.

•

cdd.phase_name

Contains the current phase name.

NOTE

If the phase name is changed before phase execution, this token will contain the new name.

•

cdd.phase_url

Contains the full URL of the phase. Syntax: <host and port>/cdd/releases/<release id>?phase=<phase id>

NOTE

For reference only.

•

cdd.phase_environment

Contains the environments of the current phase If the current phase contains more than one environment, this token

will include CSV output with the names of the environments.

•

cdd.phase_executor_email

If the phase executes automatically or is scheduled, the token contains "System". If the user does not have an email

address, the token contains their username instead.

•

cdd.phase_executor_name

Contains the first name and last name of the user that executes the phase. If the phase executes automatically or is

scheduled, the token contains "System". Syntax: <First Name> <Last Name>

On-failure tokens are populated when a task fails and an on-failure phase starts.

You can only use these tokens in an on-failure phase. These tokens only appear in on-failure phases and do not appear in

regular phases.

Continuous Delivery Director includes the following on-failure tokens:

•

cdd.failed_phase_id

Continuous Delivery Director 8.5

Contains the ID of the failed phase that triggered the on-failure phase. This ID is the current ID of the failed phase that

is used for REST calls to Continuous Delivery Director.

•

cdd.failed_phase_name

Contains the current name of the failed phase that triggered the on-failure phase. Note: If the failed phase name is

changed before phase execution, this token will contain the new name.

•

cdd.failed_phase_executer_email

Contains the email address of the user that executes the failed phase. If the phase executes automatically or

is scheduled, the token contains "System". If the user does not have an email address, the token contains their

username instead.

•

cdd.failed_phase_executer_name

Contains the first name and last name of the user that executes the failed phase. If the phase executes automatically

or is scheduled, the token contains "System". Syntax: <First Name> <Last Name>

•

cdd.failed_task_id

Contains the current failed task ID that is used in REST calls to Continuous Delivery Director.

•

cdd.failed_task_url

Contains the full URL of the failed task. Syntax: <host and port>/cdd/releases/<release id>?task=<task

id>&phase=<phase id>

NOTE

For reference only.

•

cdd.failed_task_name

Contains the failed task name.

•

cdd.failed_task_status_description

Contains error messages that appear in the failed task.

•

cdd.failed_task_detailed_status_description

Contains detailed error messages that appear in the failed task.

Token Scope

You can set tokens to have one of the following scope settings:

•

Phase

You can use a token with a phase scope in the same phase in other tasks. The scope is defined where the value of a

token, as received from an output parameter field, is valid. This token uses the set value and not the output value from

a different phase.

The Phase scope is the default scope of a new token.

IMPORTANT

If the token is used in a different phase as a task field value, the token is regarded as empty. Phases with

tasks that use the token as a mandatory value, or with the value already set, will not run and display the

following error:

•

Release

You can use a token with a release scope in other phases, and in the same phase. The value of the token that is used

is the same value that the token got from the output field result.

The token displays the value as an output parameter from the task. The value changes each time that the token is

used in an output parameter field.

Manage Tokens

You ensure that phases and release run as intended by managing any associated tokens.

Effective token management activities include:

Continuous Delivery Director 8.5

•

Search and filtering tokens

•

Adding new tokens as needed

•

Editing existing tokens

•

Viewing token usage to identify which releases, phases, and tasks contain specified tokens

•

Deleting tokens

Search and Filter Tokens

Complex release pipelines can contain large numbers of tokens of all types. Individual releases may also include many

tokens which are listed in the %Tokens tab. To manage specific tokens, first search for existing tokens by typing a text

search string, then filter the results to display the relevant tokens only.

1. Select the %Tokens tab on the Releases page tools panel on the left.

NOTE

To open the tools panel, select the menu icon (three horizontal bars) on the left of the Releases page

toolbar.

2. In the search field, type a text search string.

3. Choose either or both of the following options:

•

Click the filter icon and select one of the following: Common Tokens, Production Tokens, Built-in Tokens.

•

Select a phase or task, then select the Show by Selection checkbox to display only tokens related to the phase or

task you select in the release. If you do not select any phase or task, the tokens panel lists all of the tokens in the

release.

Add Tokens to Releases

After you add a token, you can use the token in task definitions.

1. Select the %Tokens tab on the Releases page tools panel on the left.

NOTE

To open the tools panel, select the menu icon (three horizontal bars) on the left of the Releases page

toolbar.

2. Select Add Token.

3. Enter the token name and select the checkmark icon.

NOTE

You can add either common or production tokens. Token names cannot contain spaces.

4. Specify the current value for the token and press Enter.

The token is available for use in tasks.

5. (Optional) Select the scope of the token from the following options:

NOTE

The default scope setting is Phase.

Phase

A change in token value that results from an output parameter is reflected only in the same phase.

Release

A change in token value that results from an output parameter is reflected across release for all phases.

Continuous Delivery Director 8.5

Create Tokens in Continuous Delivery Director

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to create tokens for use in a Continuous Delivery Director release. Tokens are variables

that can parameterize commonly used fields, making releases easier to maintain.

To select a token in a task field, type the percent character (%) and select the token.

Edit Tokens

1. Select the %Tokens tab on the Releases page tools panel on the left.

NOTE

To open the tools panel, select the menu icon (three horizontal bars) on the left of the Releases page

toolbar.

Tokens associated with phases and the release are listed.

2. In a token row, to display the actions menu select the ellipsis icon (three dots).

3. Select Edit Token.

4. Modify the token name, value, and scope as needed, and save.

The token is updated in every release artifact in which that token appears.

View Token Usage

ou can identify the locations of tokens to determine the consequences of editing or deleting a specific token.

1. Select the %Tokens tab on the Releases page tools panel on the left.

NOTE

To open the tools panel, select the menu icon (three horizontal bars) on the left of the Releases page

toolbar.

Tokens associated with phases and the release are listed.

2. In a token row, to display the actions menu select the ellipsis icon (three dots).

3. Select Show Usage.

Every location of the specified token in phases, tasks, and individual fields is displayed, together with the number of

occurrences.

Delete Tokens

CAUTION

Use this option carefully. Deleting tokens unnecessarily may impact access to system data.

1. Select the %Tokens tab on the Releases page tools panel on the left.

NOTE

To open the tools panel, select the menu icon (three horizontal bars) on the left of the Releases page

toolbar.

Tokens associated with phases and the release are listed.

Continuous Delivery Director 8.5

2. In a token row, to display the actions menu select the ellipsis icon (three dots).

3. Select Delete Token.

A Delete Token pop-up displays, listing every occurrence of the selected token in phases, tasks, and field.

4. Click Delete.

The token is deleted from every location listed in the Delete Token pop-up.

Create and Duplicate Phases

Phases are organized collections of release deployment steps in the Continuous Delivery chain.

Phases provide a global environment view for all application activities. Use phases to organize the sequential deployment

of a release into different environments such as development, QA, and production. Each phase contains environments

that are based on the applications and on the endpoints that are defined in the release. You can create up to ten phases

with different workflows in a release. You can execute phases as often as needed.

You can use the Blue/Green Environment Selector to determine which of two or more production environments to

deploy at runtime. This capability lets you switch quickly and easily between staging and production environments to

reduce downtime. You can also roll back to an alternative production environment if changes to a production environment

cause errors.

1. On the Releases page, select a release.

2. Select Create a Phase.

The CREATE PHASE window opens. You can also use the keyboard shortcut Alt+Shift+P to open the CREATE

PHASE window.

NOTE

Use the question mark (?) key to show and hide a list of keyboard shortcuts.

3. Select and populate the following fields:

•

Phase Name

Specify a name for the phase.

•

Environments

Specify the environments that are associated with the release phase for each application. For example, if you are

creating a phase for your development environment, add all application development environments to the phase.

Configure environments on the Applications page.

IMPORTANT

Specify environments that are assigned to the endpoints and applications to be used in the phase

tasks. If you enter one or more production environments, this phase becomes a production phase.

•

Blue/Green Environment Selector

Enter a token to define the production environment to use at runtime.

•

Owners

Specifies the users responsible for the activities occurring in this phase. For example, members of the development

team might own the Development phase. Phase owners can populate the phase with tasks and can schedule and

run the phase. They also receive release activity notifications.

NOTE

You can only add owners from the users and groups that are configured in the Project Access - Users

and Project Access - Groupspages. You can only assign users to phases that are authorized to access

Continuous Delivery Director 8.5

the applications and environments that are part of the given phase. When you save a release, you are

prompted if permission conflicts exist. The message contains instructions for resolving the conflicts.

•

Choose how you want the phase to run

Specify one of the following phase gates that determine how the phase starts:

–

Manual

Requires a user to start the phase manually.

–

Automatic

Starts automatically when the preceding phase is complete.

NOTE

Automatic phases that are the first phase of a release must be started manually.

–

Scheduled

Starts automatically at the specified time. Use the calendar feature to set the To and From times for scheduled

phases.

NOTE

For a better phase scheduling overview, you can also specify estimated To and From times for

Manual and Automatic phases.

•

Run Tasks with Updated Applications Only

Set a phase to only run tasks mapped to applications that have changed since the last deployment on the phase

environment. When a change notification arrives from the build system or source control for a mapped application,

the phase automatically starts to run. Tasks are executed according to the following rules:

–

If a task does not contain mapped applications, then that task always runs whenever the phase is initiated.

–

If a task has one mapped application, then that task only runs if there is a change to the specific application.

–

If a task has multiple mapped applications, then that task runs if one or more of the specified applications

changes. if multiple applications are changed, the task runs once for all of the changes.

–

If a task is disabled, that task does not run in any event.

NOTE

A task that is not executed due to an invalid application version is marked as disabled and is treated

as a disabled task in all aspects: missing details, release analysis report, token resolving. At the end

of phase execution, disabled tasks revert to enabled status. You cannot change the enabled/disabled

status during phase execution. Tasks that were disabled before the phase execution remain disabled

when the phase is completed.

•

Sync All Relevant Test Sources Prior To Executing Adaptive Testing Task

Select this option to reconcile differences in test availability since the last test suite import before the phase

runs. This setting lets you ensure that any tests that have been added to the test source are included in your

adaptive testing tasks. Similarly, any tests that have been removed from the test source are excluded from adaptive

testing tasks.

•

Description

(Optional) This field supports links to external systems, resources, and references that are specific to the release.

•

Tags

(Optional). Select or create one or more tags to label the Phase.

NOTE

The phase or release owner can select or create new tags.

To create a new tag, enter a value (numeric or alphanumeric) into the Tags field and then select Create New.

4. Select Create.

The phase is added to the release.

Continuous Delivery Director 8.5

5. Optional: (Optional) Set the phase to Request Approval to require phase owner approval to execute the phase.

NOTE

This option is only available for the release owner.

6. Select the phase toolbar Icon in the top right of the phase.

7. Select Request Approval.

NOTE

•

To see who approved a phase, hover over the approval icon in the Approval Phase box.

The only action that you can execute on a phase after approval is Run Phase.

•

To approve the phase and replace the Approval icon with the Run Phase button, select the Approval

icon and select Approve.

•

To disable this feature, a release owner can select Cancel Approval Request in the phase toolbar.

If a phase is stopped before completion, approval is required to restart the phase.

The Approve Phase icon replaces the run icon in the phase and the phase requires approval before execution. Before

the phase starts, the owner of the phase receives an approval notification email.

8. Repeat the previous steps to add the required phases to the release.

Create a Phase in Continuous Delivery Director

Duplicate a Phase

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to create a phase in your Continuous Delivery Director release. A phase organizes the

required tasks to execute when applications are deployed to specific environments, such as Development and

QA. This video shows how to duplicate a phase in a Continuous Delivery Director release. Duplicate phases

to reduce manual effort during release design and creation.

To duplicate a phase, select the phase toolbar icon on the top right of the phase, and from the fly-out menu, select

Duplicate Phase. Rename and edit the duplicate phase.

Depending on your preferred method of release design, you can populate the phases with tasks as you create each

phase. You can also create all phases first, and go back to populate them with tasks.

Tasks

Tasks are units of work that represent activities and workflows that are associated with a release.

Tasks let you map the sequence of events that are required to deploy the release in each phase. Tasks correlate and are

mapped to applications.

To configure and execute tasks in a release, create tasks within a release phase. Tasks can be application deployments,

automated testing, build processes, or any other activity that occurs in your regular release pipeline. Tasks can also be

simple activities that preclude or follow deployments. Examples include closing all stories, approving the build manifest, or

signing off on the deployment.

You can specify build numbers for every application associated with a task, using the Builds for Applications field in a

Create/Edit Tasks window. You can use tokens or free text or both. This capability is especially useful for deployment

tasks. The release-as-code DSL also supports this capability.

Continuous Delivery Director 8.5

TIP

As with phases, you can also duplicate tasks to share the task properties and reduce effort. Depending on your

preferred method of release design, you can either:

•

Populate the phases with tasks as you create each phase.

•

Create all phases first, then populate each phase with tasks. If the phases have similar tasks, create the

tasks in the first phase, duplicate the phases, and edit the duplicates.

•

Use tokens in tasks where the values can change, or for multiple tasks that might share the same values.

You can create the following task types:

•

Automatic - Automatic tasks run actions, such as deployments, testing, and other continuous delivery activities,

in remote components in external environments. Automatic tasks are associated with a plug-in. For example, the

Automic

Continuous Delivery Automation plug-in provides an automatic task that is named Start Application

Workflow. This task runs an Automic

Continuous Delivery Automation application workflow in the context of phases

and tasks.

•

Manual - Manual tasks are simple tasks that do not instrument activities in remote components. For manual tasks, the

task owner or phase owner manually executes the operations that are described in the task. The owner then marks

the task as complete. Use manual tasks to coordinate important release activities that are not otherwise tracked in

a release-level workflow. Manual tasks can also help you track activities that do not have automated task types in

Continuous Delivery Director. An M in the blue field on the right of the task indicates a manual task.

More Information:

•

Create Tasks

•

Highlight Relevant Tasks

•

Duplicate Tasks

Create Tasks

To create a task within a release phase, follow these steps:

1. Select Create a Task at the bottom of the phase box.

You can also select the Add task icon in the phase menu to create new tasks.

2. Select and populate the following fields:

•

Task Name

•

Description

•

Applications

Select one or more applications associated with this task. You can specify a build number for every task.

•

Builds For Applications

Specify a build number for every application. You can use a % prefix for tokens. You can also use free text alone or

together with tokens.

•

Owners

Specify the user who determines when the task is complete and who closes the task during release execution. Task

owners can change task properties and task status. They also receive release activity notifications.

NOTE

You can only add owners from the users and groups that are configured in the Project Access -

Users and Project Access - Groups pages.

•

Tags

(Optional). Select or create one or more tags to label the Task.

Continuous Delivery Director 8.5

NOTE

The Task, Phase, or Release owner can select or create new tags.

To create a new tag, enter a value (numeric or alphanumeric) into the Tags field and then select Create New.

3. Select the Task Type down arrow and select the task type from the drop-down list. Select “Manual” to create a manual

task. For automatic tasks, select a task type from the drop-down list of plug-ins and associated tasks. For Automatic

tasks enter the required task-specific information. To use the dynamic parameter feature to see the available related

values, enter an at symbol (@).

NOTE

Each automatic task type requires a configured endpoint from which to execute the remote component

operations.

For more information about specific task requirements, see Integrations.

NOTE

To use tokens as task field values, type the percent symbol (%) and select the token from the list. Use tokens

for any task field that you expect to change, or to be reused in another task.

4. Determine how Continuous Delivery Director handles task failures. Select one of the following options:

•

(Default) Wait for user action or run on failure phase if found

NOTE

Pauses task and either waits for user action or runs an on-failure phase if configured.

•

Automatically Skip Task

NOTE

The task is marked as a failure, but the phase continues to run.

•

Always Wait for User Action

NOTE

The task is automatically paused until user action. This option does not run an on-failure phase even if

configured.

•

Ignore Failure When Skipping Task

NOTE

Allows promoting the build to the next phase, regardless of task failure.

CAUTION

Using this option can compromise build quality.

•

Set as "Mandatory task"

NOTE

The task is mandatory and cannot be skipped or disabled. Only users with "can manage mandatory task"

permission can manage (edit, enable/disable, delete, etc.) mandatory tasks. Additionally, any task/phase/

release owner can run, re-run, duplicate and change the task's state.

CAUTION

The options "Automatically Skip Task" and "Ignore Failure When Skipping Task" are not allowed for this

task.

5. Select Create.

The task is saved and assigned to the release.

Continuous Delivery Director 8.5

Create a Task in Continuous Delivery Director

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to create a task in a Continuous Delivery Director release. A task is a unit of work that

represents an action or workflow that is associated with a release phase.

Highlight Relevant Tasks

You can display all the tasks in the release that include the specified application version.

1. Select the Apps & Work Items tab in the left panel, and select the application version number.

2. Select Highlight Relevant Tasks.

NOTE

This action does not control the tasks that are run as part of the release execution.

Duplicate Tasks

You can duplicate tasks to reduce the amount of manual labor during the release creation process.

You can duplicate tasks to share the task properties and reduce effort. Depending on your preferred method of release

design, you can either:

•

Populate the phases with tasks as you create each phase

•

Create all phases first, then populate each phase with tasks

TIP

•

If phases have similar tasks, create the tasks in the first phase, duplicate the phases, and edit the duplicates

•

Use tokens in tasks where the values can change or for multiple tasks that might share the same values

•

Drag and drop tasks between phases

1. In a release phase, select a task.

2. Click the task fly out menu, and select Duplicate Task.

3. Change the task properties as needed, such as the application name, tokens, and so on.

4. When done, click Duplicate.

Duplicate a Task

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to duplicate a task in a Continuous Delivery Director release. Duplicate tasks to reduce

effort during release design and creation.

If needed, drag and drop duplicated tasks to the required position in the phase.

Continuous Delivery Director 8.5

Complete the Release

Use the following steps to complete the release design phase.

1. Create all phases and tasks that the release requires.

Use the Duplicate Phase and Duplicate Task functionality at the appropriate level. If phases contain the same tasks

in different environments, duplicate the first phase and modify the subsequent phases and tasks. If tasks are unique

across phases, duplicate tasks where appropriate to reduce effort.

2. Drag-and-drop phases and tasks to order the sequence.

3. Drag tasks together to create a container for parallel task execution.

4. Consult with all release owners to ensure that the release has the required activities.

Owners, designers, and viewers can use the Activity panel for a record of design actions.

5. Schedule the release for execution.

Release Conflicts

During release design, Continuous Delivery Director generates alerts in the UI for scheduling conflicts.

Conflict-related notifications do not prevent the scheduled execution. You can see the following conflicts and the point in

the release where the conflicts occur:

•

Phases that exceed the maintenance window duration or are scheduled to deploy outside a defined window

•

An application dependency that is not deployed in the same environment as the application in any release

•

An application dependency that is not planned to be deployed before or during the current application scheduled phase

Conflicts are displayed in the following locations in the UI:

•

In a phase next to the phase name

•

In the Edit Phase window under Environments

•

In the release calendar, where a red dot in a phase bar indicates a phase conflict

Conflict notifications are removed when the conflicts are resolved.

Schedule Releases

You can schedule release execution at a specific time without the need to start the release manually. Release scheduling

lets you execute releases during off hours to minimize the risk of outages during peak usage times. You can schedule

releases in the context of release design, or through an intuitive release calendar interface.

Schedule in Phases

You can set a specific time for phase execution in the EDIT PHASE window. You can also set a recurrence pattern to run

a phase. When you schedule times within a phase, verify the following items:

•

The time that you set does not conflict with another execution of a different release in the same environment

•

Phase execution times are scheduled sequentially with enough time between phases to allow for failures or

modifications

•

If you set up a recurrence pattern, the scheduled executions should fall between the From and To dates and times

•

If you set a maintenance window for environments that are included in the release, the scheduled times should fall

within that window

Continuous Delivery Director 8.5

Instead of scheduling a specific execution time for each phase, you can set manual approval gates between phases. In

this case, schedule the first phase to execute at a specific time. Then, set manual approval gates and provide estimated

execution times for the next phases. The estimated times give you a general idea of the planned schedule.

Follow these steps:

1. Access the Phase configuration menu during phase creation, or from the Edit phase button in the phase toolbar.

2. Select Scheduled as the phase gate.

3. Set the From and To times.

4. (Optional) Select an option from the recurrence drop-down to set the frequency that you want the phase to run:

Continuous Delivery Director 8.5

Example: Weekly on Monday

5. Click Save.

The phase execution begins at the scheduled time. Execution does not automatically end at the scheduled end time,

but a scheduled end time provides a trackable estimate.

Schedule from the Release Calendar

You can also schedule and reschedule release phases from the Release Calendar. Use the calendar for a holistic view of

all scheduled releases and to make updates to release schedules. The calendar acts as a real-time release dashboard

Continuous Delivery Director 8.5

with each release on a separate line. You can use the calendar to monitor scheduled releases, to identify conflicts, and

to make necessary adjustments.

Follow these steps:

1. Click the CALENDAR tab.

The Calendar displays a list of all releases with visual indicators for when each release is scheduled. Releases without

associated schedules show indicators for the current time.

2. Expand a release on the left tree.

The phases for the release appear, and you can see the scheduled execution time for each phase.

3. Move the bubble for any phase on the calendar to reschedule the phase.

The phase is rescheduled.

Schedule Releases to Run Together

You can use the Continuous Delivery Director Tracks feature to bundle several releases into reusable release tracks. This

functionality lets you deliver all the bundled releases into production together. Release tracks are easy to edit and monitor,

and can be reused and modified for future and periodic releases.

For more information, see Release Tracks.

Instructional Video

The following video shows how to schedule multiple releases and use the calendar and maintenance windows to avoid

conflicts:

Build Promotion

The Build Promotion capability lets you automatically promote successful builds across the pipeline. You can use this

capability to promote successful builds across release phases. Application build numbers are included in, and can be

automatically tracked across, the lifecycle of a release.

The Build Promotion capability lets you automatically promote successful builds across the pipeline in Continuous Delivery

Director. You can use this capability to promote successful builds across release phases. Application build numbers are

included in, and can be automatically tracked across, the lifecycle of a release.

For example, Continuous Delivery Director recognizes the ID in the Build Parameters field of a Jenkins Run Build task

as the build number. To promote a successful build to the next phase, use the built-in last_successful_build token. This

token is used for all applications and across all phases in a release where a build field is required. The token correlates

the correct build number and associated applications.

To receive new build numbers inside the relevant releases, integrate releases with your build system. Use the

last_successful_build token in the Build field of the first phase. If the build system is configured correctly, the new build

number is promoted.

NOTE

For the first phase to run automatically when a new build arrives for the applications in the release, set the

phase gate to Automatic.

NOTE

More Information:

•

Jenkins

Continuous Delivery Director 8.5

Build Promotion in Continuous Delivery Director

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how a Continuous Delivery Director release can move from one phase to the next automatically,

deploying to the appropriate environment with key values changing based on tokens.

File Sources

You can save a lot of the time and effort involved in manually setting up releases by creating file sources.

File sources are connections to files stored in a source control repository, that represent releases in JSON format. Once

you create a file source, releases are automatically created and run whenever you make changes to one of the JSON

files. You can also use the file source feature to manage JSON files that reference other JSON files.

NOTE

To use this capability, create a top-level folder in the relevant repository with the following name: CDD-

FileSource . Place all release-related JSON files in this folder.

The CDD-FileSource folder does not apply if you use file sources to manage JSON files that reference other

JSON files.

Prerequisites: You have been granted Can create file source permissions.

Follow these steps:

1. From the Administration menu, click File Sources, then New File Source.

2. In CREATE FILE SOURCE, select one of the available options as your source control and configure the parameters.

a. Name: Specify a name for the file source configuration.

b. Source Control: Select the requried source control from the available options. Once you select the source control,

addition input parameters fields appear:

•

Endpoint: Select an endpoint.

•

SCM Type: Select either Git or TFVC, according to the source control management system used in Azure

Devops Server.

•

Project: Specify a Azure Devops Server project name or ID.

•

Repository: Specify the name of the Azure Devops Server repository from which to import the files.

•

Branch: Specify a branch used by the specified project. To allow processing of webhook notifications from all

repository branches, keep this field empty.

c. Release Created On Behalf Of (API Key): Specify the API key of the user on whose behalf future releases will be

created.

NOTE

If you are creating the file source on your behalf, then leave the field empty.

d. Send Error Notifications To: Specify the name of the recipients to receive error notifications. By default, the

logged in user’s email address is selected.

3. Click Create.

Parametrized Releases

Use parametrization in release DSLs to create release entities as code, reducing the time spent on modeling releases

through the user interface. Use the user interface to export or import parameterized releases.

Continuous Delivery Director 8.5

You can parametrize the following release entities:

•

ApplicationVersion

•

ReleaseToken (regular, shared, and production)

•

Phase

•

Task

•

ContentSource

Export Parameterized Releases

You can export parametrized release DSL files in the Releases page, using the Export Parameterized Release

Template option.

In the Releases page, an icon indicates that a release is parameterized and can be exported as a template.

When you export a release, the release entities are parameterized, and the "parameters" section is added to the DSL

with the parameters.

The export does not modify the objects - if the objects section includes parameters, the exact parameters are exported

(regardless of their values).

The exported file name syntax is <release name>_<release version>_template.json.

The parameters section includes all parameters without values. For example:

"parameters": [

{

"name": "version",

"value": ""

{

"name": "appName",

"value": ""

{

"name": "releaseName",

"value": ""

}

Limitations

Duplicate releases do not keep the parameters. A duplicated release includes only the values and is not marked as a

template.

When the field contains a list of external entities (such as users, shared tokens, groups, application versions), if the

reference is removed from the list, the list is exported with values and not with parameters. For example, a template

contains:

"parameters": [

{

"name": "userName",

"value": "[email protected]"

}

]

********

Continuous Delivery Director 8.5

"objects": [

....

"ownerParties": [

"BuildNotification",

"[email protected]",

"${userName}"

]

[email protected]

The owners appear in the release as BuildNotification , [email protected] , [email protected] . If a

user removes [email protected] , the export does not include the parameter "userName".

If the name of an external entity is changed (for example, you change a group name/application version/phase),

and this entity is parameterized in the release, the export does not include the parameter, but the only the entity name.

If a field contains a reference to another entity, and due to the release editing the reference is changed, the field is

exported with the value and not as a parameter. For example:

"parameters": [

{

"name": "p1",

"value": "CI"

{

"name": "p2",

"value": "UAT"

]

****************************************************************************************

"objects": [

{

"kind": "Phase","name": "${p1}",

"previousPhase": null

{

"kind": "Phase","name": "${p2}",

"previousPhase": "${p1}"

}

]

This scenario creates two phases - "CI" and then "UAT". If a user edits the release and moves "UAT" to before "CI", the

export DSL is:

{

"kind": "Phase","name": "${p2}",

"previousPhase": null

{

"kind": "Phase","name": "${p1}",

"previousPhase": "UAT"

}

Continuous Delivery Director 8.5

Import Parameterized Releases

When you import a parameterized release, Continuous Delivery Director stores the parameters defined in the DSL.

The same parameter can be used in multiple entities. In the following example, the parameter "version" appears both

as an application version and as a release version.

A parameter can appear next to free text. In the following example, the parameter releaseName is next to the text

"Mobile-Team" .

A release attribute can contain more than one parameter.

{

"ownerParties": [

"[email protected]"

"applicationVersions": [

"Local|${appName}/${version}"

"runOnCreation": false,

"version": "${version}",

"name": "${releaseName}-Mobile-Team",

"kind": "Release"

}

Pipelines as Code

The pipelines as code function enables you to export the release entities to a DSL file - a JSON file representing the

release entities.

You can use pipelines as code to:

•

Automate the release creation simply by committing a DSL file containing set of parameters to the source control

•

Apply benefits such as version control, code review, branching strategies

•

Easily transfer content between user accounts and workspaces

•

Share pipelines as templates

•

Make holistic changes to the pipeline with minimal effort

•

Seamlessly and securely deliver new application features and updates

The DSL File Format

The DSL is a JSON format file. The file may contain two sections - Objects and Parameters.

DSL Objects

The JSON files that represent pipelines contain fully qualified names (FQNs) that specify which object, function, or

variable to which a call refers to.

Examples of FQNs

Object Syntax Sample Text

release [release name]/[release version] Sample Release/1496057472000

phase [release name]/[release version]/[phase

name]

Sample Release/1496057472000/

Acceptance

Continuous Delivery Director 8.5

task [release name]/[release version]/[phase

name]/[task name]

Sample Release/1496057472000/

Acceptance/Run acceptance tests

application [source name]|[application name] Local|Sample Application 1

application version [source name]|[application

name]/[application version name]

Local|Sample Application 1/1.0

plug-in [plug-in name]/[plug-in version] BlazeMeter/1.0

NOTE

Some objects (such as application, application version) require the use of the pipe '|' character to separate two

adjacent data fields within a segment. This character also separates the segment ID from the first data field in

each segment.

DSL Parameters

To create a DSL template, you can replace hard coded values with parameters. The parameters are specified in the DSL

file in a separate section, or in a separate parameters file.

For example, you can parameterize the following release entities: Application Version, Token value, Phase Name, Tasks

Name, and so on.

The Parameters section in the DSL will specify the name and values. For example:

"parameters": [

{

"name": "p1",

"value": "CI"

{

"name": "p2",

"value": "UAT"

]

In the Objects section you can use the parameter in the following format:

"objects": [

{

"kind": "Phase",

"name": "${p1}",

"previousPhase": null

{

"kind": "Phase",

"name": "${p2}",

"previousPhase": "${p1}"

}

]

You can use the same parameter in multiple utilities. In the following example, the parameter "version" appears both as an

application version and as a release version.

Continuous Delivery Director 8.5

A parameter can appear next to the free text. In the following example, the parameter ‘releaseName’ is next to the text

‘Mobile-Team.’

A release attribute can contain more than one parameter.

{

"ownerParties": [

"[email protected]"

"applicationVersions": [

"Local|${appName}/${version}"

"runOnCreation": false,

"version": "${version}",

"name": "${releaseName}-Mobile-Team",

"kind": "Release"

}

Referring Parameters file to an Object File

You can split a parametrized DSL file into two - an object file that contains only the objects and a parameters file. The

objects file will be stored in a Git repository and the parameters file will contain a reference to the objects file. The user will

import the parameters file, and using the reference details CDD will merge the two files and create the release.

To use this capability, create a top-level folder in the relevant repository with the name “CDD-FileSource” and place the

objects file in this folder.

The Reference section in the parameters file contains the following attributes:

•

The objects file name

•

The file source name which will be used to fetch the file from the repository

The following is the format of the Reference section:

"reference": {

"fileName": "My_Release_Template.json",

"fileSource": "My filesource"

}

Add Reference to Phase/Task DSL in a Release DSL File

You can manage release objects such phases or tasks in a separate DSL file, and to include in the release DSL reference

to these objects.

An example of use case is if you have a phase that repeats in many release templates, and you would like to apply

changes to this phase only once and it will apply to all release templates.

First you need to create a DSL file that contains the required object. Make sure that you parameterize all the attributes

that refer to a specific release such as release name, release version, application name and versions, previous phase,

and so on.

Store the file in a git repository and create a file source for this repository.

In the Objects section of the release DSL, enter a reference to this DSL file. The reference will include the file name and

path, the file source for the specific repository and list of parameters and values that are used in the DSL.

Use the following format:

Continuous Delivery Director 8.5

{

"kind": "reference",

"fileName": "<path and name of the DSL file>",

"fileSource": "<file source for the specific repository?",

"parameters": [

{

"name": "<Parameter name>",

"value": "<Parameter Value>"

{

"name": "<Parameter name>",

"value": "<Parameter Value>"

} ]

}

Specifications:

•

You can use a release parameter as a value for the reference parameter. for example,

{

"name": "APPLICATION1_NAME",

"value": "${applicationName}"

}

In this example, the parameter applicationName is a release DSL parameter.

•

If a certain field may contain more than one value, the object DSL should contain parameters for every value. For

example, owners of a specific phase will have the format:

"ownerParties": [

"${user1}",

"${user2}",

"${user3}"

]

If the calling release is not required to list three owners, in the reference specify only one parameter. The other

parameters will be ignored.

•

An object DSL may contain reference to another Object DSL. For example, a DSL of a phase may include reference to

DSL of a task

•

There is importance to the location of the objects in the DSL file. When object A has a reference to object B (for

example, when a previous phase attribute is defined for a phase object), object A must be defined above to object B. If

you use reference to define object A, the reference object must appear above the definition of object B.

Special Tokens and Attributes

Release DSL Tokens

When you create and edit JSON files that represent pipelines, you can use special tokens as placeholders for values in

FQNs, descriptions, and versions. The tokens must start and end with a '%' percent sign.

The following tokens are available for use in JSON files:

•

CDE.CURRENT_TIME The current time in milliseconds

Example:

Continuous Delivery Director 8.5

"kind": "Phase","release": "%CDE.CURRENT_USER_FULL_NAME%'s Sample Release/

%CDE.CURRENT_TIME%",

•

CDE.CURRENT_USERNAME The user name of the logged-in user. This token can be used in owner and member

parties

Example:

"ownerParties": [ "%CDE.CURRENT_USERNAME%"

•

CDE.CURRENT_USER_FULL_NAME The first name and last name of the logged-in user

Example:

"kind": "Phase", "release": "%CDE.CURRENT_USER_FULL_NAME%'s Sample Release/

%CDE.CURRENT_TIME%",

Release Attributes

•

Mark Releases as Done - You can add the markAsDonePhaseName property to the Release paragraph in the DSL to

configure a release to be marked as Done automatically.

To use this property, set the value to the name of the phase that will mark the release as done automatically. This

setting assigns the specified phase in the release as the phase that marks the release as done.

Syntax

"markAsDonePhaseName" : "<phase name>"

Example

"markAsDonePhaseName" : "QA"

•

Run on Creation - Boolean flag, when set to true the first phase will start upon the release creation.

Syntax:

"runOnCreation" : "true"

Export or Import Release

From the Releases page, you can import and export the release DSL.

Export Release with Content

This option will download the release DSL file containing all the release objects and their values.

Export Parameterized Release Template

This option is available only for releases created from a parameterized DSL file. Selecting this option downloads the

release DSL containing the parameters that are used in the objects, and a Parameters section that lists all the parameters

without values.

Export Phase or Task to a DSL Template

You can export a phase or a task from the release, and later use it either as a reference to a DSL template or to import

from the user interface after they are edited.

Exporting a phase provides the following two options:

•

Export Phase with Content: This option creates a DSL file containing the phase object and all the task objects. You

can select to export with or without the on-failure phase (if it exists).

•

Export Parametrized Phase Template: This option creates a DSL that includes the phase object and all the related

tasks. If the phase was created using a parameterized DSL file, the exported DSL will contain the DSL parameters.

You can select to export with or without the on-failure phase (if it exists).

Exporting a task provides the following two options:

Continuous Delivery Director 8.5

•

Export Task with Content: Exports the task DSL containing the fields’ value.

•

Export Task as a Parametrized Template: If the task is created from a parameterized DSL file, the exported DSL will

contain the DSL parameters.

Import Release

The import validates the DSL file and errors out any anomalies such as missing entities or duplicate names.

The import creates a new release or even a release component, providing that all the object's FQNs will be specified

correctly.

You can import files either from your local machine or from the source control repository:

•

Import from Source Control Repository:

–

Select the file source which has access to the required repository

–

Provide a relative file path to a JSON file in your source control repository

•

Import from Local Machine

–

Browse the local folders and select the required DSL file.

Import Parameterized Releases

When you import a parameterized release, CDD stores the parameters defined in the DSL.

Creating and Running releases using GitOps

You can create a new release and trigger its run directly from your git repository.

A typical use case is when the dev team would like to release a new application version. The DevOps engineering team

owns the release template and the Dev team needs to supply the parameters value.

The dev team creates the parameters file, commits it to a git repository, and this triggers the release creation and

execution.

To set up the release creation using GitOps, follow the following steps:

1. Create the release DSL objects file that contains the release template and store it in your source control under the

CDD-FileSource folder

2. Create a file source for a specific repository which stores Objects file and copy the webhook URL

3. Create a release DSL parameters file which contains the reference to the object file (the created file source and file

name). Store the file in git repository (can be a separate repository)

4. Create a webhook for push events in the parameters file’s repository using the webhook URL that was generated by

the file source

When a change to the parameters file is committed, a webhook is sent to CDD. CDD then accesses the parameters file

and the objects file, and creates the new release.

Pipeline as Code Video

The following embedded video describes the Pipeline as Code feature in Continuous Delivery Director. This video

provides extra information, context, and examples to augment the product documentation. This video is available in full

size on the Continuous Delivery Director YouTube channel.

Pipeline as Code Example

The following example shows how a sample release is represented in JSON format.

Continuous Delivery Director 8.5

User Scenario

A release manager, Julie Wilson, imports a sample release from the code repository:

When Julie clicks the release name, the preconfigured sample release appears, complete with phases and tasks:

The Activity pane shows that the import release action triggers the creation of the child objects and variables of the

sample release.

After the import is complete, Julie can either work with the existing sample release configuration, or make changes as

needed.

Pipeline as Code Sample

The following code sample is the full pipeline definition JSON file for the sample release that Julia imports:

{ "objects": [ { "name": "Sample Application 1", "kind": "Application" }, { "applications": [ "Local|Sample

Application 1" ], "name": "Test", "kind": "Environment" }, { "environments": [ "Test" ], "applications":

[ "Local|Sample Application 1" ], "name": "Blazemeter", "kind": "Endpoint", "type": "BlazeMeter",

"parameters": { "apiKeyId": "0248cb489fd1a1ba731de0f6", "authType": "Advanced", "url": "https:\/\/

Continuous Delivery Director 8.5

a.blazemeter.com" }, "plugin": "BlazeMeter\/2.1" }, { "application": "Local|Sample Application 1", "name":

"6.8.0", "kind": "ApplicationVersion" }, { "version": "1.0.1", "ownerParties": [ "[email protected]" ],

"memberParties": [ "[email protected]" ], "applicationVersions": [ "Local|Sample Application 1\/6.8.0" ],

"description": "", "name": "Julie Wilson's Sample Release", "kind": "Release" }, { "environments":

[ "Test" ], "isApprovalRequired": false, "release": "Julie Wilson's Sample Release\/1.0.1", "approvalGate":

"MANUAL", "ownerParties": [ "[email protected]" ], "name": "PhaseTemplate", "kind": "Phase" }, { "phase":

"Julie Wilson's Sample Release\/1.0.1\/PhaseTemplate", "ownerParties": [ "[email protected]" ], "isDisabled":

false, "applicationVersions": [ "Local|Sample Application 1\/6.8.0" ], "name": "TaskTemplate", "kind":

"Task", "type": "Run Test", "parameters": { "workspace": "Default workspace", "test": "Test 2 - Valid URL",

"project": "Default project" }, "endpoint": "Blazemeter", "plugin": "BlazeMeter\/2.1" } ] }

Explanation of the Pipeline as Code Sample

The following section explains how the different elements of the sample release are represented in JSON format.

•

Application

A deployable unit of software that is part of a release.

Example: The sample release contains an application, Sample Application 1:

"name":"Sample Application 1",

"kind": "Application"

•

Environment

A location where an application runs

Example: The sample release contains a Test environment:

"name":"Test",

"kind": "Environment"

•

Application Version

A unique version number assigned to a unique state of the application in sequential order.

Example: The application Sample Application 1 is in version 6.8.0:

"application":"Local|Sample Application 1",

"name": "6.8.0", "kind": "ApplicationVersion"

•

Release

A configuration that consists of phases that simulate global environments and tasks that instrument continuous delivery

operations required during release deployment.

Note: Pipeline as Code automatically assigns logged-in users the role of release owner.

Example: The release, Julie Wilson's Sample Release, is in version, 1.0.1. The release owner is [email protected],

and the release member is [email protected].

{ "version": "1.0.1", "ownerParties": [ "[email protected]" ], "memberParties": [ "[email protected]" ],

"applicationVersions": [ "Local|Sample Application 1\/6.8.0" ], "description": "", "name": "Julie Wilson's

Sample Release", "kind": "Release" },

•

Phase

Continuous Delivery Director 8.5

A representation of the different environments that are part of your release.

Example: The sample release contains a PhaseTemplate phase.

], "name": "PhaseTemplate", "kind": "Phase" }, { "phase": "Julie Wilson's Sample Release\/1.0.1\/

PhaseTemplate", "ownerParties": [ "[email protected]" ],

•

Task

A representation of the relevant workflow inside each release phase.

Example: The sample release contains a Blazemeter task, Run Test.

], "name": "TaskTemplate", "kind": "Task", "type": "Run Test", "parameters": { "workspace": "Default

workspace", "test": "Test 2 - Valid URL", "project": "Default project" }, "endpoint": "BlazeMeter",

"plugin": "BlazeMeter\/2.1" }

•

Parameters

A representation of the parameters that determine how Continuous Delivery Director accesses specific release

components. The DSL JSON file can refer to parameters such as ${APPLICATION_NAME}.

You specify the value of parameters in the parameters section.

Syntax:

{ "objects": [ { "kind": "string" } ], "parameters": [ { "name": "string", "value": "string" } ]}

Example 1: The parameters provide access to the specified application.

{ "objects": [ { "application": "${APPLICATION_NAME}", "kind": "ApplicationVersion",

"name": "${APPLICATION_VERSION_NAME}" }, { "applicationVersions": [ "${APPLICATION_NAME}/

${APPLICATION_VERSION_NAME}" ], "description": "", "kind": "Release", "memberParties":

[ "[email protected]" ], "name": "${RELEASE_NAME}", "ownerParties": [ "[email protected]" ], "version":

"${RELEASE_VERSION_NAME}" } ], "parameters": [ { "name": "APPLICATION_NAME", "value": "Sample Application

1" }, { "name": "APPLICATION_VERSION_NAME", "value": "1.1" }, { "name": "RELEASE_NAME", "value": "Julie

Wilson's Sample Release" }, { "name": "RELEASE_VERSION_NAME", "value": "1.0.1" } ]}

Example 2: The parameters provide secure access to the BlazeMeter endpoint capabilities.

], "name": "Blazemeter", "kind": "Endpoint", "type": "BlazeMeter", "parameters": { "apiKeyId":

"0248cb489fd1a1ba731de0f6", "authType": "Advanced", "url": "https:\/\/a.blazemeter.com" }, "plugin":

"BlazeMeter\/2.1" },

Example REST Call: Import from File

/dsl-manifest/attachment

Imports a file and creates a manifest.

Resource URL

Type Description

GET https://<host>:<port>/cdd/administration/0000/v1/dsl-manifest/atta

chment

Method Parameters

Parameter Type Description

file Undefined file

Response Parameters

HTTP Status Code Reason

201 Created

Continuous Delivery Director 8.5

401 Unauthorized

403 Forbidden

404 Not Found

Curl

curl -X Get --header "Accept: application/json" "http://<host>:<port>/cdd/design/0000/v1/dsl-manifest/

attachment"

Response Body

[{

"Kind": "Application Version",

"ID": "3505453"

{

"Kind": "Release Token",

"ID" :"2345656523"

{

"Kind": "Release",

"ID" :"23"

{

"Kind": "Phase",

"ID" :"11"

{

"Kind": "Phase",

"ID" :"12"

},{

"Kind": "Phase",

"ID" :"13"

{

"Kind": "Task",

"ID" :"122"

},{

"Kind": "Task",

"ID" :"123"

{

"Kind": "Task",

"ID" :"124"

{

"Kind": "Task",

Continuous Delivery Director 8.5

"ID" :"125"

}]

Response Code

200

Response Headers

{

"hostname": "server-4-3h6qp",

"date": "Wed, 14 Mar 2018 12:25:00 GMT",

"server": "nginx/1.11.10",

"connection": "keep-alive",

"transfer-encoding": "chunked",

"x-upstream": "10.131.0.178:8080",

"content-type": "application/json;charset=UTF-8"

}

Release Management

This section provides information about how to manage releases, phases, and tasks during release design and execution.

Permissions to execute release activities are role-based. For more information about roles and associated release

activities, see User Permissions and Activities.

More Information:

•

Manage Releases

•

Manage Phases

•

Manage Tasks

Manage Releases

To help manage your Continuous Delivery Director releases during and following release design, use the following

information and actions.

Start Releases

To start a release, click the Run phase button in the first phase of the release. When a release starts, the status Running

and a power button icon appear at the top of the release.

Phases with a SCHEDULED phase as the first phase of the release start automatically at the scheduled time.

Complete Releases

To complete a release, click MARK AS DONE next to the Running status at the top of the release. If phases are running

in the release when you click MARK AS DONE, a message opens to confirm that you want to stop the release.

Note: When you mark a release as Done, the release is permanently in a read-only status and cannot be edited. For more

information, see Release Execution.

Continuous Delivery Director 8.5

Edit Releases

To edit a release, open the release and click the pencil icon next to the release name. You can also use the keyboard

shortcut alt+shift+r to edit a release.

Note: Use the question mark (?) key to show and hide a list of keyboard shortcuts.

Edit a release to change the main release properties, such as name, version, and applications.

Important If you remove an application from a release, all endpoints mapped to this application from the release are also

removed.

Delete Releases

Administrators can delete releases from the RELEASES page.

Follow these steps:

1. Click and highlight the release field in the RELEASES page.

2. Click the trash can icon at the top right of the page, and click Delete.

Duplicate Releases

After you execute a release, you cannot execute the release again. To reuse releases, use the Duplicate Release

functionality.

To deploy the next version of a release, duplicate the release, change the version number, and edit the release content.

If you duplicate a release, you are prompted if permission conflicts exist. The message contains instructions for resolving

the conflicts.

Note: When you duplicate a release, new application versions are automatically created for each application mapped to

the source release. The settings (work item source, dependencies and source control connection) are copied from the

original application versions to the corresponding application versions in the new release.

Follow these steps:

1. Click and highlight the release field on the RELEASES page.

2. Click the duplicate icon in the upper right.

3. Edit the target release name and click Save.

The release is duplicated. The duplicate release shows on the RELEASES page as a copy, and the Design page

appears for the release.

Duplicated releases include the following content:

•

Phases

Note: Duplicate phases include scheduled dates and times for scheduled phases.

•

Tasks

•

Stakeholders

•

Tokens and token values

•

Application versions

Application versions are duplicated to retain the connection between the application and the promoted tasks. Duplicated

application versions are named <original version> - Copy. Application content must be added to duplicate releases.

If you duplicate a release that is part of a Release Track, the status of the duplicate release defaults to Manual in the

production phase.

Continuous Delivery Director 8.5

Filter Releases

You can filter the releases list on the RELEASES page to display only relevant releases. This capability is especially

useful if you manage a large number of releases. You can filter releases by:

•

Date created

•

Last activity

•

Releases that you own

•

Only releases created from parameterized DSL

•

Status

You can also sort the following columns in ascending or descending order:

•

Release name

•

Date created

•

Last activity

Release Roles

For each release, the release manager assigns the following roles:

Owner

•

Release Owners can be one or more users or user groups.

•

Release Owners must be authorized to access the endpoints, applications, and environments that are part of the given

release. When you save a release, you are prompted if permission conflicts exist. The message contains instructions

for resolving the conflicts.

•

A Designer product role is required to be assigned as a release owner.

Note: Assigning a release owner is not mandatory. The user who creates the release is assigned as the default owner.

Member

•

Release Members can be one or more users or user groups.

•

Assignment to one of the product roles is required for release membership.

•

You can only assign members to releases who are authorized to access the applications that are part of the given

release. When you save a release, you are prompted if permission conflicts exist. The message contains instructions

for resolving the conflicts.

Note: A release is created with no members by default. A release can exist without members.

Release owners and members are listed in the expandable Stakeholders section on the left of an open release. You can

edit members and owners for a release.

Follow these steps:

1. Click the release name in the RELEASES page to open the release.

2. Click the pencil icon next to the release name.

3. Edit the members and owners.

Note: Add users in User Management on the ADMINISTRATION page.

4. Click Save.

For more information about roles, see Manage Users, Groups, and Roles.

Mark a Release as Done

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

Continuous Delivery Director 8.5

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to mark a release as done in Continuous Delivery Director and describes the different statuses you

can assign to the release.

Duplicate Releases

You can save a considerable amount of setup time by duplicating existing releases.

You have been granted the Can create release permission.

A duplicated release inherits the settings, phases, and tasks of the existing release.

1. On the RELEASES page, select the required release row, then click the Copy icon.

The DELETE RELEASE dialog opens.

2. Review and edit as needed the following fields to configure the duplicate release:

•

Release Name

Specifies the name of the release.

•

Version

Specifies the release version. Use the version number to correspond to the release number, sprint number, or any

other important differentiator.

NOTE

The version is a required property. Versions are important to differentiate multiple release versions.

•

Description

(Optional). Specifies a description of the release details.

NOTE

This field allows you to format the description text. You can also add links to external systems, resources,

and references that are specific to the release.

•

Application Type

Select either Application or Business Application.

Application

–

Applications

Indicates applications that are linked to the release. Add any application to the release that you plan to deploy or

act on in some other way. You can only view and assign applications that you are authorized to access.

IMPORTANT

You cannot create a release without at least one assigned application. For more information, see

Applications and Environments.

–

Business Application

Add a business application to the release that you plan to deploy or act on in some other way. You can only view

and assign business applications that you are authorized to access.

NOTE

The business application version is set to the version in the existing release. If the business application

version does not exist, a version is created.

•

Owners

Specifies users who own and can configure the release.

NOTE

The release creator is the default release owner.

•

Members

Continuous Delivery Director 8.5

Specifies users who can be assigned release tasks. Users can only see releases that they are members of.

Owners of release components are automatically added as release members and can view the entire release.

NOTE

You can only add owners and members from the users and groups that exist in Continuous Delivery

Director. For more information, see Manage Users, Groups, and Roles.

For more information about the difference between release owners and members, see User Permissions

and Activities.

3. Select Save.

The duplicated release is listed on the RELEASES page.

Release Risk Score

You use the release score to quickly assess release readiness for production deployments. In this way, you can prevent

low-quality code from being delivered and exposed to your customers.

You can determine release health, risks, and quality at a glance, based on metrics collected during the development and

delivery lifecycle.

You view the release score in the RELEASES page. The release score appears as a scale on the right in a release row

and is graded from A (highest) to E (lowest) in increments of 20%:

A: 0-20%

B: 21-40%

C: 41-60%

D:61-80%

E:81-100%

An Continuous Delivery Director release can consist of multiple applications to be delivered to production. The release

score that appears at the release level is based on the metrics for all release applications. The release score is

automatically updated whenever one of the underlying metrics changes.

Release score updates can occur as a result of a change in the source control (such as new commits, or the addition to or

removal from the release of applications and application versions).

You can choose how Continuous Delivery Director calculates a release score:

•

Continuous Delivery Director calculates the average of all the metrics

•

Continuous Delivery Director calculates the release score based on the worst-case metric score

You configure the calculation method by editing the following properties in settings.properties:

settings.properties

=======================================

# algorithm can be worstMetric or averageOfMetrics}

cdd.release.score.algorithm={worstMetric,averageOfMetrics}

=======================================

To view the underlying metrics, click the A-E scale in the release row.

Continuous Delivery Director 8.5

Figure 5: Release score in release row

The metrics that are shown are:

Test Coverage - Test coverage of source files that have changed during the release.

Continuous Delivery Director includes a .NET coverage agent that registers code coverage data. The agent maps

modified .NET (C#, Visual Basic, and so on) source code files to test suites and runs the relevant tests only. For each

executed test suite, the agent collects the list of source code files covered.

•

Calculation: Percentage of the number of changed source files that were covered by tests*100 / total number of

changed source files during the release. The higher the score, the better.

•

No data available: Possible causes - None of the application source files were changed during the release; no

continuous testing agent reports for this application.

•

Example: 1 (files with test coverage) / 2 (total number of files that have changed during the release) = 50% (C)

Flaky Tests - Test suites with inconsistent/unstable results during the release.

•

Calculation: Percentage of the number of flaky test suites*100 / total number of test suites that were executed during

the release. The lower the score, the better.

•

No data available: Possible causes - Test module (CDI) is inactive.

•

Example: 4 (number of flaky test suites) / 14 (total number of test suites) = 29% (B)

Code Churn - The number of commits in the last week. A large number of commits indicates code volatility. Measuring

the rate of code change is especially relevant in the week before the end of the release. At this point in time, the codebase

should be stable.

•

Calculation: The number of commits / the number of days. The higher the score, the better.

•

No data available: Possible causes - No commit source (source control connection) is configured.

•

Example: If 3 files changed, 3 are counted; if the same file changes 3 times, 3 are counted.

(A) = 0-5 files have changed in the week before release end

(B) = 6-10 files have changed in the week before release end

(D) = 16-20 files have changed in the week before release end

(E) = More than 21 files have changed in the week before release end

You can change the code churn configuration in settings.properties:

cdd.release.score.code_churn.period_in_days=7

cdd.release.score.code_churn.0.risk=5

cdd.release.score.code_churn.1.risk=10

cdd.release.score.code_churn.2.risk=15

cdd.release.score.code_churn.3.risk=20

Incomplete Work Items - The percentage of the planned work items (such as user stories, defects) in the ALM tool (such

as Rally, Jira) for the release applications that are not marked as completed/accepted.

Continuous Delivery Director 8.5

•

Calculation: Percentage of the number of incomplete work items*100 / total number of work items for the release. The

lower the score, the better.

•

No data available: Possible causes - No work items have been imported from the ALM tool into Continuous Delivery

Director.

•

Example: 38 (number of incomplete work items) / 50 (total number of work items) = 76% (B)

Figure 6: Metrics for release scores

The release score, in this example, C, is the average of the percentage score of each of the following three metrics: Test

Coverage, Flaky Tests, and Incomplete Work Items:

29 + 50 + 76 = 155

155 / 3 = 51.66% (C)

You can filter to see only the top issues affecting the release applications that require urgent attention:

Figure 7: Top issues affecting release score

You can also view the scores for all release applications:

Continuous Delivery Director 8.5

Figure 8: Release scores for all applications

You can also see the release complexity which refers to the number of applications in the release. This metric does not

affect the release score. Additionally, you can see the number of builds and whether this release is assigned to a track.

Figure 9: Release complexity metric

Additionally, you can see the release score when you open a release.

Figure 10: Release score display when release opens

Release Activities and Release Score

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to view release activity in Continuous Delivery Director and see the overall release score. The

release score gives the release a grade based on several indicators that can derive the overall quality of the release.

Manage Phases

Phases represent different environments that are part of your release. Use the following information and operations to

manage release phases during release design and execution.

Continuous Delivery Director 8.5

Phase Information

You can view the phase status in the Release page.

Phase statuses include:

•

Never run

•

Running

•

Failed to run

•

Paused

•

Stopped

•

Running with failures

•

Done with failures

•

Done

A timestamp is also shown.

See the following screenshot for the state transistion during the phase execution.

Phase Operations

The following operations are available in the phase actions menu at the top right of the phase box:

•

Add Task

Add a task to the phase.

•

Edit Phase

Change the phase properties that you enter when you create the phase.

Note: You can also click a phase in the Release Calendar to open the Edit Phase window.

Continuous Delivery Director 8.5

Important: If you remove an environment from a phase, all endpoints mapped to this environment from the release are

also removed.

•

Enable/Disable Phase

Enable/Disable a phase.

•

Duplicate Phase

Duplicate the phase for use elsewhere in the release.

•

Delete Phase

Delete the phase from the release.

•

Pause Phase

Pause the phase while running. A phase is paused immediately upon completion of the running tasks.

•

Resume Phase

Resume the paused phase, the subsequent tasks start running.

•

Request approval

Sets a phase to require approval before execution.

Phase Gates

When you create a phase, you set the phase gate to specify how the phase is triggered to run. You can configure phases

with the following phase gates:

•

Manual (default)

Runs the phase when you click the phase run button.

•

Automatic

Runs the phase when the previous phase is complete. Automatic phases that are the first phase in a release must be

started manually.

•

Scheduled

Runs the phase automatically at the scheduled time.

Note: The run phase button overrides Scheduled and Automatic phase gates.

You can also edit a phase gate for existing phases.

Follow these steps:

1. Click the edit icon in the phase actions menu.

2. Under CHOOSE HOW YOU WANT THE PHASE TO RUN, select the phase type (Manual, Automatic, or

Scheduled).

Note: For Scheduled phases, also specify the From and To times. For automatic and manual phases, you can specify

the estimated From and To times.

3. Click Save.

Phase Approval

Release owners can specify that a phase requires manual approval before the phase runs. The owner of the phase

receives an approval notification email before this phase is executed.

Phases that are set to Request Approval require approval before every execution. If you duplicate a phase that is set to

Request Approval, the duplicate phase is also set to require approval before each execution.

For more information, see the Create Phases section of Design and Create Releases.

Disable Phase

You can disable a phase, and the disabled phase does not get executed.

You cannot disable a phase that is mapped to a production stage or a milestone in a track.

Continuous Delivery Director 8.5

The disabled phases cannot be approved/disapproved.

When the first phase is disabled and a build notification arrives, CDD ignores the phase and does not auto-start the

release.

When importing a DSL with "runOnCreation = true and the first phase is disabled, CDD ignores the phase and does not

auto-start the release

If a scheduled phase is disabled, on the scheduled time, the phase starts and fails with the "fail to start" status. If a

recurrent phase is disabled, the next run does not get calculated as long as the phase is disabled. Once the phase is

enabled, the next run date is calculated.

When an on-failure phase is disabled, failures are managed as if an on-failure phase does not exist.

You cannot disable a phase which requires approval and is approved.

Phases Errors

Running with Errors

If failures are detected during phase execution, a red dot next to the Run button indicates Phase Running With Errors.

The red error indicator also appears in the RELEASES window status column while the release is running.

Done with Errors

If a phase is stopped or skipped while Running With Errors, a green checkmark icon with a red dot displays in the phase

as a reminder of the phase errors.

Failed to Run

If a phase did not initiate, a red triangle

next to the Run button indicates Failed to Run.

Possible causes:

•

A token is missing a value.

•

There are missing details in the CREAT/EDIT PHASE form.

The red triangle error indicator also appears in the RELEASES window status column while the release is running.

Approve Phase Execution

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how you can use approval gates to require approval before executing the next phase in a Continuous

Delivery Director release.

Create On-Failure Phases

You can create special phases to run in the event that errors are detected in another phase.

100

Continuous Delivery Director 8.5

•

In a release, decide which phases require on-failure phases

•

Plan the tasks to initiate when the on-failure phase starts to run

On-failure phases initiate only when errors are detected in an associated phase. Additionally, you can start on-failure

phases manually.

NOTE

A phase with errors that initiates an on-failure phase is called a trigger phase.

You can configure tasks to initiate on-failure activities such as sending release error notifications to release owners,

stopping builds, and so on.

1. In a release, from the trigger phase toolbar, select Create On-Failure Phase.

The CREATE ON-FAILURE PHASE dialog opens.

2. Specify a phase name, environments, and the phase to trigger the on-failure phase.

3. Optionally, select Run Tasks with Updated Applications Only. This option lets you run only those tasks that are

mapped to applications that have changed since the last deployment on the phase environment.

4. Click Create.

5. From the trigger phase, select Show On-Failure.

6. Select Create a Task at the bottom of the on-failure phase box. You can also select the Add Task icon in the phase

toolbar to create new tasks.

7. Specify the required properties and select Create.

The task is saved and assigned to the on-failure phase.

Create an On-Failure Phase

On Failure Phase Execution

NOTE

The following videos are extracted from the Release Orchestration training course.

This course provides extra information, context, and examples to augment the product

documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to create an On Failure Phase in a Continuous Delivery Director release. An On Failure

Phase only runs when a primary phase fails to complete and can be used for operations like rollbacks. This

video shows how an On Failure phase executes when a task fails in a Continuous Delivery Director release.

Manage Tasks

Tasks represent the relevant workflow inside each release phase. Use the following information and operations to manage

release tasks during release design and execution.

View Task Information

You can hover over tasks in the Releases page to view task details.

Task-related information that is shown in the Releases page includes:

101

Continuous Delivery Director 8.5

•

Status

•

Task Type

•

Start and end time

•

Duration

•

Endpoint

•

Plug-in logo

•

Application name

•

Environment

•

Build number

Task Operations

Use the task actions menu to configure tasks. To open a task actions menu, click the task actions menu icon at the top

right of the task.

The task actions menu contains the following operation icons:

•

Edit Task

Opens the edit task dialog.

•

Disable/Enable

Disables and enables a task. When you disable a task, the release execution process skips the task.

•

Duplicate Task

Duplicates the task for uses elsewhere in the phase or in other phases.

•

Delete a task

To delete a task, select the task and click on the trash icon in the actions menu.Note: If the task is the only task in

a container, also delete the container.

Other task management operations include:

•

Order Tasks

To move tasks within and between phases, drag-and-drop the tasks.

•

Operations on multiple tasks

To perform operations on groups of tasks, hold Shift or Ctrl and click the tasks.

•

Run tasks in parallel

To group tasks to run simultaneously, drag-and-drop tasks together. This action groups the tasks in a single parallel

container in the phase. You can drag tasks out of, and can drag more tasks into, parallel containers.

Note: When all the tasks in a parallel container are complete, the task that follows the container runs.

During the design phase, all tasks show a status of Design.

Duplicate Tasks

You can duplicate tasks to reduce the amount of manual labor during the release creation process.

You can duplicate tasks to share the task properties and reduce effort. Depending on your preferred method of release

design, you can either:

•

Populate the phases with tasks as you create each phase

•

Create all phases first, then populate each phase with tasks

102

Continuous Delivery Director 8.5

TIP

•

If phases have similar tasks, create the tasks in the first phase, duplicate the phases, and edit the duplicates

•

Use tokens in tasks where the values can change or for multiple tasks that might share the same values

•

Drag and drop tasks between phases

1. In a release phase, select a task.

2. Click the task fly out menu, and select Duplicate Task.

3. Change the task properties as needed, such as the application name, tokens, and so on.

4. When done, click Duplicate.

Duplicate a Task

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to duplicate a task in a Continuous Delivery Director release. Duplicate tasks to reduce

effort during release design and creation.

If needed, drag and drop duplicated tasks to the required position in the phase.

Release Execution

Continuous Delivery Director lets you execute multi-application releases using a dynamic interface that provides instant

feedback on progress and results. The Continuous Delivery Director interface lets you closely monitor each task and

phase of the release. The interface lets you fix errors, stop tasks, skip tasks, and move to the next phase at any time.

Release execution is automated and interactive in key ways to give you an appropriate level of oversight in all scenarios.

This page provides a general framework to move through the execution of a release. The sequence of events is

different for every release.

NOTE

To run phases and execute releases in the on premise version, a product license key is required (not required

for SaaS). For more information, see Administration.

Run Individual Releases

After you build a release, the release displays the status DESIGN at the top next to the release name. The release phases

run based on the phase gates, the task types, and manual input from users.

For more information about phase gates, see Create a Phase in Release Design.

Release execution starts based on the phase gate of the first phase in the release. You can set one of the following phase

gates:

•

Manual

Runs when the release owner manually starts the first phase of the release.

Note: The phase Run button overrides the scheduled phase gate.

•

Scheduled

Runs at the scheduled time of the first phase of the release.

•

Automatic

Runs at the time that is specified in the first phase of the release.

103

Continuous Delivery Director 8.5

Note: You can also set phases to require manual approval before execution. For more information see the Create

Phases section in Design and Create Releases.

Follow these steps:

1. (On-premise only) Enter the Release license key information if you have not yet applied your product license.

2. Click the run icon in the first phase, or wait for the scheduled execution for the first phase to start. If the phase if is set

to Request Approval, click the Approve Phase icon in the phase.

Note: Release phases and tasks are locked from editing during execution.

The status of the release changes to RUNNING and the status of the first task in the phase changes as follows:

–

Manual tasks change to PENDING.

–

Automatic tasks automatically run and provide feedback as to whether they succeeded or failed.

The statuses of other tasks in the phase change to READY.

3. (Manual task) Open the toolbar in the first task and click the run icon.

Note: The manual task owner or release owner can carry out this step. While multiple people can manage

the tasks assigned to them, this procedure assumes that a single person manages the execution.

The task starts to run and the status changes to RUNNING.

4. Perform one of the following actions for each manual task:

–

View

Opens the task in a separate window.

–

Fail

Fails the task. A task failure does not automatically stop the release. The release owner can continue with ensuing

tasks or can stop the phase to fix the cause of the failure.

Note: If an automatic task fails, an error appears. This error either matches the input you would receive from the

remote component or indicates an error with the task itself. Mouse over the status of a failed task for details.

–

Skip

Stops the task and skips to the next task. To continue with the other tasks, skip the failed task. Also, disable tasks

that you want to automatically skip in the execution workflow. You can skip a failed automatic task but cannot mark

it Done.

–

Done

Completes the task.

When each task is skipped or done, the next task status changes to PENDING for manual tasks or automatically starts

running for automatic tasks.

5. Continue through the task workflow in the first phase. You can stop and adjust the phase at any time. For example:

In the event of a failed task, stop the phase, fix the problem, reconfigure the tasks, and restart the phase. You can

disable or enable tasks that have already passed, skip tasks for any reason, and mark manual tasks as done. As you

move through the task workflow, the phase progress bar at the top of the phase updates. The progress bar is based on

task completion. When all tasks in the phase are complete, the phase moves out of the RUNNING state. Depending

on the gate of the next phase, move through all phases and repeat the previous steps.

–

If the gate is automatic, the next phase starts automatically.

–

Phases with scheduled or manual gates start when the release owner manually starts the phase, or at the

scheduled time.

6. Adjust to task resolutions as appropriate. You can stop releases anytime to make edits and to reconfigure tasks. You

can also rerun the entire release or parts of the release. The process is flexible and accommodates any situation.

Re-run Tasks

If a task fails during a phase execution, you can re-run that task. If necessary, you can make changes before you re-rerun

a task.

You can re-run a task multiple times. When a task re-runs, an email is sent to the task owner (same as when a task runs

for the first time).

104

Continuous Delivery Director 8.5

Task re-runs are displayed in the Release Analysis report. Each task re-run appears on a separate row per execution.

NOTE

If you skip or stop the phase execution, you cannot re-run a task.

Follow these steps:

1. In the task phase, click the failed task name or select Edit Task from the task menu.

The Edit Task dialog opens.

2. Make any required changes, and click the Re-Run Task button.

Any changes you have made are saved and the task runs.

Note: When a task is rerun, the token value used is always the value that is used when the phase is executed for the

first time. Any changes to the token value after phase execution begins are ignored.

Example: Phase execution is initiated at 14:00 when the last_successful_build number is 45. A phase task fails

at 14:30. A new successful build, number 46, completes at 16:00. When the phase task is rerun at 17:15, the

last_successful_build number used is 45, and not 46.

Mark Releases as Done

Releases that are marked as Done become read-only. Only mark releases as done if

the release is complete. To reconfigure and rerun releases, duplicate the release, set new properties and versions, and

execute the new version.

You can either mark releases as Done manually or automatically.

Manually Mark as Done

When all tasks in all phases are complete, select MARK AS DONE next to the release status of RUNNING.

Automatically Mark as Done

As a release owner or administrator, you can configure releases to be marked as Done automatically when the last phase

or a selected phase is completed successfully.

From the release page, select Mark Release as Done when Phase is Completed, and select a phase.

When the selected phase is completed successfully, Continuous Delivery Director waits for a specified interval to run

checks, then automatically marks the release as Done. You can modify that wait interval (default = 30 seconds) by editing

the following value in settings.properties :

settings.properties

========================================================

cdd.release.mark_as_done.phase_end_wait_time=30

========================================================

A release is not automatically marked as Done if:

•

If the selected phase is stopped

•

If there are other phases running when the selected phase is completed

When duplicating an existing release, the mark as Done configuration is copied from the original release (including the

phase that defines when to mark as Done).

If the phase selected to mark the release as Done is deleted, that release returns to manually mark as Done.

You can select a phase that is running.

You can configure a release that is part of a track to be marked as Done automatically when the track is Done. The

selected phase must not be set to run after the Production time frame ends.

105

Continuous Delivery Director 8.5

Release Statuses

You can select a release status and add free text comments after a release is marked as Done.

From the release page, select the required status from the dropdown list. The following statuses are available

•

Success

•

Failure - Deployment Issues

•

Failure - Performance Issues

•

Failure - Environment Issues

•

Failure - Functional Issues

•

Failure - General

•

Not in use

The selected status is displayed inside the release and in the releases list.

You can also add a free text comment.

A release that is marked as Done automatically is assigned the Success status.

If you duplicate a release, the release status is not copied to the new release.

Execute Multiple Releases in Bundles

You can also bundle multiple releases together into Release Tracks to the bundled releases into production together. For

more information, see Release Tracks.

More Information:

•

Monitor and Troubleshoot Release Execution

•

Activity Panel

•

Release Notifications

•

Track Planned vs Actual Work

•

Release Risk Score

•

Rollback Management

Monitor and Troubleshoot Release Execution

Continuous Delivery Director provides detailed release information and metrics to help you monitor release progress and

troubleshoot problems.

The following tools are available to help monitor and plan releases:

Phase Progress Bar

The progress bar at the top of the phase indicates the phase progress. The bar is divided into increments that equal the

number of tasks in the phase. The progress bar moves as each phase is complete.

Dependencies

Application dependency conflicts appear in the context of a phase as an orange icon next to the phase name. When you

define application dependencies, Continuous Delivery Director checks across releases to see whether the dependencies

are met. The orange icon indicates a dependency conflict when both of the following cases are true:

•

The application dependency is not currently deployed in the same environment as the dependent application.

•

The application dependency is not scheduled to deploy to the same environment as the dependent application in any

phase scheduled for before the dependent application phase.

106

Continuous Delivery Director 8.5

When you click the orange icon, the DEPENDENCIES CONFLICTS box opens and shows the conflicts.

Edit the deployment order or times to address the conflicts so that the dependency deploys, or is scheduled to deploy,

before the dependent application.

Click Sync Conflicts to ensure that the conflicts are resolved.

Task Status

During task execution, tasks display the task status at the bottom of each task with the following icons.

Note: You can use the task toolbar to change a task status during execution.

•

Design

Indicates that a task is not running.

Note: Design is the default status for new tasks.

•

Running

Indicates that the task is in progress.

•

Ready

Indicates that the phase is running and that the task is ready to run.

•

Pending

Indicates that the task is ready to run.

Note: This status is only for manual tasks.

•

Stopped

Indicates that the task stopped before or during execution.

•

Failed

Indicates that a task failed.

Notes:

–

When a task fails, the execution stops. Click Skip to start the next task.

–

When a task in a parallel container fails, other tasks in the container continue to run. The tasks run until all tasks in

the container are complete.

•

Skipped

Indicates that the task was manually skipped and that the next task starts.

•

Missing Details

Indicates that required task fields are not complete, which would prevent the task from running successfully. When you

see a Missing Details indication on a task, the Run button is disabled until you add the missing information.

•

Disabled

Indicates that a user disabled the task. You can disable tasks before the phase run begins.

•

Done

Task ends successfully.

Activity Panel

The activity panel displays release activity on the right side of an open release, including:

•

Execution events, such as phase start, task start, and task completion

•

Error messages

•

Warning messages

•

Notes and events that users enter manually

•

When a release is added to, and is removed from, a release track.

For information about how to use the Activity Panel to monitor and troubleshoot releases, see Activity Panel.

107

Continuous Delivery Director 8.5

Indication Panel

The Indication Panel shows in the top right of a release. The panel also shows on the Dashboard tab in the Running

Releases Health Widget. Color panel icons indicate the following release events:

•

Pending tasks

Click the pending task indicator to view a list of pending tasks. Click a task to locate the task.

•

Errors

Click the Error indicator to show error details.

•

Warnings

Click the warning indicator to show error details. To dismiss the warning, click the gavel icon in the warning.

The panel is activated when the release starts to run.

Release Calendar

Continuous Delivery Director includes a configurable, interactive release CALENDAR that provides a high-level, real-time

calendar view of all planned and running releases.

For more information, see Release Calendar.

Release Track Timeline

The following tools let you monitor releases that are bundled into release tracks for execution together:

•

Release track interactive timeline on the Tracks page

•

Release miletones

•

Release notifications

For more information, see the Release Track Timeline section at Release Tracks

Activity Panel

Use the Activity panel to enter and monitor release activities, and to identify and troubleshoot release issues.

The panel is updated in real time with the following release events:

•

Design events

•

Execution events

•

Error messages

•

Warning messages

•

User Activity and text that users enter manually.

The Activity panel opens on the right side of the RELEASES page when you open a release. Release participants also

receive email notifications of activity.

TIP

Click the arrow at the top right of the Activity panel to collapse the panel. When you are not monitoring release

activity, collapse the panel to provide more screen space for activities like release design.

Activity Types

The Activity panel displays release activities to all users in real time. The following activity types are displayed in the

panel:

•

System

Indicates automatic changes in the release. System activities are generated for the following release events:

108

Continuous Delivery Director 8.5

–

Task Ended

–

Task Executed

–

Task Skipped

–

Task Continued

–

Phase started

–

Phase ended

–

Release Done

–

Release added to a track

–

Release removed from a track

–

Release status, including comments

–

Release marked as Done automatically

–

Release waiting because parent track is not Done

•

User

Indicates release activities that users run manually, and release activity text that users enter.

Note: Manually add user activities to make notes, and for notification and collaboration.

•

Error

Indicates that the status of a task is changed to Failed.

•

Warning

Indicates warning messages for the release. Warning messages are generated for the following events:

Execution Events:

•

A scheduled phase does not start at the estimated time

•

A scheduled phase continues to run after the estimated end time

•

A phase gate that the system changes from Automatic to Manual

•

A phase stops

•

A task stops

Other Events:

•

A scheduled phase does start at the estimated time

•

An environment that is assigned to the phase is deleted

•

A user who is the phase owner is deleted

•

A user who is the task owner is deleted

•

A user who is the release owner is deleted

•

An application that is assigned to the release is deleted

•

A release is added to a release track

•

A release is removed from a release track

Filter Activities

You can filter activities in the Activity Panel by activity type or a specific selection.

To filter by activity type, click the filter icon and select from the following activity types:

My Activities

Activities that are entered manually

Error Activities

Errors in the release

Warning Activities

109

Continuous Delivery Director 8.5

Warnings of activities that are potential problems

Info Activities

Changes in the release

Application and Content Version

Changes or edits to application and content versions

To filter the Activity panel to show only a phase or task that you select, click the Filter by Selection box and select a

phase or a task. The panel filters to show only activities for a selected phase or task.

Add Activities

To make notes and enhance collaboration, you can manually add activities to the Panel.

Follow these steps:

1. Click the plus sign at the top of the Activity Panel and click Type your activity text.

2. Enter the activity text in the dialog, and click the Add icon.

Note: Activities that are added manually are indicated in the Activity Panel next to the user initials.

Add Custom Activities with REST API

You can add custom activities to the panel to the panel using a REST API call.

Follow these steps:

1. In Continuous Delivery Director, click the user initials icon, then REST API.

2. Under DESIGN, navigate to activity, then POST /releases/{releaseId}/activities.

3. In releaseId, enter the relevant release number.

4. In activityDto, enter the following:

{

"id": null,

"content": {

"className": "ActivityContentDto",

"contentValues": {

"content": "<ENTER THE ACTIVITY CONTENT HERE>"

"contentTemplate": "manualContent"

"releaseId": <ENTER THE RELEASE ID HERE>,

"className": "ActivityDto"

}

Release Activities and Release Score

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to view release activity in Continuous Delivery Director and see the overall release score. The

release score gives the release a grade based on several indicators that can derive the overall quality of the release.

110

Continuous Delivery Director 8.5

Release Notifications

Continuous Delivery Director provides your stakeholders with email notifications for release activity and status changes.

Notifications

Email notifications are sent to the owners of releases, release tracks, phases, and tasks for release activities in the

following categories:

Note: For release tracks, the owner of the track and the owners of the releases in the track receive notifications. The

creator of the track is the track owner.

•

Information

Changes in the status of releases, release tracks, phases, and tasks

•

Warning

Problems in releases, phases, and tasks such as missing details or usual behavior

•

Error

Errors that occur in releases, phases, and tasks

Note: Email notifications for errors contain specific error messages and relevant error details.

Notification emails include the following information:

•

Specific release components (Phase, task, or release track)

•

Release name

•

URL that links directly to the relevant release

Disable Notifications

Users receive email notifications by default. To remove your account from release notifications, disable the notification

feature.

Follow these steps:

1. Click the icon with the initials of the logged in user in the top right of the UI.

2. Select User Settings in the drop-down list.

3. Click Preferences in the left panel.

4. Clear the Get email notifications box.

Email notifications for the user are disabled.

Track Planned vs Actual Work

You can track planned vs actual work in releases through a four-way integration between Continuous Delivery Director, a

source version control system, Jenkins, and an ALM (application lifecycle management) tool.

This integration helps you manage and optimize the flow of business value throughout the release cycle.

NOTE

•

ALM tool: Both Rally

(formerly CA Agile Central) and Atlassian Jira are supported.

•

Source version control: Both GitHub and Bitbucket are supported.

The Problem

Release managers are required to ensure that the business value delivered at the end of a release matches the objectives

agreed during release planning. However, looking at the status of work items in your ALM tool, for example, Rally, is not

111

Continuous Delivery Director 8.5

enough to track the execution of features and capabilities. Some of the disadvantages of working solely with ALM tools

are:

•

Statuses in the ALM tool might not be up-to-date.

•

Time and effort remaining to deliver planned features is not obvious.

•

Difficulty of assessing the risk to the release.

•

Lack of clarity regarding work-in-progress and understanding which features have entered the release pipeline.

You must be able to compare planned work to the actual work to manage risks and dependencies and to escalate and

track impediments.

The Solution

Continuous Delivery Director provides an integration that is designed to help release managers keep track of the progress

of releases. This integration involves listening to and analyzing the commit messages that are triggered when developers

commit changes to a GitHub repository.

This integration helps you understand which work items are being implemented, the risk to release execution, and the

probability of delivering the agreed business value on time.

Using this integration, you can:

•

See which work items (features, user stories, defects, and so on) are planned to be delivered in the current release

cycle.

•

View the progress of the actual work items.

•

Observe the work items that enter the release, the work item statuses, and the completed work items.

•

Understand which work items have changes that have entered the pipeline and accordingly determine the work

progress.

Workflow

The Planned vs Actual workflow consists of work item creation, developer commits, build execution triggering build

notifications, and work item ID matching.

The following diagram shows the integration workflow:

112

Continuous Delivery Director 8.5

Key:

1. In Rally (CA Agile Central), project members create work items.

2. In Continuous Delivery Director, a user imports work items from Rally (CA Agile Central).

3. In GitHub, developers commit changed files to the master and add the work item IDs to the commit comments.

4. Jenkins runs a build and gets the new commits from GitHub.

5. Jenkins sends a build notification to Continuous Delivery Director with the commits range.

6. Continuous Delivery Director gets the commit messages from GitHub and matches the work item IDs in the commit

messages to the imported work items. The work item statuses are indicated by icons. For more information, see Work

Item Statuses.

Before You Begin

In Jenkins, ensure that the following prerequisites are enabled:

•

The Continuous Delivery Director plug-in for Jenkins, version 2.0.13 and higher, is configured. For more information,

see Plug-in for Jenkins.

•

The Git plug-in is configured. The Git plug-in ensures that the commit range is included in the change notifications sent

from Jenkins to Continuous Delivery Director. For more information, see https://wiki.jenkins.io.

•

A project in Jenkins is configured with the Git action in the Source Code Management section and Send Notifications

to CDDirector in the post-build section.

Set Up Tracking

After Jenkins is configured, you configure Continuous Delivery Director to enable work item matching.

Follow these steps:

1. In Continuous Delivery Director, set up the latest versions of either the GitHub (1.01 or higher) or Bitbucket (2.0 or

higher) plug-ins, and endpoints accordingly. For more information, see GitHub Plug-in or Atlassian Bitbucket Plug-in.

2. Set up either the Rally (CA Agile Central) plug-in, version 2.2 or higher, or the Jira plug-in, version 1.2.3. or higher, and

an endpoint. For more information, see Rally Plug-In or Jira Plug-in.

3. Create a work item source. For more information, see Import Work Items in Rally Plug-in.

4. Create a source control connection.

This action enables the import of commit messages from your source control. For more information, see Set Source

Control Connection in Design and Create Releases.

Work Item Status Icons

Continuous Delivery Director uses icons are used to highlight the status of work items in the current release:

Videos

Video: Tracking Planned vs Actual Work - Part One

This two-part video explains how a four-way integration between Continuous Delivery Director, GitHub, Jenkins, and Rally

can help release managers track planned vs. actual work in releases. Part One contains an overview and explanation of

work item status icons.

Video: Tracking Planned vs Actual Work - Part Two

Part two of this video shows the setup required to enable the integration between Continuous Delivery Director, GitHub,

Jenkins, and Rally.

113

Continuous Delivery Director 8.5

Release Risk Score

You use the release score to quickly assess release readiness for production deployments. In this way, you can prevent

low-quality code from being delivered and exposed to your customers.

You can determine release health, risks, and quality at a glance, based on metrics collected during the development and

delivery lifecycle.

You view the release score in the RELEASES page. The release score appears as a scale on the right in a release row

and is graded from A (highest) to E (lowest) in increments of 20%:

A: 0-20%

B: 21-40%

C: 41-60%

D:61-80%

E:81-100%

An Continuous Delivery Director release can consist of multiple applications to be delivered to production. The release

score that appears at the release level is based on the metrics for all release applications. The release score is

automatically updated whenever one of the underlying metrics changes.

Release score updates can occur as a result of a change in the source control (such as new commits, or the addition to or

removal from the release of applications and application versions).

You can choose how Continuous Delivery Director calculates a release score:

•

Continuous Delivery Director calculates the average of all the metrics

•

Continuous Delivery Director calculates the release score based on the worst-case metric score

You configure the calculation method by editing the following properties in settings.properties:

settings.properties

=======================================

# algorithm can be worstMetric or averageOfMetrics}

cdd.release.score.algorithm={worstMetric,averageOfMetrics}

=======================================

To view the underlying metrics, click the A-E scale in the release row.

Figure 11: Release score in release row

The metrics that are shown are:

Test Coverage - Test coverage of source files that have changed during the release.

Continuous Delivery Director includes a .NET coverage agent that registers code coverage data. The agent maps

modified .NET (C#, Visual Basic, and so on) source code files to test suites and runs the relevant tests only. For each

executed test suite, the agent collects the list of source code files covered.

114

Continuous Delivery Director 8.5

•

Calculation: Percentage of the number of changed source files that were covered by tests*100 / total number of

changed source files during the release. The higher the score, the better.

•

No data available: Possible causes - None of the application source files were changed during the release; no

continuous testing agent reports for this application.

•

Example: 1 (files with test coverage) / 2 (total number of files that have changed during the release) = 50% (C)

Flaky Tests - Test suites with inconsistent/unstable results during the release.

•

Calculation: Percentage of the number of flaky test suites*100 / total number of test suites that were executed during

the release. The lower the score, the better.

•

No data available: Possible causes - Test module (CDI) is inactive.

•

Example: 4 (number of flaky test suites) / 14 (total number of test suites) = 29% (B)

Code Churn - The number of commits in the last week. A large number of commits indicates code volatility. Measuring

the rate of code change is especially relevant in the week before the end of the release. At this point in time, the codebase

should be stable.

•

Calculation: The number of commits / the number of days. The higher the score, the better.

•

No data available: Possible causes - No commit source (source control connection) is configured.

•

Example: If 3 files changed, 3 are counted; if the same file changes 3 times, 3 are counted.

(A) = 0-5 files have changed in the week before release end

(B) = 6-10 files have changed in the week before release end

(D) = 16-20 files have changed in the week before release end

(E) = More than 21 files have changed in the week before release end

You can change the code churn configuration in settings.properties:

cdd.release.score.code_churn.period_in_days=7

cdd.release.score.code_churn.0.risk=5

cdd.release.score.code_churn.1.risk=10

cdd.release.score.code_churn.2.risk=15

cdd.release.score.code_churn.3.risk=20

Incomplete Work Items - The percentage of the planned work items (such as user stories, defects) in the ALM tool (such

as Rally, Jira) for the release applications that are not marked as completed/accepted.

•

Calculation: Percentage of the number of incomplete work items*100 / total number of work items for the release. The

lower the score, the better.

•

No data available: Possible causes - No work items have been imported from the ALM tool into Continuous Delivery

Director.

•

Example: 38 (number of incomplete work items) / 50 (total number of work items) = 76% (B)

115

Continuous Delivery Director 8.5

Figure 12: Metrics for release scores

The release score, in this example, C, is the average of the percentage score of each of the following three metrics: Test

Coverage, Flaky Tests, and Incomplete Work Items:

29 + 50 + 76 = 155

155 / 3 = 51.66% (C)

You can filter to see only the top issues affecting the release applications that require urgent attention:

Figure 13: Top issues affecting release score

You can also view the scores for all release applications:

Figure 14: Release scores for all applications

116

Continuous Delivery Director 8.5

You can also see the release complexity which refers to the number of applications in the release. This metric does not

affect the release score. Additionally, you can see the number of builds and whether this release is assigned to a track.

Figure 15: Release complexity metric

Additionally, you can see the release score when you open a release.

Figure 16: Release score display when release opens

Release Activities and Release Score

NOTE

The following video is extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to view release activity in Continuous Delivery Director and see the overall release score. The

release score gives the release a grade based on several indicators that can derive the overall quality of the release.

Rollback Management

When an application build fails, you can automatically revert to a previously successful build.

You can use a system token, previous_successful_change, to quickly roll back to the last build that was deployed in

your environment (before the latest deployment). This token is automatically added to each application.

The previous_successful_change token holds the build number that was deployed in the

environment prior to the latest build promotion. The reference to the token appears as <application

name>.previous_successful_change.

You can also use this token in on-failure phases.

The redeployment is run exactly as the failed deployment was run previously with the same parameters.

117

Continuous Delivery Director 8.5

Release Tracks

Overview

The Release Tracks feature enables authorized users to bundle several releases into a track and deliver them to

production together.

Release tracks are created, displayed, and managed in the TRACKS tab in the product UI.

You can view release tracks in a Gantt chart layout. Using Gantt bars, this view shows a list of the releases in your track.

The Gantt chart illustrates the relationship of these tracks to one another, release dependencies, and the schedule.

The Gantt bars show the duration of the production stages across a timeline. You can change the timeline units of time.

You can zoom out to see the bigger view of release tracks by displaying months or weeks, or zoom in to see the exact

start and end dates and times by displaying days or hours. You can also choose a Fit Screen option.

Administrators and authorized users can create tracks.

When a release is part of a track, the following details are displayed in the release:

•

The name of the track that the release belongs to

•

An indication in each phase that is mapped to a milestone including:

–

An indication that the phase is mapped to future milestones.

–

An indication of whether the milestone passed or failed

–

The name and due date of each milestone that is mapped to the phase

Release tracks can contain releases from all projects.

Users with the Can manage track permission can create a track, and delete tracks to which they are assigned as owner.

A track owner can: edit the track (names dates, and so on), and can approve the milestones, production stages and

production phases.

Benefits

Release tracks provide the following benefits and functionalities:

•

Provide the production owner control over multiple release using a central management page.

–

Approve production phase.

–

Remove releases that are not ready for deployment from the track.

•

The Gantt view helps to plan the delivery milestone and stages.

–

Determine the order in which releases are executed.

–

Manage dependencies between releases.

–

Manage Canary Deployments by braking the production timeframe into stages.

•

Govern releases that involve multiple teams across projects to ensure high quality.

•

Track milestones help to monitor the progress and the quality of the releases in the track.

•

Dynamically prioritize the order in which approved releases are sent to production.

Release Track Timeline

Tracks are displayed and executed in an interactive timeline that shows the bundled releases and includes the following

details:

•

Production Time Frame

The time frame in which all the releases that are included in the track are delivered to production. A phase from each

release must be mapped to this time frame. To run, each phase requires the approval of the track owner.

118

Continuous Delivery Director 8.5

As an authorized user, you can approve the phases in the track when all milestones have reached or passed their due

date. You can also approve one or more phases before the production time frame arrives.

Approving a phase in a production stage does not cause that phase to start running unless the following conditions are

met:

•

The stage planned start date has arrived.

•

The stage was approved (in the case stage requires approval).

•

The predecessor stage is completed.

•

The predecessor phase in the stage is completed (if the release is dependent on another release).

You can withdraw approvals, provided the production stage has not started.

•

Production Stage

The production time frame can include one or more stages. A stage is a period within a production time frame in which

a specified production-related activity is scheduled to occur, for example, for each region or data center. Every stage

has a start time and optionally a planned end time. The start time must be within the production time frame.

•

Track milestones

A checkpoint in the track that is mapped to phases in a release. Milestones provide release progress checks and

notifications.

•

Milestone due dates

Milestone due dates must precede the date that the production time frame begins.

You can perform the following actions in the release timeline:

•

Add a release to a track.

NOTE

Releases can join a track as long as the first production stage has not started.

•

Remove releases from a track.

•

Approve production stages and production phases.

•

Add milestones.

•

Remove milestones.

•

Edit the production time range.

•

Schedule all releases to either run simultaneously or in a specified sequence.

•

Approve all phases in a release track simultaneously.

Release Permissions

The following guidelines apply to release track management:

•

Only administrators and authorized users can edit release tracks.

•

The owner of a release can add and remove a release from a track.

•

When releases are added or removed, an email notification is sent to the track owner.

•

A release can only be added to one track.

•

The track owner is the user who can edit and manage the track:

–

Create/change the production timeframe, stages and milestones.

–

Set release dependencies.

–

Approve phases and stages.

•

You cannot mark releases that are part of a track as done while the track is active.

Notifications

Email notifications are sent to release stakeholders for the following release track activities:

119

Continuous Delivery Director 8.5

•

A release is added to a track.

•

A release is removed from a track.

More Information:

•

Create Release Tracks

•

Add Releases to a Track

•

Manage Release Tracks

Create Release Tracks

Release tracks let you group releases for execution as a bundle. Once you create a release track, you can add existing

releases to the track.

Prerequisites: You have been granted the Can manage tracks permission.

NOTE

•

Only a release owner can add a release to a track

•

A release can only be added to one track.

1. Select the Tracks tab.

The TRACKS page opens.

2. Click New Track.

The Create Track window opens.

3. Enter the track name, track owners, and a description of the track.

NOTE

The track Description field allows you to format the description text. You can also add links to external

systems, resources, and references that are specific to the release.

4. Specify the Production Time Frame dates.

Enter stage name.

Optionally:

–

To add milestones to the track, select +Add Milestone and provide the Milestone Name and the Milestone Due

Date.

–

To require milestone approval by the track owner, select the Require Approval option.

–

To require all track milestones to receive approval by the track owner, select the All Milestones Require

Approval option.

NOTE

Phases that are mapped to an milestone that requires approval cannot start running until an authorized

user approves that milestone

–

To add production stages to the track, select +Add Stage and provide the Stage Name. You can specify the

stage planned start date,

–

To require production stage approval by the track owner, select the Require Approval option.

–

To require all track stages to receive approval by the track owner, select the All Stages Require Approval

option.

NOTE

Phases that are mapped to a stage that requires approval cannot start running until an authorized user

approves that stage

120

Continuous Delivery Director 8.5

5. Select Create.

Once you create a release track, the track is displayed in a timeline in the TRACKS page. The track shows the milestones

in the locations of the milestone due dates. You can hover over a milestone icon to display the details.

Create a Release Track

NOTE

The following video is extracted from the Release Orchestration training course. This course

provides extra information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how to create a release track in Continuous Delivery Director. Release tracks let you track

parallel releases that you want to release in the same time window in a single view.

Add Releases to a Track

After a track is created, you can releases to that track.

1. Select Add Release to Track.

The ADD RELEASE TO TRACK dialog opens.

2. Select Release list and select a release from the drop-down list.

3. In the Production Stages panel, select Map To Phase and select a phase from the drop-down list.

You must map at least one stage to a phase.

4. Click Select a phase next to a milestone name and select a phase from the drop-down list.

The milestones are mapped to phases.

5. Click Add.

The release is added to the track.

When you add a release to a track, the phases that are mapped to production stages are changed to Scheduled. The

scheduled date is the stage planned start date or the production date of the track.

If a phase is in a track, you cannot edit the phase, and cannot run the phase from the release.

Manage Release Tracks

You can manage release tracks in the following locations:

•

Inside a track on the TRACKS page

•

Inside a release on the RELEASE page

You can add up to a maximum of 128 releases to a track. To change the maximum number of releases allowed in a track,

in settings.properties, configure the following properties:

cdd.api.pagination.max_page_size = 128

cdd.tracks.maximum_number_of_releases_per_track = 128

Tracks Page

Add a Release to a Track

You can add a release to a track from inside the tracks on the TRACKS page.

121

Continuous Delivery Director 8.5

Manage Tracks

You can perform the following actions inside a release track:

Edit a Track

To edit a track, select the pencil icon next to the track name.

Reorder Releases in a Track

You can schedule releases to run in a specified sequence.

To move a release to a specific place in the sequence, click the Set Dependencies button, and select and drag the

release.

NOTE

•

You can reorder a release after the track is created until the production time frame arrives. Releases can be

reordered regardless of milestone dates or approval status.

Remove Releases from a Track

To remove a release from a track, select the a phase mapped to a stage, click Actions and select Remove Release from

Track.

Following removal of the release from the track:

•

The release no longer appears in the track.

•

All phases in the removed release are reset to Manual.

•

Notification of the removal is sent to the release owner.

•

Removal of the track is reflected in the Activity Panel.

Release Page

Add a Release to a Track

You can add releases to and can remove releases from, release tracks inside a release on the RELEASE page.

Follow these steps:

1. Select a release name.

2. Select the Add to Track option in the release menu.

The Add to Track window opens.

3. Select the track from the drop-down list.

4. Use the drop-down lists to map the Production Stages and Milestones to phases.

5. Select Add.

Manage Tracks

To perform the following actions from inside a release, select Joined Track: <Track Name> in the toolbar and select

the operation from the drop-down list:

•

Remap phases.

•

Go To the track on the TRACKS page.

•

Remove the release from the track.

NOTE

The following videos are extracted from the Release Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

122

Continuous Delivery Director 8.5

To access this course, see Broadcom Enterprise Software Academy.

Add a Release To Track

This video shows how to add releases to a release track in Continuous Delivery Director. It also shows how to map those

releases to production phases and milestones of the track.

Manage Release Tracks

This video shows how to manage the releases, production stages, milestones, and dependencies in a Continuous

Delivery Director release track.

Calendars

A set of calendars offer you visibility about scheduled releases, environment availability, and freeze periods.

The Calendars menu provides the following menu options:

•

Release Calendar displays a timeline of scheduled releases

•

Maintenance Windows shows the periods of time when you can run releases in specified environments

•

Environment Planner helps you to prevent resource conflicts when multiple releases require the same environment

•

Freeze Periods let you prevent deployments from taking place during predefined time intervals

Release Calendar

The calendar acts as a real-time release dashboard with configurations saved per user. Use the calendar to plan resource

use across teams and releases. You can see the Releases in separate lines on the left of the calendar.

You access the Release Calendar from the Calendars tab.

As a release owner or member, you can use the visual release calendar to monitor the following information:

•

Real-time release scheduling and progress during execution

•

Phase with failed tasks

•

Start and stop times for scheduled phases

•

Estimated Start and stop times for automatic and manual phases

•

Environment details

•

Maintenance windows

•

Freeze Periods

•

Failures

•

Conflicts

NOTE

The following conflicts are monitored and are displayed as a red indicator on the left of the phase:

•

Phases are scheduled to exceed maintenance windows

•

Phases are scheduled to run during a freeze period

You can use the following release calendar functionalities to help monitor and manage releases:

123

Continuous Delivery Director 8.5

•

Add Releases – Select one or more releases to include in the calendar view..

•

Select the +/- icons to the left of the release name to expand the release and show the phases, freeze periods and

maintenance windows.

•

Select phases for details.

•

Drag and stretch phases in the release to change the schedule duration and execution times. It is recommended to

change the “View by” from “Fit Screen” to a specific time frame.

•

Select View by <Duration> and select a time frame from the drop-down list to filter the view.

•

Select a phase to open the Edit Phase window and edit phase details.

NOTE

The release calendar displays the disabled phase only if there are past executions.

If there are no executions then the disabled phase is not shown.

Maintenance Windows

If you schedule release phases outside their maintenance windows, warning messages appear.

To manage maintenance windows, you require the Can manage maintenance window permission. From the Calendars

tab, click Maintenance Windows.

In the MAINTENANCE WINDOWS page, you can perform the following actions:

•

Duplicate

Use duplication for environments in separate applications that require the same time frame. Duplicate windows are

also useful when you need multiple windows for the same environments.

•

Edit

To edit, click the required window table row.

•

Delete

•

Enable / Disable

Windows are enabled by default when you create them and appear in the MAINTENANCE WINDOWS and

ENVIRONMENT PLANNER pages. If you disable a window, warnings are not shown when you execute a release

outside of the environment maintenance window. Releases that use a specific environment can only be executed when

the maintenance window is in effect. Warning icons next to the phase name, and in the Edit Phase dialog, indicate that

the phase cannot run until the maintenance window begins. The Release Calendar shows a conflict notification for

items that exceed a maintenance window.

Create Maintenance Windows

You can create maintenance windows for specific environments.

124

Continuous Delivery Director 8.5

Prerequisite: You have been granted the Can manage maintenance window permission.

A maintenance window is a period of time during which one or more teams may release into production on specified

environments.

1. From the Calendars tab, click Maintenance Windows.

2. In the MAINTENANCE WINDOWS page, click Create Window.

3. Enter a name and optionally, a description.

4. Under Environments, click Choose Environments and specify your environments.

5. Under Time Frame, click the From and To calendar icons to set a time frame for the window.

6. Click Add.

This maintenance window is set for the selected environments. The maintenance window is added to the MAINTENANCE

WINDOWS and ENVIRONMENT PLANNER pages.

Environment Planner

You can easily monitor environment usage and availability and identify release and resource scheduling conflicts.

In continuous delivery, organizations manage multiple releases across multiple teams and share environments, often

at the same time. Planning and maintaining environments is critical to the smooth running of your release pipeline. The

ENVIRONMENT PLANNER provides an overview of environment availability in relation to scheduled releases and

outages.

Use the ENVIRONMENT PLANNER to:

•

Track environments

•

View the involvement of environments in scheduled releases

•

See the maintenance windows and freeze periods that might impact the timely delivery of deployments

•

Avoid potential bottlenecks

To view the ENVIRONMENT PLANNER, from the Calendars tab, click Environment Planner. To change the view from

monthly to weekly, click in the calendar grid. To change the view from weekly to monthly, click Back.

You can add or remove the environments shown in the Environments field. You can select environments from all

projects, not only from the current project.

To see copyable details, hover over the following entry types :

•

Maintenance windows - associated environments and time frame

•

Freeze periods - associated environments, time frame, and freeze period type (hard or soft)

Freeze Periods

You can prevent deployments from taking place during predefined periods.

A freeze period is a time frame in which a deployment (or similar tasks) cannot take place in specified environments. To

see the existing freeze periods, from the Calendars tab, click one of the following menu options: Freeze Periods,

Release Calendar, or Environment Planner. Freeze periods are effective across all projects.

There are two types of freeze periods:

•

Hard - Prevents the release from running during the specified time frame

•

Soft - Displays warnings but does not prevent the release from running during the specified time frame

You need the Can manage freeze periods permission to:

125

Continuous Delivery Director 8.5

•

Create hard and soft freeze periods and add all the environments of all projects

•

Edit freeze periods

•

Duplicate freeze periods

•

Delete freeze periods

If you do not have this permission, you can only view freeze periods in read-only mode.

You cannot schedule a freeze period if a maintenance window is already scheduled during the same time

frame. Additionally, you cannot schedule a maintenance window if a freeze period is already scheduled during the same

time frame.

You can define specific releases to run even during a hard freeze period to allow emergency fixes.

If you define a freeze period that conflicts with a release, a Phase scheduling conflict with a freeze period notification

is sent to the release and phase owners. If a scheduled / automatic phase fails to run due to a conflict with a freeze

period, a Phase failed to start - freeze period conflict notification is sent to the release and phase owners.

Create and Edit Freeze Periods

You can create periods in which deployments cannot occur.

Prerequisite: You have been granted the Can manage freeze periods permission.

A freeze period is a time frame in which a deployment (or similar tasks) cannot take place in specified environments. You

may want to define a freeze period during a holiday season or during special activities in the data center.

Figure 17: Freeze Periods Page

1. From the Calendars tab, click Freeze Periods.

2. In the FREEZE PERIODS (CROSS-PROJECT) page, click Create Freeze Period.

3. In the NEW FREEZE PERIOD dialog, define the following parameters:

•

Name

Specify a name for the freeze period.

•

Type

Select the required type of freeze period:

–

Soft - Display warnings when conflicts exist without blocking deployments.

–

Hard - Block deployments and to send automatic notifications to release and phase owners.

•

Allowed Releases

126

Continuous Delivery Director 8.5

NOTE

Applies only for Hard Freeze Period.

Specify releases that can run even during hard freeze periods to allow emergency fixes.

•

Environments

Specify the environments to include in the freeze period.

•

Time Frame

Specify the from and to dates for the freeze period.

–

(Optional) Select an option from the recurrence drop-down to set the frequency that you want for the freeze

period.

NOTE

If you set up a recurrence pattern, the scheduled freeze period is set between the From and To dates

for the number of recurrences.

4. Click Create.

The freeze period is added to the FREEZE PERIODS (CROSS-PROJECT) page and appears in the Release Calendar

and Environment Planner.

Reports

Reporting functionalities help you monitor applications and content.

Reports indicate where applications and content are in the pipeline, and when and where they are scheduled for

deployment. You can create, save, and access reports for your releases. Select the REPORTS tab, and select one of the

following reports from the drop-down list:

NOTE

Report Data is saved in the local browser cache. If you change domains, the report data is not reflected in the

new domain.

Application Pipeline Report

The Application Pipeline Report shows you which releases have been deployed to the various environments including

the version number and any release content. This application-focused view allows you to gain insight into the software

delivery process:

127

Continuous Delivery Director 8.5

This report provides an overview of the following application and deployment information:

•

Environment

•

Phase

•

Release

•

Version

•

Status

•

Build Number

NOTE

If you use Jenkins as your continuous integration hub, you can click the build number to directly access build-

related information and log files in Jenkins.

•

Application version that is running

Note: Also shows the last successful application version

•

Application version that failed

Note: Also shows the last successful application version

Use this report to monitor where applications are in the release pipeline.

An application appears in this report only after:

•

The application is assigned to at least one release.

•

Environments are assigned to the application.

•

The application has at least one version.

•

The application has environments that are mapped to a phase.

•

The application has content that is associated with a task.

Note: The associated task must be deployed or scheduled.

After you configure an application, create an application report.

Follow these steps:

1. Select the REPORTS tab and select Applications.

2. Select Add Applications and select an application from the list.

3. Select Add Selected.

Applications that fit the described criteria are added to the report. Phases show as rows with a column for each task.

128

Continuous Delivery Director 8.5

Work Items Report

NOTE

Formerly known as the Content report.

Use the Work Items Report to access information about work items in different views.

•

Track - See a list of all work items in a given release track:

•

Work Items - See information about a specific work item.:

•

Application Versions - See information about an application version:

129

Continuous Delivery Director 8.5

The Work Items Report includes release name, application version, status in Continuous Delivery Director, and status in

the external Agile management tool, such as Rally

or Atlassian Jira. This Agile-centric view provides useful visibility for

the business, showing the release value in the context of features and fixes included.

The data for this report includes all releases that have been created in the workspace by any user.

To access the report, do one of the following: Use the Show By filter at the top of the report to select Tracks, Work Items,

or Application Versions.

•

Select Reports, then Work Items.

•

On a release page, select the Applications tab in the left panel, then the application version number. From the

dropdown menu, select Go to Work Items Report.

NOTE

This report shows you the status and details of all the work items shown on the release page in the Work

Items tab.

Release Analysis Report

You can view details of release execution activities for current and past executions.

The Release Analysis Report shows the execution results of phases and tasks in a selected release and illustrates their

relationship to the schedule using Gantt bars. This capability lets release managers quickly assess release execution

progress and identify issues.

The report contains the following release information:

NOTE

You can only select one release for each report.

•

A list of phase and task executions shown in the grid portion on the left side of the Gantt chart view. You can expand

this list to display the following information:

–

Phase name

–

Phase and task execution start and end times

–

Phase and task duration

–

Phase and task execution status

•

A Gantt chart on the right side of the grid portion. This view provides an illustrated version of your release activities

with Gantt bars that show the duration of your phases and tasks across a timeline. For each task, the associated Gantt

130

Continuous Delivery Director 8.5

bar begins at the start date and finishes at the end date. In the chart view, you can click on a task name to view the

following information:

–

Task applications

–

Task owners

–

Task input and output parameters

Error and warning activities appear as colored icons above the phases and tasks shown in the timeline. Mouse over an

activity to show error and warning messages.

You can adjust the time units for the timeline by selecting one of the following options from the View by dropdown

menu:

–

Fit Screen

–

Months

–

Weeks

–

Days

–

Hours

You can zoom out to see a bigger picture of your release by displaying, for example, Months, or you can zoom in to

see the exact start and finish dates for your release tasks by changing the timescale to Days or Hours. This flexibility

is especially useful if tasks are executed within short intervals of each other.

To go to the Release page for the selected release, click Go to Release.

To access this report, select Reports, then Release Analysis from the top menu. Alternately, in a release, open the

hamburger menu and click Go to Release Analysis Report.

Environment Report

The Environment Report shows all deployed, planned, and failed applications on a selected environment:

The report contains the following details:

•

Application and version

•

Build number, if available

131

Continuous Delivery Director 8.5

NOTE

If you use Jenkins as your continuous integration hub, you can click the build number to directly access build-

related information and log files in Jenkins.

•

Deploy Status

Note: Deploy statuses are Deployed, Scheduled, Failed, and Running.

•

Releases that deployed, or that are scheduled to deploy, the application version on this environment

Releases Over Time Report

You can quickly see how many releases have been marked as done within a specified time frame.

To access the report, select Reports, then Release Over Time from the top menu. Use the Select time frame filter at the

top of the report to select a time period such as Last 6 months or a custom date range.

The data for this report includes all releases that have been created in the workspace by any user.

The Release Over Time report provides the following information:

•

Status

Which releases were successful, which releases failed, and which releases are not in use.

•

Duration

The execution time of each release

•

Mark as Done Date

The date on which the release was marked as complete and became read-only.

CDA Deployments Report

The CDA Deployments report shows detailed information about Automic

Continuous Delivery Automation deployments

that have run as part of releases in Continuous Delivery Director:

NOTE

This report is available with Automic

Continuous Delivery Automation 12.3. This report is not compatible with

earlier versions of Automic

Continuous Delivery Automation.

This report contains the following details:

•

Release Name (CDD)

•

Deploy Status (CDD)

Note: Deploy statuses are Deployed, Scheduled, Failed, and Running.

•

Deployment Package (CDA)

Information: An instance (a version, a revision, a tag, …) of a CDA application that defines the content to deploy.

•

Application (CDD and CDA)

Information: A CDA application is the main container of the deployment model and typically consists of multiple

Components.

•

Environment (CDD)

•

Components (CDA)

Information: A component can be any file (also configuration files), objects (for example, database structure),

administrative scripts that are stored under version control or in a source or staging system, and so on.

•

Workflow

Information: CDA workflows are used to carry out physical deployments. A workflow describes all necessary steps for

the deployment of an application.

•

Duration

•

Deployment Name (CDA)

132

Continuous Delivery Director 8.5

Release Quality Report

You can see detailed information about the quality of your release and quickly assess any risks. You can also use this

report to evaluate the effectiveness of your test automation strategy.

Figure 18: Release Quality Report

The data for this report includes all releases that have been created in the workspace by any user.

You can also see test information for any associated work items that are defined in your agile management tool (Jira/

Rally).

You can use the Release Quality Report to:

•

Save time

•

Select test suites wisely and see the breakdown

•

View results per test framework

•

Optimize test coverage and find gaps in the test plan

The Release Quality report provides the following information:

•

General Information

133

Continuous Delivery Director 8.5

–

Number of builds that exist for the specified business application version/application version.

–

Time saved during test suite execution due to implementation of Test Advisor recommendations.

–

Number of flaky test suites detected either with inconsistent execution results or test suites failed on the last

execution.

–

Number of files without test coverage.

–

Number of tests/test suites that have failed

•

Test Distribution

–

Bar graph showing the distribution of test suite execution. To see more information, hover over the bar graph.

–

Number of failed tests out of total tests recommended by the Test Advisor.

–

Number of failed tests out of total tests not recommended by the Test Advisor.

–

Time to first test failure.

–

Adaptive Testing task duration.

–

Change ID of build or commit that triggered the Adaptive Testing task.

NOTE

If you use Jenkins as your continuous integration hub, you can click the build number to directly access

build-related information and log files in Jenkins.

–

Details of phase containing the Adaptive Testing task executed. Hover over the phase name to see the details.

–

Testing framework from where the test suites were imported.

•

Code Churn

Shows in graphical format the code churn in releases and in business application versions/application versions. This

heuristic is updated on every commit.

•

Flaky Test Suites

Lists the flaky test suites detected either with inconsistent execution results, or test suites that failed on the last

execution.

•

Uncovered / Updated Files

Lists the files that were changed during the release but have no associated test suites.

•

Incomplete Work Items

Shows information about the test coverage of work items in a given release (features, user stories, defects, and so

on). This graph shows how well a work item has been tested and whether that work item has passed or failed the

associated tests.

For every release work item, you can see:

–

The commits that have been done for this work item, and the test coverage status.

–

The tests executed for a specific work item and how many of them are flaky.

To access the report, select Reports, then Release Quality from the top menu. Alternately, in a release, open the

hamburger menu and click Go to Release Quality Report.

To create a new report, open the Release Quality report and select releases, business applications, business application

versions, applications, and application versions.

Follow these steps:

1. Open the Release Quality report and in Release, specify a release name.

The Business Application Version/Application Version Report summary is displayed.

2. Under Business Application Version/Application Version Report, select the release name.

The Release Quality by Business Application Version/Application Version report is displayed.

Note: You can change the release and business application/application version as needed.

134

Continuous Delivery Director 8.5

Endpoint Usage Report

You can quickly view the services which use a specific Endpoint.

To access the report, select Reports, then Endpoint Usage from the top menu. Select the desired Plugin, the Endpoint,

and the Plugin Service for the report. The data for this report includes all plugin services that use the selected endpoint.

135

Continuous Delivery Director 8.5

Test Orchestration

An innovative automated testing solution helps testers prioritize, execute, and fine-tune testing activities.

Overview

The test module lets you optimize and accelerate your code and application testing in a unified storage, planning, tracking,

reporting, and execution hub. This testing solution integrates with unit, functional, and performance test suites, as well as

continuous integration and DevOps activities in your deployment pipeline.

QA experts can use the test module to manage a test suite catalog and to tag tests. Release managers can integrate the

test module into releases to significantly improve release quality and speed up innovation velocity.

Key benefits:

•

Select optimal test plan automatically

•

Store and organize test assets in a single repository

•

Reduce release cycles

•

Increase release quality

Use the test module to:

•

Save time by identifying and removing redundant test executions from test cycles

•

Support continuous testing scenarios

•

Test new code changes efficiently, based on risks and priority

•

Perform risk-based testing cycles

•

Improve your change delivery process by automating test scenarios and optimizing test cycle execution

•

Run test cases (changes per phase, application, and version)

•

Set up test environments

•

Use test data during testing cycles

•

Launch virtual services

•

Visualize release health and quality levels, including current status and quality trend

•

View current status of application quality

The test module lets you:

•

Import references to test suites from test providers, such as Gradle, Protractor, and so on.

•

Tag test suites

•

Run the tagged test suites using Adaptive Testing tasks in releases. When an Adaptive Testing task runs, the results

are stored and added to the Adaptive Testing Results list.

Test Frameworks

Plug-ins provide an interface for storing your test provider authentication credentials and project folders as environment

variables on the cloud. This interface allows you to reference your credentials without the need to hardcode this data into

your tests. Because plug-ins manage authentication at the global level, you can have multiple jobs running in parallel that

use the same credentials and project folders.

The test module provides the following test frameworks for test assets:

•

JUnit - A test automation framework for Java

•

Robot Framework - A test automation framework for Git builds

136

Continuous Delivery Director 8.5

Supported Plug-ins

Plug-ins provide an interface for storing your test provider authentication credentials and project folders as environment

variables on the cloud. This interface allows you to reference your credentials without the need to hardcode this data into

your tests. Because plug-ins manage authentication at the global level, you can have multiple jobs running in parallel that

use the same credentials and project folders.

After you enable plug-ins and create associated endpoints, you can add adaptive testing tasks to your releases.

Terms and Concepts

The following terms and concepts, defined here, are used throughout the Adaptive Testing documentation.

•

Adaptive Testing Catalog: A central repository of test sources and test suites.

•

Application Testing Insights: An interface for viewing performance trends in test execution results.

•

Adaptive Testing Results: An interface for viewing the results of test executions.

•

JUnit: A unit testing framework for the Java programming language.

•

test asset: A reusable test case or test script.

•

test framework: A set of guidelines for creating and designing test cases. A conceptual part of automated testing that

helps testers to use resources more efficiently.

•

test source: A configuration to import tests that includes the plugin name and endpoint to use.

•

test suite: A container of test assets.

Test Orchestration Overview

NOTE

The following videos are extracted from the Test Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video describes how you can orchestrate tests with your release pipeline. Continuous Delivery Director provides

integration with common testing tools, plus test intelligence and heuristics that automatically select the right tests to run

and return data about release quality based on test results.

More Information:

•

Setting Up the Test Module

•

Create an Adaptive Testing Task

•

Continuous Testing Agents

•

Monitor Running Tests

•

Monitor Test Suite Executions Through APIs

•

View Adaptive Testing Results

•

Integration Testing

•

Test Advisor

•

Test Module Actions

•

Import and Export Test Sources

•

Test Source Templates

Install Continuous Delivery Director with the Test Module

Help your colleagues achieve continuous testing by installing the Test module together with Continuous Delivery Director.

Continuous Delivery Director has two flexible offerings:

137

Continuous Delivery Director 8.5

•

SaaS – SaaS provides the same enterprise strength as the on-premises version, but it is available through a tiered

licensing approach, including a free starter tier. For more information, see cddirector.io

•

On-premise – On-premise is available for customers who prefer to manage software in-house.

In this section, you will learn how to install the on-premise solution with the Test module functionality.

NOTE

To install Continuous Delivery Director without the Test module, see Install Continuous Delivery Director.

Solution Overview

Continuous Delivery Director orchestrates releases utilizing open-source, commercial, and homegrown (Broadcom)

solutions across the DevOps toolchain, including planning, CI, testing, and deployment tools.

Continuous Delivery Director coordinates the end-to-end release pipeline, triggering actions, and gathering data for

reporting and analytics. These actions and analytics help teams to build a more efficient and productive continuous

delivery pipeline, ultimately delivering more value to customers.

Figure 19: Intelligent Pipeline

To enable Continuous Delivery Director with the Test module, you need to install and configure a number of components.

The following diagram shows a typical system landscape after installation:

138

Continuous Delivery Director 8.5

Figure 20: CDD On-Premise System Architecture with Test Module

Continuous Delivery Director and the Test module components are packaged as self-installed WAR (cdd.war) files that

you add to a configured Apache Tomcat instance. Additionally, you will also install the Test Advisor, an AI-based tool that

helps developers reduce the test cycle time by selecting a subset of test suites to run instead of all test suites.

Continuous Delivery Director packaged plug-ins are also WAR files that you add to the same Apache Tomcat instance

or to a remote Apache Tomcat instance. To auto-register these plug-ins, include the plug-ins with the cdd.war file. After

Continuous Delivery Director starts to run, the plug-ins are auto-registered and appear in the Plug-ins page.

The Test module uses MongoDB as a repository for test-related data. You can install MongoDB either as a standalone

server or as a Docker container server. For more information, see https://www.mongodb.com/

The Test module supports popular test frameworks such as Protractor and Gradle. These test frameworks require Docker

Engine installation to integrate with the Test module.

Therefore, we recommend that you use a Docker platform that runs on the Red Hat Linux OS to integrate with the Test

module.

Before You Install

For installation purposes, enable the following servers/resources:

•

A dedicated server for Continuous Delivery Director

139

Continuous Delivery Director 8.5

NOTE

Red Hat Linux is provisioned.

•

A dedicated server to run the Docker Engine.

NOTE

Red Hat Linux is provisioned.

•

An NFS service for a shared file system is provisioned.

•

JRE 1.8 is installed.

•

Apache Tomcat 8.5.x is installed.

•

A relational database (MS-SQL, MySQL, Oracle, and so on) is installed.

•

The installation user has full permissions for the Apache Tomcat installation folder where you want to install the

product.

•

Docker Engine is installed

•

The remote API is accessible and a port is exposed (the port is stored in the Continuous Delivery Director

configuration)

•

MongoDB version 4.2 Community Edition is installed. Adaptive Testing uses MongoDB as a repository for test-related

data. You can install MongoDB either as a standalone server or as a Docker container server. For more information,

see https://www.mongodb.com/

Configure the Adaptive Testing Environment

After you carry out the prerequisites, you configure the environment, as shown in the following diagram:

Figure 21: Planning your Test module Installation

Follow these steps:

1. Create an Apache Tomcat owner for the CDD server (Server 1). This server contains Adaptive Testing Catalog,

Adaptive Testing Results, and Continuous Delivery Director.

Important! Do not use root for the Apache Tomcat owner.

140

Continuous Delivery Director 8.5

Example:

user name = cdd

uid=1010

group name = cdd

gid=1010

groupadd 1010 -g 1010 cdd

useradd 1010 -u 1010 -g 1010 -G docker cdd

2. Configure a shared file system on the NFS Server:

a. On NFS server:

a. Create a shared folder.

Example: /home/cdd/.cdd

b. Change folder owner to the same uid and gid defined in step 1.

Example: chown -R 1010:1010 /home/cdd/.cdd

c. Grant folder permissions to all.

Example: chmod -R 777 /home/cdd/.cdd

d. Expose the shared folder to enable access from Server 1 and Server 2 with read/write and sync options.

Example: vi etc/exports

NOTE

If the exports configuration file is missing in the /etc folder, create an exports file.

Add the following text: /home/cdd/.cdd *(rw,sync)

After saving the edited exports file, you must update the operating system. To update the operating system,

run the command:

exportfs -a

b. On CDD server (Server 1):

a. Create .cdd folder in the Apache Tomcat owner home folder to be mapped to the NFS shared folder.

Example: /home/cdd/.cdd

b. Create a mount point on Server 1 to be mapped to the NFS shared folder.

a. Check on the server with the NFS shared folder that mount is open by running this command: rpcinfo -u

localhost nfs.

Successful output:

program 100003 version 3 ready and waiting program 100003 version 4 ready and

waiting

Failure output:

rpcinfo: RPC: Program not registered program 100003 is not available

If you receive failure output, run the following commands (these examples are for CentOs):

yum install nfs-utils

systemctl restart nfs-server

Test again with the command:

rpcinfo -u localhost nfs

b. All folders in the NFS folder path must have permissions (). To change permissions for a folder, navigate to

that folder's parent folder and run the command:

chmod 751 cdd”.

c. On the client, CDD server (Server 1), and Docker Engine server (Server 2), the following command detects

whether the mount succeeds:

showmount -e {IP} where {IP} is the IP of the server with the NFS shared folder.

A successful output is the content of the exports file:

141

Continuous Delivery Director 8.5

Export list for {IP}:

/home/cdd/.cdd *

Example: mount -t nfs4 <nfs server>:/home/cdd/.cdd /home/cdd/.cdd

c. On Docker Engine server (Server 2):

a. Create .cdd folder owner to be mapped to the NFS shared folder.

Example: /home/cdd/.cdd

b. Change folder owner to the same uid and gid defined in step 1.

Example: chown -R 1010:1010 /home/cdd/.cdd

c. Create a mount point on Server 2 to be mapped to the NFS shared folder.

Example: mount -t nfs4 <nfs server>:/home/cdd/.cdd /home/cdd/.cdd

Create Admin User for MongoDB

After MongoDB is installed, you create an Admin user to connect to the MongoDB instance, to authenticate with, and to

enable remote access to MongoDB. In the following examples, we create a root user.

Standalone Server

Create an admin user from the MongoDB command line:

use admin

db.createUser(

{

user: "<user>",

pwd: "<pwd>",

roles: ["root"]

});

Example:

use admin

db.createUser(

{

user: "cdd",

pwd: "mypassword",

roles: ["root"]

});

Docker Container Server

Create an admin user from the MongoDB command line:

sudo docker exec -it <container-name> mongo admin

db.createUser({ user: '<admin-username>', pwd: '<admin-initial-password>', roles: [ {

role: "root", db: "admin" } ] });

exit

Example:

142

Continuous Delivery Director 8.5

docker exec -it mongo1 mongo admin

> db.createUser({ user: 'cdd', pwd: 'mypassword', roles: [ { role: "root", db:

"admin" } ] });

> db.auth("cdd", "mypassword");

Install the Web Application Files

IMPORTANT

Review the installation instructions for the database setup. For more information, see Install Continuous Delivery

Director

To enable the Test module to work with Continuous Delivery Director, install, on the Apache Tomcat server, the .war files

that are required to run Adaptive Test Catalog, Adaptive Test Results, and the Test Advisor.

The Test module is packaged as self-installed WAR (cds.war , tar.war , and cta.war ) files that you add to a

configured Apache Tomcat instance. cds.war contains the Adaptive Testing Results files, tar.war contains

the Adaptive Testing Catalog files, and cta.war contains the Test Advisor files. Optionally, you can install

the WAR (cds.war , tar.war , and cta.war ) files on the same Apache Tomcat instance that contains the Continuous

Delivery Director cdd.war file and integrate the Test module with Continuous Delivery Director.

After Continuous Delivery Director starts to run, the Test module functionality is enabled and appears under the Tests

menu in the Continuous Delivery Director user interface.

Follow these steps:

1. Download the cds.war , tar.war , cta.war and plug-in .war files from the Support site.

2. Log in to the Apache Tomcat server as the Apache Tomcat owner.

IMPORTANT

Ensure that the user is not logged in to the Apache Tomcat server as root .

3. Stop the Apache Tomcat service.

Depending on your implementation, shut down the Windows service for Apache Tomcat, or navigate to the

<tomcat_home> directory from the command prompt and use the shutdown command.

Example:

[cdd@T11383 apache-tomcat-8.5.24]#./bin/shutdown.sh

4. Copy the cds.war , tar.war , cta.war and plug-ins .war files to the webapps folder of the Apache Tomcat

installation directory.

5. Start the Apache Tomcat service.

Depending on your implementation, start the Windows service for Apache Tomcat in the <tomcat_home> directory or

use the startup command, for example:

[cdd@T11383 apache-tomcat-8.5.24]#./bin/startup.sh

Wait a few minutes for Apache Tomcat to initialize the application and to deploy the web applications.

You must deploy the applications in the order that is specified in this procedure, starting with Adaptive Testing Results

(CDS).

6. Deploy Adaptive Testing Results.

Enter the following URL in a Web browser:

http://<tomcat-host>:<tomcat-port>/cds

NOTE

The default Apache Tomcat port is 8080.

A configuration page opens the first time that you enter this URL.

The following screen capture shows the Adaptive Testing Results Web Installer welcome message:

143

Continuous Delivery Director 8.5

7. Enter the path to Home folder defined in Configure the Adaptive Testing Environment, and select Set.

This folder holds the Adaptive Testing Results configuration and log files. The configuration file holds the database

server connectivity details that you enter in the next step. The following paths are for the default Home folders:

–

Windows: c:\.cdd

–

Linux: /home/cdd/.cdd

After you select Set, the MongoDB connection properties page opens.

The following screen capture shows the Adaptive Testing Results MongoDB connection properties page:

144

Continuous Delivery Director 8.5

8. Enter the necessary information for your MongoDB instance, and select Install.

After the installation has finished, the Apache Tomcat server loads Adaptive Testing Results with a valid connection to

MongoDB.

The next application to be deployed is Adaptive Testing Catalog (TAR).

9. Deploy Adaptive Testing Catalog.

Enter the following URL in a web browser:

http://<tomcat-host>:<tomcat-port>/tar

A configuration page opens the first time that you enter this URL.

The following screen capture shows the Adaptive Testing Catalog Web Installer welcome message:

10. Enter the path to the Home folder created, defined in Configure the Adaptive Testing Environment, and select Set.

145

Continuous Delivery Director 8.5

This folder holds the Adaptive Testing Catalog configuration and log files. The configuration file holds the database

server connectivity details that you enter in the next step. The following paths are for the default Home folders:

–

Windows: c:\.cdd

–

Linux: /home/cdd/.cdd

After you select Set, the MongoDB connection properties page opens.

The following screen capture shows the Adaptive Testing Catalog MongoDB connection properties page:

11. Enter the necessary information for your MongoDB instance, and select Install.

After the installation has finished, the Apache Tomcat server loads Adaptive Testing Catalog with a valid connection to

MongoDB.

12. Deploy Test Advisor

Enter the following URL in a web browser:

http://<tomcat-host>:<tomcat-port>/cta

A configuration page opens the first time that you enter this URL.

The following screen capture shows the Test Advisor welcome message:

146

Continuous Delivery Director 8.5

13. Enter the path to the Home folder created, defined in Configure the Adaptive Testing Environment, and select Set.

This folder holds the Test Advisor configuration and log files. The configuration file holds the database server

connectivity details that you enter in the next step. The following paths are for the default Home folders:

–

Windows: c:\.cdd

–

Linux: /home/cdd/.cdd

After you select Set, the MongoDB connection properties page opens.

The following screen capture shows the Test Advisor MongoDB connection properties page:

147

Continuous Delivery Director 8.5

14. Enter the necessary information for your MongoDB instance, and select Next.

The Apache Tomcat server loads the Test Advisor with a valid connection to MongoDB and the Test Advisor services

connection properties pages opens:

15. Select Install.

The Apache Tomcat server loads the Test Advisor with valid connections to the Adaptive Testing Catalog and Adaptive

Testing Results.

16. Deploy Continuous Delivery Director (CDD).

Enter the following URL in a Web browser:

http://<tomcat-host>:<tomcat-port>/cdd

A configuration page opens the first time that you enter this URL.

The following screen capture shows the Continuous Delivery Director Web Installer welcome message:

17. Accept the default Home folder, or enter the path to Home folder defined in Configure the Adaptive Testing

Environment, and select Set.

148

Continuous Delivery Director 8.5

This folder holds the Continuous Delivery Director configuration and log files. The configuration file holds the

database server connectivity details that you enter in the next step. The following paths are for the default Home

folders:

–

Windows: c:\.cdd

–

Linux: /home/cdd/.cdd

After you select Set, the database connection properties page opens:

Example: MySQL

18. Complete the required fields and select Save. The services connection page opens:

149

Continuous Delivery Director 8.5

19. Select both checkboxes to activate the Test module functionality.

If you install Adaptive Testing Results, Adaptive Testing Catalog, and the Test Advisor on different Apache Tomcat

instances, you can change the server paths.

Select Save.

NOTE

For more information about installation, see:

System Requirements

Installation Best Practices

Install Continuous Delivery Director

Configure Continuous Delivery Director for Testing

1. Connect to the NFS server with the user 1010. If the folder /home/1010/.cdd/artifacts does not yet exist,

create this folder.

On the NFS server, grant full access permissions to all users on the artifacts folder under the .cdd shared folder.

For example:

chmod -R 777 /home/1010/.cdd/artifacts

2. Create a release. For more information, see Design and Create Releases.

3. Create an application. For more information, see Manage Applications and Environments

4. Create an application version for the application you just created. For more information, see Manage Applications and

Environments

5. Set up containerized plug-ins. For more information, see: Set Up Containerized Plug-ins

6. Install the Gradle testing plug-in. For more information, see: Gradle Plug-in

150

Continuous Delivery Director 8.5

7. Install the Robot framework plug-in. For more information, see: Robot Framework Plug-in

8. Install the GitHub plug-in. For more information, see: GitHub Plug-in

9. Create a source control connection. This action enables the import of commit messages from your source control. For

more information, see Set Source Control Connection in Design and Create Releases.

Configure Jenkins for Testing

Follow these steps:

1. Download the cdd-jenkins-<version>.hpi file from the Support site.

2. Configure the Continuous Delivery Director plug-in for Jenkins. For more information, see Plug-in for Jenkins.

3. Open the Jenkins project configuration screen and add a post-build action.

4. Either select the Send notification to CDDirector post-build type and enter:

–

Application name

–

Application version

–

Tenant ID (from User Settings)

–

API key (from User Settings)

Or open the Jenkinsfile and add a post-build action:

sendNotificationToCDD appName: '<appname>',

appVersion: '<appversion>',

gitCommit: "${ env.GIT_COMMIT }",

gitPrevSuccessfulCommit: "${ env.GIT_PREVIOUS_SUCCESSFUL_COMMIT }",

overrideCDDConfig: [

customApiKey: '******************************',

customProxyPassword: '',

customProxyUrl: '',

customProxyUsername: '',

customServerName: 'myserver.net',

customServerPort: 8080,

customTenantId: '***-***-***-***-***',

customUseSSL: false

releaseTokens: '{"":""}'

5. Save your configuration.

Set Up the Continuous Testing Agent

The Continuous Testing Agent is a Java agent that is used by SUT (System Under Test) applications to monitor the

interactions between application source files and CDD test suites.

This monitoring is used to determine which test suites to run when an application source file changes.

Follow these steps:

1. Download the ct_agent.jar file from the Support site.

2. In settings.properties, ensure that the following property is set to true:

cdd.ct_agent.enabled=true

3. In SUT setenv.sh in the Tomcat bin folder, ensure that the following lines exist:

export CDD_HOME_FOLDER=/home/cdd/.cdd

export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/home/cdd/.cdd/ct_agent.jar"

151

Continuous Delivery Director 8.5

NOTE

The lines above are for the CentOS operating system.

4. Upload ct_agent.jar to the location you defined above.

5. In CDD_HOME_FOLDER, under the conf folder create a settings.properties file:

cdd.continuous_testing_agent.cdd.application=<application name from CDD>

cdd.continuous_testing_agent.cdd.environment=<env name from CDD>

cdd.continuous_testing_agent.cdd.api_key=<API key from CDD>

cdd.continuous_testing_agent.cdd.url=http://<CDD hostname>:8080/cdd/

cdd.continuous_testing_agent.cdd.tenant_id=00000000-0000-0000-0000-000000000000

cdd.continuous_testing_agent.packages.include=com.ca.cdd

cdd.continuous_testing_agent.packages.exclude=com.ca.cdd.ws,com.ca.cdd.controllers,com.ca.cdd.dao

cdd.continuous_testing_agent.cdd.url_path=/ct_agent

cdd.continuous_testing_agent.cdd.trust_self_signed_certificate=true

cdd.continuous_testing_agent.cdd.disable_host_verification=true

cdd.continuous_testing_agent.log.configuration_file=/home/cdd/.cdd/ct_agent.logback.xml

cdd.continuous_testing_agent.log.maximum_memory_size=800

cdd.continuous_testing_agent.log.level=trace

6. Restart Tomcat.

Setting Up the Test Module

This section describes how to configure the test module for use.

Before you can use the test module, you configure Continuous Delivery Director to enable the test module for use.

Prerequisites

Ensure that the artifacts listed below are available:

•

At least one application is available for testing. For more information, see Manage Applications and Environments

•

At least one environment is available for testing. Test environments should match the phases in your target releases.

For more information, see Manage Applications and Environments

•

At least one testing plug-in is available, such as Gradle, Protractor, Robot Framework, and so on. If you see that there

are no plug-ins, register at least plug-in. For more information, see Register Plug-ins

•

At least one endpoint is available for testing. For more information, see Manage Endpoints

•

At least one release is available for testing. For more information, see Design and Create Releases

You can choose to set up one or more of the following plug-ins:

•

Gradle Testing running JUnit (containerized). For more information, see Gradle Testing Plug-in

•

Robot Framework. For more information, see Robot Framework Plug-in

Follow these steps:

1. Select Tests, then Adaptive Testing Catalog.

2. Specify the Application and the Application Version/ Business Application and the Business Application

Version.

3. Select the New Test Source button on the upper right.

4. The GET TEST ASSETS page opens, configure the following input parameters:

– •

Test Source Name

•

Plug-in

Select Import Test Suites for one of the predefined test plug-ins.

152

Continuous Delivery Director 8.5

Example: Robot Framework

•

Endpoint

Select an endpoint that has been predefined for the selected test plug-in.

•

Input parameters

The input parameters and test configurations vary according to the selected plug-in. However, all plug-ins

contain the Tags input parameter:

•

Tags

A tag is a word or a short phrase associated with a test suite for description and filtering purposes. Tags are

used to filter which test suites are executed when an Adaptive Testing task runs.

You can add multiple tags to test suites:

•

In the Tags field in the Get Test Assets pop-up.

•

In the Imported Tests page. Select one or more rows and select the Tags button.

You can add more tags at any time.

Note: Tags are not case-sensitive.

Example: BZM.Sanity.Test

For more information, see:

•

Gradle Testing Plug-in

•

Robot Framework Plug-in

–

Copy Tests from Another Application Version/Business Application Version

All test suites that match the input parameters are imported, tagged, and ready for use when an Adaptive Testing task is

run.

NOTE

The test configuration is linked to the test source. If you want to run the same test with a different configuration,

you need to create a new test source and to import the tests again. This may cause duplication of test sources.

NOTE

You can manage the test sources as per your Application version or Business Application version from the

Releases page. For more information, refer to Manage Test Sources from Releases.

Import Tests into Continuous Delivery Director

NOTE

The following video is extracted from the Test Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

This video shows how you can import test suites from your test framework into the Continuous Delivery Director test

modules. You can then associate the tests with the appropriate application and tag them.

Create an Adaptive Testing Task

After tests are imported into Continuous Delivery Director, you can add those tests to an adaptive testing task in a release

phase.

Each time the phase is run, Continuous Delivery Director runs those tests directly from the task on the versions of the

business applications and applications associated with the release.

153

Continuous Delivery Director 8.5

If you have a large number of test suites in your test tool, you may prefer to run only specific tests instead of running all

test suites. You can include and exclude tests using tags.

1. On the Releases page, select a release.

2. In a phase, select Create Task.

3. In Task Type, select Run Adaptive Testing.

4. In Tags, start to type to specify one or more tags.

You can add comma-separated values without spaces that may include:

•

Dynamic Values - type @ (at sign) to get a list of tags defined in the test tool. You can select multiple dynamic

values separated by commas.

•

Tokens - type % (percentage sign) to get a list of available tokens. You can add one or more tokens and can

concatenate tokens as free text.

•

Free text

You can combine free text and tokens. You cannot combine dynamic values with free text or tokens.

Leave empty to execute all the test suites under the application version.

5. Optionally, in Applications, specify application names to add to the task.

You can specify build numbers for each application.

6. Optionally, select Run Business Application Tests.

Select this option to execute all the tests that were imported for the business application in the release.

7. In Build/Commit ID, specify the build number or commit ID of the code to test.

8. Optionally, select Run a subset of test suites selected by the Test Advisor.

9. Click Create.

Monitor Running Tests

You can view a test execution log that is updated in real-time.

A running release that includes one or more adaptive testing tasks.

You can access a test execution log from a release page to see which tests are executed at any given time. The execution

log is updated in real-time so if problems occur in a test run, you can examine the log to determine whether to stop or

continue with the test execution. This feature is especially useful when you run a large set of tests on complex business

applications.

IMPORTANT

This functionality is supported by the CucumberJVM plug-in version 1.4.1-6 and higher and is not backward-

compatible. For more information, see Cucumber JVM Plug-in.

1. In an adaptive testing task in a running release, click the progress bar.

A popup appears with an Execution Log link.

2. Click the Execution Log link.

The execution log opens in a new window.

Continuous Testing Agents

Dedicated programs collect and analyze adaptive testing metrics.

154

Continuous Delivery Director 8.5

Version 2.2

Continuous Testing (CT) agents are automated services that poll test sources to verify if specified test suites have been

updated. The agent is a data-gathering component. This component collects detailed information about applications

under test as test suites are executed. After the tests are run, the agent reports the collected data to Continuous Delivery

Director. An agent:

•

Analyzes the interactions between application source files and test suites.

•

Determines which test suites are executed when an application source file changes.

•

Is referenced by an AUT (application under test) when a new build triggers testing in a release.

•

Connects to Continuous Delivery Director using the WebSocket protocol.

Agents are installed in an environment where a business application/application is being tested. An agent receives a

notification from Continuous Delivery Director every time a test suite is started. The agent identifies the classes that are

examined. Then Continuous Delivery Director notifies the agent that the test suite is complete. At the end of the test

execution, the agent generates a mapped list of all the files that were changed and the test suites that examined the

changed files. This mapping is used by Continuous Delivery Director to instruct the Test Advisor to recommend running

only those tests that are associated with the changed code.

The following illustration shows a simple deployment in which an agent collects application and test metrics and relays this

information to Continuous Delivery Director. You can view these metrics in releases and reports.

155

Continuous Delivery Director 8.5

Figure 22: CT Agent Architecture

There are two types of CT agents:

•

.NET

For testing applications written in C# (C sharp).

•

Java

For testing Java applications.

Download Options

Use one of the following options to download the latest CT agent (ct_agent.jar) version:

156

Continuous Delivery Director 8.5

IMPORTANT

Downloading the ct_agent.jar file is a prerequisite for installing both the .NET and Java CT agents.

Method Info

wget wget -O ct_agent.jar https://

cspdl.broadcom.com/s/

vklrdye94fyyfi7nw99frkf2y7dnt1h8?

LCK=ent.box.com

MD5 edee233c7befd5bf96c6aa32047cd627

Click Download Button

Use one of the following options to download the latest CT agent DLL (ct_agent.dll) file:

IMPORTANT

Downloading the ct_agent.dll file is a prerequisite for installing the .NET CT agent only.

Method Info

wget wget -O ct_agent.jar https://

cspdl.broadcom.com/s/

d6cwhh8hht0n7p1dzm02xslzubacxg9l?

LCK=ent.box.com

MD5 4daf434c3dba818499302548e68a2a8b

Click Download Button

Configure .NET Continuous Testing Agents

Install and configure a .NET CT Agent on the Continuous Delivery Director server so that you can monitor adaptive testing

tasks running on C# (C sharp) applications in a release.

•

Windows Server 2019 or Windows 10

•

Java (JRE) 8 or higher is installed and enabled

•

A CDD_HOME_FOLDER environment variable is configured on the Windows Server

Follow this procedure to prepare a Windows environment with a working CT agent for adaptive testing.

NOTE

The CT agent requires that IIS and specific IIS components be enabled on Windows Server 2019 or Windows

10. The setup cannot proceed if IIS is not detected and specific IIS components are not enabled.

1. Run the CT agent Java application on Windows.

a) Copy ct_agent.jar to the <$CDD_HOME_FOLDER>\lib directory. For more information, see Continuous Testing

Agents.

•

The default home folder of OS user cdd is: \home\cdd

•

The default home folder of the Continuous Delivery Director product is: \home\cdd\.cdd

b) Under C:\<$CDD_HOME_FOLDER>\conf, create a settings.properties file.

C:\cdd\conf\settings.properties

157

Continuous Delivery Director 8.5

c) Configure the settings.properties file as follows:

•

cdd.continuous_testing_agent.id

Specify a unique ID for the agent.

•

cdd.continuous_testing_agent.cdd.application

Specify the application name from Continuous Delivery Director.

•

cdd.continuous_testing_agent.cdd.environment

Specify the Continuous Delivery Director environment in which the CT agent runs.

•

cdd.continuous_testing_agent.cdd.api_key

Specify the Continuous Delivery Director API key of an authorized user, such as an integration user, release

manager, or administrator. You can find the API key in Continuous Delivery Director under My Settings.

•

cdd.continuous_testing_agent.cdd.url

Specify the URL to your Continuous Delivery Director instance.

•

cdd.continuous_testing_agent.cdd.tenant_id

Specify the tenant ID of your Continuous Delivery Director instance. You can find the tenant ID in Continuous

Delivery Director under My Settings.

•

cdd.continuous_testing_agent.packages.include

Specify a comma-separated list of included packages (groups of classes, sub-packages, and interfaces).

•

cdd.continuous_testing_agent.packages.exclude

Specify a comma-separated list of excluded packages.

•

cdd.continuous_testing_agent.cdd.url_path

Specify the file path to the folder that contains the agent files.

•

cdd.continuous_testing_agent.cdd.trust_self_signed_certificate

Define whether to trust the Continuous Delivery Director self-signed certificates: true/false.

•

cdd.continuous_testing_agent.cdd.disable_host_verification

Define whether to disable host verification: true/false.

•

cdd.continuous_testing_agent.log.configuration_file

Specify the path to the agent log configuration file.

•

cdd.continuous_testing_agent.log.maximum_memory_size

Specify the maximum memory size of the agent log. Default is 100KB

•

cdd.continuous_testing_agent.log.level

Specify the granularity of the logging output. Possible entries: trace, debug (default), info, warning, error, fatal.

# Example:

cdd.continuous_testing_agent.id=my_ct_agent

cdd.continuous_testing_agent.cdd.url=http://{cdd-server-name}:8080/cdd

cdd.continuous_testing_agent.cdd.tenant_id=c914e1af-140b-4051-8ba5-0686b661f784

cdd.continuous_testing_agent.cdd.api_key=eyJhbGciOiJIUzUxMiJ9.JHGhgjhgJG

cdd.continuous_testing_agent.cdd.application=OnlineBanking

cdd.continuous_testing_agent.cdd.environment=Dev

cdd.continuous_testing_agent.packages.include=com.ca.cdd

cdd.continuous_testing_agent.packages.exclude=com.ca.cdd.ws,com.ca.cdd.controllers,com.ca.cdd.dao

cdd.continuous_testing_agent.cdd.url_path=/ct_agent

cdd.continuous_testing_agent.cdd.trust_self_signed_certificate=false

cdd.continuous_testing_agent.cdd.disable_host_verification=false

cdd.continuous_testing_agent.log.maximum_memory_size=8192

cdd.continuous_testing_agent.log.configuration_file=/home/cdd/.cdd/conf/ct_agent.logback.xml

cdd.continuous_testing_agent.log.level=trace

cdd.continuous_testing_agent.heartbeat_interval_in_milliseconds=0

cdd.continuous_testing_agent.maximum_idle_timeout_in_millis=60000

158

Continuous Delivery Director 8.5

cdd.continuous_testing_agent.api_key_path=

cdd.continuous_testing_agent.internet_proxy.url=

cdd.continuous_testing_agent.internet_proxy.username=

cdd.continuous_testing_agent.internet_proxy.password=

d) Run ct_agent.jar <java -jar ct_agent.jar>.

e) Verify that you are connected by checking the CT agent logs.

The log files are located at C:\<$CDD_HOME_FOLDER>\logs\ct_agent.log.

2. Install ct_agent dll on your Windows machine and run ct_agent dll with your application under test.

a) Install ct_agent.dll on your Windows machine.

Downloadct_agent.dll and put this file under C:\<CUSTOM_PATH>. For example:

<C:\incoming\ctagent\x64>

b) Configure the application under test.

Ensure that the application under test is running with the following environment variables:

NOTE

The COR_PROFILER is a .NET Framework feature that allows you to specify that the ct_agent.dll is

loaded into each applicable .NET process that loads the Common Language Runtime (CLR).

•

name="COR_PROFILER" value="{f42148d0-acbe-4fbe-be18-b46845e1a26a}"

The COR profiler ID of ct_agent.dll (must appear exactly as shown).

•

name="COR_PROFILER_PATH" value="C:\<CUSTOM_PATH>\ct_agent.dll"

The path to ct_agent.dll 32-bit

•

name="COR_PROFILER_PATH_64" value="C:\<CUSTOM_PATH>\ct_agent.dll"

The path to ct_agent.dll 64-bit

•

name="COMPLUS_ProfAPI_ProfilerCompatibilitySetting" value="EnableV2Profiler"

The profiler compatibility setting (must appear exactly as shown).

•

name="CDD_CT_AGENT_LOG_ENABLED" value="false"

(true/false; Default: false) Determines whether to disable logging completely.

•

name="CDD_CT_AGENT_LOG_CONSOLE_ENABLED" value="true"

(true/false; Default: false) Lets you keep a clean console for the profiled process, and possibly output logs only

to files.

•

name="CDD_CT_AGENT_LOG_LEVEL" value="trace”

(trace, debug, info, warning, error, fatal; Default: debug) Lets you control the granularity of the logging output.

•

name="CDD_HOME_FOLDER" value=“C:\<CDD_HOME_FOLDER>

(Default: read on) Specifies that the logs are written to a /logs sub-directory of this folder. If no folder is

provided, the logs are written to /tmp/cdd_profiler_logs.

•

name="CDD_CT_AGENT_INCLUDED_MODULES" value=“<Application under test name>”

(str1,str2,str3; Default: None) Filters functions (modules) by the containing dll/exe file. Only functions from

modules containing the provided string(s) are treated. Comma-separated strings - with no spaces before/after

the commas.

•

name="CDD_CT_AGENT_EXCLUDED_MODULES" value="module_prefixlong"

(str1,str2,str3; Default: None) Only applicable when some included modules (above) are defined - you can

exclude more specific module names.

•

name="CDD_CT_AGENT_INCLUDED_SOURCE_FILES" value=".cs"

(str1,str2,str3; Default: None) List functions defined in source files which include these strings.

•

name="CDD_CT_AGENT_EXCLUDED_SOURCE_FILES"

value="file_path_prefix3,file_path_prefix4 "

(str1,str2,str3; Default: None) List functions defined in source files which exclude these strings.

•

name="_NT_ALT_SYMBOL_PATH" value="C:\pdbs"

159

Continuous Delivery Director 8.5

The application under test .pdb file debugging output is copied to this path.

If the application under test is running under IIS, add the environment variables above to the

applicationHost.config file.

c) Make sure that the application under test is running as .NET Framework 4.7.

d) Make sure that the following DLLs exist on your server.

The $PATH environment variable specifies a set of directories where executable programs, such as DLLs, are

located. Validate that the Windows environment variable $PATH points to all DLL locations.

NOTE

If you prefer, you can also copy these DLLs to a specific location, and add this location to the $PATH

environment variable.

List of DLLs:

160

Continuous Delivery Director 8.5

•

C:\Windows\System32\advapi32.dll

•

C:\Windows\System32\bcrypt.dll

•

C:\Windows\System32\bcryptprimitives.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrjit.dll

•

C:\Windows\System32\combase.dll

•

C:\Windows\System32\gdi32.dll

•

C:\Windows\System32\gdi32full.dll

•

C:\Windows\System32\imm32.dll

•

C:\Windows\System32\kernel.appcore.dll

•

C:\Windows\System32\kernel32.dll

•

C:\Windows\System32\KernelBase.dll

•

C:\Windows\System32\mscoree.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll

•

C:\Windows\Microsoft.NET\assembly\GAC_64\mscorlib

\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorrc.dll

•

C:\Windows\System32\msvcp_win.dll

•

C:\Windows\System32\msvcp140d.dll

•

C:\Windows\System32\msvcrt.dll

•

C:\Windows\System32\ntdll.dll

•

C:\Windows\System32\ole32.dll

•

C:\Windows\System32\oleaut32.dll

•

C:\Windows\System32\psapi.dll

•

C:\Windows\System32\rpcrt4.dll

•

C:\Windows\System32\sechost.dll

•

C:\Windows\System32\shlwapi.dll

•

C:\Windows\System32\ucrtbase.dll

•

C:\Windows\System32\ucrtbase_clr0400.dll

•

C:\Windows\System32\ucrtbased.dll

•

C:\Windows\System32\user32.dll

•

C:\Windows\System32\vcruntime140_1d.dll

•

C:\Windows\System32\vcruntime140_clr0400.dll

•

C:\Windows\System32\vcruntime140d.dll

•

C:\Windows\System32\version.dll

•

C:\Windows\System32\win32u.dll

•

C:\Windows\System32\ws2_32.dll

Continue to the instructions for running a .NET CT agent.

Run a .NET Continuous Testing Agent

Perform these steps to ensure that the .NET agent is available for use.

161

Continuous Delivery Director 8.5

•

The .NET agent is installed and configured.

•

The application under test is configured in IIS.

1. In IIS, start the application under test.

2. From the command line, start ct_agent:

java -jar c:\cdd\ct_agent.jar

To run the process in the background use javaw -jar c:\cdd\ct_agent.jar

The agent logs are available under C:\Users\<USER>\.cdd\logs\ct_agent.log or C:\Users\Administrator

\.cdd\logs\ct_agent.log. IIS profiler logs should appear under C:\Windows\System32\inetsrv, and can be

copied later to a custom-defined path such as C:\tmp\cdd_profiler\cdd_profiler_0.log.

When you access the application for the first time, a profiler success message should appear in Windows Event Viewer,

such as:

.NET Runtime version 4.0.30319.0 - The profiler was loaded successfully. Profiler CLSID: '{0gig07oymq-

vffh-2n29-zv6k-004h1v0f71}'. Process ID (decimal): 5624. Message ID: [0x2507].

Configure Java Continuous Testing Agents

Add continuous testing (CT) agents to your release pipelines to monitor and optimize Java application testing.

•

Continuous Delivery Director is installed with the Test module.

For more information, see Install Continuous Delivery Director with the Test Module

•

You have downloaded the ct_agent.jar file. For more information, see Continuous Testing Agent

The Continuous Testing Agent is a Java agent that is used by SUT (System Under Test) applications to monitor the

interactions between application source files and Continuous Delivery Director test suites.This monitoring is used to

determine which test suites to run when an application source file changes.

1. Configure settings.properties for both Continuous Delivery Director and the agent.

a) In the Continuous Delivery Director server, navigate to the home folder, and open settings.properties.

b) In settings.properties, ensure that the following property is set to true: cdd.ct_agent.enabled=true

c) In the Continuous Delivery Director server home folder, under the conf folder create a settings.properties

file.

d) Configure the settings.properties file as follows:

•

cdd.continuous_testing_agent.id

Specify a unique ID for the agent.

•

cdd.continuous_testing_agent.cdd.application

Specify the application name from Continuous Delivery Director.

•

cdd.continuous_testing_agent.cdd.environment

Specify the Continuous Delivery Director environment in which the CT agent runs.

•

cdd.continuous_testing_agent.cdd.api_key

Specify the Continuous Delivery Director API key of an authorized user, such as an integration user, release

manager, or administrator. You can find the API key in Continuous Delivery Director under My Settings.

•

cdd.continuous_testing_agent.cdd.url

Specify the URL to your Continuous Delivery Director instance.

•

cdd.continuous_testing_agent.cdd.tenant_id

Specify the tenant ID of your Continuous Delivery Director instance. You can find the tenant ID in Continuous

Delivery Director under My Settings.

•

cdd.continuous_testing_agent.packages.include

162

Continuous Delivery Director 8.5

Specify a comma-separated list of included packages (groups of classes, sub-packages, and interfaces).

•

cdd.continuous_testing_agent.packages.exclude

Specify a comma-separated list of excluded packages.

•

cdd.continuous_testing_agent.cdd.url_path

Specify the file path to the folder that contains the agent files.

•

cdd.continuous_testing_agent.cdd.trust_self_signed_certificate

Define whether to trust the Continuous Delivery Director self-signed certificates: true/false.

•

cdd.continuous_testing_agent.cdd.disable_host_verification

Define whether to disable host verification: true/false.

•

cdd.continuous_testing_agent.log.configuration_file

Specify the path to the agent log configuration file.

•

cdd.continuous_testing_agent.log.maximum_memory_size

Specify the maximum memory size of the agent log. Default is 100KB

•

cdd.continuous_testing_agent.log.level

Specify the granularity of the logging output. Possible entries: trace, debug (default), info, warning, error, fatal.

# Example:

cdd.continuous_testing_agent.id=my_ct_agent

cdd.continuous_testing_agent.cdd.url=http://{cdd-server-name}:8080/cdd

cdd.continuous_testing_agent.cdd.tenant_id=c914e1af-140b-4051-8ba5-0686b661f784

cdd.continuous_testing_agent.cdd.api_key=eyJhbGciOiJIUzUxMiJ9.JHGhgjhgJG

cdd.continuous_testing_agent.cdd.application=OnlineBanking

cdd.continuous_testing_agent.cdd.environment=Dev

cdd.continuous_testing_agent.packages.include=com.ca.cdd

cdd.continuous_testing_agent.packages.exclude=com.ca.cdd.ws,com.ca.cdd.controllers,com.ca.cdd.dao

cdd.continuous_testing_agent.cdd.url_path=/ct_agent

cdd.continuous_testing_agent.cdd.trust_self_signed_certificate=false

cdd.continuous_testing_agent.cdd.disable_host_verification=false

cdd.continuous_testing_agent.log.maximum_memory_size=8192

cdd.continuous_testing_agent.log.configuration_file=/home/cdd/.cdd/conf/ct_agent.logback.xml

cdd.continuous_testing_agent.log.level=trace

cdd.continuous_testing_agent.heartbeat_interval_in_milliseconds=0

cdd.continuous_testing_agent.maximum_idle_timeout_in_millis=60000

cdd.continuous_testing_agent.api_key_path=

cdd.continuous_testing_agent.internet_proxy.url=

cdd.continuous_testing_agent.internet_proxy.username=

cdd.continuous_testing_agent.internet_proxy.password=

2. Set a path type environment variable to the CT agent home folder: CDD_CT_AGENT_HOME_FOLDER.

After initialization, the agent determines that \conf\settings.properties is located at the specified path.

CDD_CT_AGENT_HOME_FOLDER=C:\Users\bob04\.cdd

3. Stop the Tomcat service.

For example, enter shutdown.sh.

4. In the SUT setenv.sh in the Tomcat bin folder, add the following lines if not found:

export CDD_HOME_FOLDER=/home/cdd/.cdd

export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/home/cdd/.cdd/ct_agent.jar"

NOTE

The lines above are for the CentOS operating system.

163

Continuous Delivery Director 8.5

5. Upload ct_agent.jar to the /home/cdd/.cdd/ location you defined in the preceding step in the setenv.sh file.

6. Restart Tomcat.

Monitor Test Suite Executions Through APIs

View detailed information about test suite execution through REST calls.

You can retrieve test suite execution data for applications under test by phase names and ids using the test-suite-

executions REST API.

Type Description

GET https://<host>:<port>/cdd/cds/0000/v1/

applications/{applicationId}/application-

versions/{applicationVersionId}/test-suite-

executions

Method Parameters

Parameter Type Description

applicationId path[long] applicationId

applicationVersionId path[long] applicationVersionId

test_source query[long] testSourceId

sort_field query[string] sortField

sort_direction query[string] sortDirection

filter query[string] free text filter

endpointId query[long] freeTextFilter

tag query[string] tags

environment query[long] environmentId

release query[long] releaseId

phase Array[long] phaseIds

release_name query[string] releaseName

release_version query[string] releaseVersion

phaseName query[string] phaseName

embed Array[string] embedFields

test_suite_execution_status Array[string] testSuiteExecutionStatuses

page_number integer pageNumber

page_size integer pageSize

Response Parameters

HTTP Status Code Reason

401 Unauthorized

403 Forbidden

404 Not Found

164

Continuous Delivery Director 8.5

Curl

curl -X Get --header "Accept: application/json" "http://<host>:<port>/cdd/cds/0000/v1/applications/

{application-id}/application-versions/{application-version-id}/test-suite-executions"

Response Body

{

"data": [

{

"application": {

"displayName": "string",

"id": 0,

"name": "string"

"applicationVersion": {

"displayName": "string",

"id": 0,

"name": "string"

"applicationVersionChanges": [

{

"application": {

"displayName": "string",

"id": 0,

"name": "string"

"applicationVersion": {

"displayName": "string",

"id": 0,

"name": "string"

"buildNumber": "string",

"buildUrl": "string",

"changeId": "string",

"commitId": "string",

"creationDate": 0

}

"businessApplication": {

"displayName": "string",

"id": 0,

"name": "string"

"businessApplicationVersion": {

"displayName": "string",

"id": 0,

"name": "string"

"environments": [

{

"displayName": "string",

"id": 0,

"name": "string"

165

Continuous Delivery Director 8.5

}

"executionDuration": 0,

"executionEndDate": 0,

"executionStartDate": 0,

"externalId": "string",

"id": "string",

"isOnlyIntelligentTestSuites": true,

"name": "string",

"numberOfDisabledTestSuites": 0,

"numberOfErrorTestSuites": 0,

"numberOfFailedTestSuites": 0,

"numberOfIntelligentTestSuites": 0,

"numberOfSkippedTestSuites": 0,

"numberOfSuccessfulTestSuites": 0,

"numberOfTestSuites": 0,

"phase": {

"displayName": "string",

"id": 0,

"name": "string"

"phaseExecutionId": "string",

"pluginsCounter": [

{

"displayName": "string",

"id": 0,

"name": "string",

"numberOfDisabledTestSuites": 0,

"numberOfErrorTestSuites": 0,

"numberOfFailedTestSuites": 0,

"numberOfSkippedTestSuites": 0,

"numberOfSuccessfulTestSuites": 0

}

"release": {

"displayName": "string",

"id": 0,

"name": "string",

"project": {

"displayName": "string",

"id": 0,

"name": "string"

"version": "string"

"strategyCounters": [

{

"count": 0,

"strategies": [

"string"

]

}

166

Continuous Delivery Director 8.5

"tags": [

"string"

"task": {

"displayName": "string",

"id": 0,

"name": "string"

"testSuiteResults": [

{

"application": {

"displayName": "string",

"id": 0,

"name": "string"

"applicationVersion": {

"displayName": "string",

"id": 0,

"name": "string"

"applicationVersionChanges": [

{

"application": {

"displayName": "string",

"id": 0,

"name": "string"

"applicationVersion": {

"displayName": "string",

"id": 0,

"name": "string"

"buildNumber": "string",

"buildUrl": "string",

"changeId": "string",

"commitId": "string",

"creationDate": 0

}

"businessApplication": {

"displayName": "string",

"id": 0,

"name": "string"

"businessApplicationVersion": {

"displayName": "string",

"id": 0,

"name": "string"

"endpoint": {

"displayName": "string",

"id": 0,

"name": "string"

167

Continuous Delivery Director 8.5

"environments": [

{

"displayName": "string",

"id": 0,

"name": "string"

}

"executionDetailedStatusDescription": "string",

"executionDuration": 0,

"executionEndDate": 0,

"executionStartDate": 0,

"executionStatusDescription": "string",

"externalId": "string",

"id": "string",

"name": "string",

"numberOfFailedTestCases": 0,

"numberOfSuccessfulTestCases": 0,

"phase": {

"displayName": "string",

"id": 0,

"name": "string"

"phaseExecutionId": "string",

"phaseExecutionStartDate": 0,

"plugin": {

"displayName": "string",

"id": 0,

"name": "string"

"release": {

"displayName": "string",

"id": 0,

"name": "string",

"project": {

"displayName": "string",

"id": 0,

"name": "string"

"version": "string"

"resultURL": "string",

"strategies": [

"string"

"tags": [

"string"

"task": {

"displayName": "string",

"id": 0,

"name": "string"

168

Continuous Delivery Director 8.5

"testCaseResults": [

{

"buildUrl": "string",

"changeId": "string",

"executionDuration": 0,

"executionEndDate": 0,

"executionStartDate": 0,

"executionStatus": "PASSED",

"externalId": "string",

"id": "string",

"name": "string",

"resultMessage": "string",

"resultURL": "string",

"testSuiteResultId": "string"

}

"testSuite": {

"id": "string",

"name": "string"

"testSuiteExecutionEndDate": 0,

"testSuiteExecutionOrder": 0,

"testSuiteExecutionStatus": "PASSED",

"testSuitesExecutionId": "string"

}

]

}

"maxNumberOfTestSuites": 0,

"pageNumber": 0,

"pageSize": 0,

"totalResultsCount": 0

}

Response Code

200

1. Log in to Continuous Delivery Director.

2. In the menu bar, click the initials of your user account

then select REST API.

3. Scroll down to the CDS section, and select test-suite-executions, then GET /applications/

{applicationId}/application-versions/{applicationVersionId}/test-suite-executions.

4. Specify the query parameters and run the API.

You must specify the application id and the application version id.

Related Links

REST API Reference on page 621

REST APIs let external systems configure, execute, and monitor release operations and applications without the need to

access the UI.

169

Continuous Delivery Director 8.5

View Adaptive Testing Results

You can view test results after a phase that includes an Adaptive Testing task runs.

You can access test details per test framework through the Adaptive Testing Results page. You can view the test status

and logs, and identify which tests failed. If you use Jenkins as your continuous integration hub, you can click a build

number to directly access build-related information and log files in Jenkins.

1. From Tests, click Adaptive Testing Results.

2. Configure the following filters:

•

Show By

Select either Application or Business Application.

•

Application/Business Application

Specify an application/business application name.

•

Application/Business Application Version

Specify an application/business application version number.

A list of test results displays.

3. To see results by test framework, such as Gradle Testing, select a table row, then click Results.

To see the release containing the adaptive testing task that has been executed, click the release name.

To see a popover summarizing the test execution results, click a table row on the Adaptive Testing Results page

Integration Testing

When applications (components or microservices) are logically grouped together in a business application, performing

integration tests is very important.

A typical release consists of multiple applications. Each application has its own set of tests that identifies defects of the

specific application. The purpose of integration testing is to expose defects in the interactions between applications and

subcomponents that are integrated into a business application. Successful integration tests ensure that the component

parts of your business application work correctly together as well as separately.

Table 2: Unit Testing vs. Integration Testing

Unit Testing Integration Testing

Tests each unit individually to make sure that application/

subcomponent works properly independent of other units.

Test applications/subcomponents together to make sure they can

be incorporated with each other without any issues.

Can be performed at any time. Is performed after unit testing. In Agile methodology, the order of

unit tests and integration tests is not important.

Can only detect errors within a single unit. Can detect errors resulting from units interacting with one another.

If you work according to the principles of Agile software development, you can perform integration testing continuously.

In continuous integration, you merge source code updates from all developers on a team into a shared codebase. By

continually merging source code and integration testing, you can avoid catastrophic merge conflicts. The Adaptive

Testing Results page and the Release Quality Report help you quickly locate the root cause of errors in integration

testing.

Continuous Delivery Director and Integration Testing

Continuous Delivery Director provides a comprehensive solution for performing integration testing. You can:

170

Continuous Delivery Director 8.5

•

Create test sources for business application versions and import tests. For more information, see Setting Up the Test

Module.

•

Create releases for each business application version and associate the relevant applications with the release. For

more information, see Create a Release.

•

Run integration tests through adaptive testing tasks in release phases. For more information, see Test Module Actions.

•

View integration test outcomes on the Adaptive Testing Results page. For more information, see View Adaptive

Testing Results.

•

Look at the release quality by business application in the Release Quality Report.. For more information, see Reports.

•

Import tests for a business application version. For more information, see Import and Export Test Sources.

•

Duplicate releases with business applications. For more information, see Duplicate Releases.

•

Assess the release risk taking into account business application testing using release scores. For more information,

see Release Risk Score.

•

Export releases with the business application version test sources embedded in the release DSL. For more

information, see Pipelines as Code.

Test Advisor

The test module includes the Test Advisor, an AI-based tool that helps you reduce your test cycle time by only running a

subset of your tests.

Working in Agile, development teams need short development and test cycles to rapidly deliver high-quality software

updates. You can add to your test pipeline an ever-increasing number of test frameworks (functional, APIs, performance,

and so on), test automation, and several CD/CI integration platforms. However, you need to balance the need for short

test cycles with the need to conduct the required tests. You need to fail fast, minimize the time taken to identify the root

causes of failures and fix problems immediately. Failing to deliver on time and at high-quality negatively impacts your

business.

The Test Advisor is an innovative approach to handling test cycles. This tool saves developer time by eliminating the

need to wait for test cycles to finish. A pipeline that contains a lot of test suites will take a long time to run, no matter how

automated that test pipeline is.

The Test Advisor helps you reduce testing time by intelligently selecting a subset of test suites.

Figure 23: Test Advisor-selected test suites

The Test Advisor also ensures that the test suites selected are relevant to the code changes because not all test suites

are relevant to the code changes that are made.

Using the Test Advisor tool, Continuous Delivery Director can shorten the time taken to run test suites, give fail fast

feedback to developers, and reduce the load on test environments. How does Continuous Delivery Director select the test

suites to run? Continuous Delivery Director uses a number of heuristics to determine which test suites to run:

•

Tests associated with code changes

•

Flaky tests

•

New or updated test suites

•

Tests marked as important

171

Continuous Delivery Director 8.5

Figure 24: Test Advisor uses heuristics

Tests Associated with Code Changes

Continuous Delivery Director uses the Test Advisor to run only those tests that are associated with the changed code.

Currently, Continuous Delivery Director uses an agent that is based on Java.

The agent (ct_agent) that is installed on the environment where the business application/application that is being tested

associates the test suites with the files that are changed as a result of the tests. The agent receives a notification from

Continuous Delivery Director every time a test suite is started. The agent identifies the classes that are examined. Then

Continuous Delivery Director notifies the agent that the test suite is complete. At the end of the test execution, the agent

generates a mapped list of all the files that were changed and the test suites that examined the changed files.

172

Continuous Delivery Director 8.5

Figure 25: Changed files mapping

The mapping information is sent to Continuous Delivery Director, and Continuous Delivery Director builds a map where

every analyzed file is associated with the test suites that analyzed that file. When a new build notification arrives.

Continuous Delivery Director finds and analyzes the list of files that were updated in the build. Continuous Delivery

Director then maps those files and generates a list of the test suites that are related to the updated files.

Figure 26: Test Advisor lists changed code files and associated test suites

Flaky Tests

The next heuristic is flaky tests. These are test suites with one or more of the following characteristics:

173

Continuous Delivery Director 8.5

•

Test suites that have failed many times in past executions

•

Test suites that are erratic and change from success to failure in successive test cycles

•

Test suites that have failed in the previous execution

If there is a discernable trend in the test suite results and the last several test runs are all successful then a test is not

identified as a flaky test. This kind of test result shows that an issue existed, but was subsequently fixed.

A test can be flaky because of a problem in the code or because of a problem in the test itself. A test suite that is identified

as flaky is automatically selected for the next test cycle.

New or Updated Test Suites

The next heuristic is new or updated test suites. For example, a developer adds a test suite or updates an existing test

suite with new test cases. Continuous Delivery Director can identify new or updated test suites through the test framework

plug-ins. These plug-ins supply new and updated test suite information to Continuous Delivery Director in different ways

but the result is the same - Continuous Delivery Director can identify changes in the tests in the various test frameworks.

The Test Module synchronizes test suites automatically. New and updated tests become part of the next test cycle and

are also part of the mapping that takes place during the test cycle. The next time the test cycle is run, any of the new and

updated test suites that are associated with changed files will be run as part of the test cycle and also subsequently if

these test suites stay relevant.

The last heuristic is identifying those tests that are marked by a user as important, and therefore as mandatory parts of the

test cycle. Continuous Delivery Director run important test suites in every execution of an adaptive testing task.

When you set up the agent, you can configure the agent to ignore parts of the code such as classes that are not relevant,

for example, because these parts of the code are third-party.

Tests Marked as Important

The last heuristic is identifying those tests that are marked as important, and therefore as mandatory parts of the test

cycle. Continuous Delivery Director runs important test suites in every execution of an adaptive testing task.

To mark a test as important, you select the Must run - Run Test Suite in Every Test Cycle option in the Edit Test Suite

page.

When you set up the agent, you can configure the agent to ignore parts of the code such as classes that are not relevant,

for example, because these parts of the code are third-party.

Test Advisor and Test Cycles

When all of the above heuristics have run, the test selection process is completed. When you set up adaptive testing

tasks in Continuous Delivery Director, you can either choose to run all tests or a Test Advisor-selected subset of tests as

described in this section.

To run the Test Advisor in your test cycles, in a Run Adaptive Testing task, select the Run a subset of test suites

selected by the Test Advisor option.

TIP

We recommend that you run all of the test suites at least for the first time in the test pipeline so that Continuous

Delivery Director can build the mapping before using the Test Advisor option. Once Continuous Delivery Director

has mapped the tests, we suggest that you use the Test Advisor in the earlier phases of a release pipeline to

fail fast and to identify issues to fix. In the later phases of the release pipeline, such as the pre-Production and

Production phases, we suggest that you again run all the tests to identify any outstanding issues.

Using the Test Advisor for test cycles:

174

Continuous Delivery Director 8.5

•

Saves time

•

Helps you select test suites wisely and see the breakdown

•

Lets you view results for each test framework

Test Advisor Summary

After a test cycle, you can see the execution results in a pop-up window, the Test Advisor Summary. You can access the

Test Advisor Summary as follows:

•

In an Adaptive Testing task that has run, hover over the task status:

Figure 27: Invoking the Test Advisor Summary - Adaptive Testing Task

The Task Advisor Summary pops up:

175

Continuous Delivery Director 8.5

Figure 28: Test Advisor Summary in an Adaptive Testing Task

•

In the Release Quality by Business Application/Application Version report, hover over the Test Distribution bar

graph:

176

Continuous Delivery Director 8.5

Figure 29: The Test Advisor Summary in the Release Quality Report

Test Suite Priority

The Test Advisor prioritizes which test suites to run in every test cycle according to the following heuristics:

•

New

The Test Advisor runs new test suites and test suites that have been added since the last test execution.

The Test Advisor automatically synchronizes the test catalog against the test repositories and determines if a new test

suite has been added.

•

Flaky

Flaky test suites:

–

Have failed many times in previous executions

–

Are unstable - results alternate frequently between success and failure

–

Have failed in the previous execution

The Test Advisor parses all saved test execution results to identify flaky tests. A test that fails frequently has a higher

chance of being selected

•

Error

The Test Advisor identifies tests that have not run due to system or environmental errors. These tests are automatically

included in the list of tests to run.

•

Relevant

177

Continuous Delivery Director 8.5

Continuous Delivery Director runs only those test suites that are relevant to the changes in the code that have

triggered the adaptive testing task. When a new build enters the CD pipeline, the Test Advisor identifies the classes

that have changed and selects the test suites that cover it.

•

Changed

Runs test suites that have been updated since the last test execution.

The Test Advisor automatically synchronizes the test catalog against the test repositories and determines if an existing

test suite has been updated.

•

Must Run

You can select mission-critical test suites to be included with the prioritized test suites in every test cycle. In Edit Test

Suite, select Must run - Run Test Suite in Every Test Cycle. Continuous Delivery Director runs these test suites in

every execution of the associated adaptive testing task.

For more information, see Test Module Actions.

Test Advisor Analytics and Release Quality

You can see detailed information about the quality of your release and quickly assess any risks. You can also use this

report to evaluate the effectiveness of your test automation strategy.

Figure 30: Release Quality Report

The data for this report includes all releases that have been created in the workspace by any user.

You can also see test information for any associated work items that are defined in your agile management tool (Jira/

Rally).

You can use the Release Quality Report to:

178

Continuous Delivery Director 8.5

•

Save time

•

Select test suites wisely and see the breakdown

•

View results per test framework

•

Optimize test coverage and find gaps in the test plan

The Release Quality report provides the following information:

•

General Information

–

Number of builds that exist for the specified business application version/application version.

–

Time saved during test suite execution due to implementation of Test Advisor recommendations.

–

Number of flaky test suites detected either with inconsistent execution results or test suites failed on the last

execution.

–

Number of files without test coverage.

–

Number of tests/test suites that have failed

•

Test Distribution

–

Bar graph showing the distribution of test suite execution. To see more information, hover over the bar graph.

–

Number of failed tests out of total tests recommended by the Test Advisor.

–

Number of failed tests out of total tests not recommended by the Test Advisor.

–

Time to first test failure.

–

Adaptive Testing task duration.

–

Change ID of build or commit that triggered the Adaptive Testing task.

NOTE

If you use Jenkins as your continuous integration hub, you can click the build number to directly access

build-related information and log files in Jenkins.

–

Details of phase containing the Adaptive Testing task executed. Hover over the phase name to see the details.

–

Testing framework from where the test suites were imported.

•

Code Churn

Shows in graphical format the code churn in releases and in business application versions/application versions. This

heuristic is updated on every commit.

•

Flaky Test Suites

Lists the flaky test suites detected either with inconsistent execution results, or test suites that failed on the last

execution.

•

Uncovered / Updated Files

Lists the files that were changed during the release but have no associated test suites.

•

Incomplete Work Items

Shows information about the test coverage of work items in a given release (features, user stories, defects, and so

on). This graph shows how well a work item has been tested and whether that work item has passed or failed the

associated tests.

For every release work item, you can see:

–

The commits that have been done for this work item, and the test coverage status.

–

The tests executed for a specific work item and how many of them are flaky.

To access the report, select Reports, then Release Quality from the top menu. Alternately, in a release, open the

hamburger menu and click Go to Release Quality Report.

To create a new report, open the Release Quality report and select releases, business applications, business application

versions, applications, and application versions.

Follow these steps:

1. Open the Release Quality report and in Release, specify a release name.

179

Continuous Delivery Director 8.5

The Business Application Version/Application Version Report summary is displayed.

2. Under Business Application Version/Application Version Report, select the release name.

The Release Quality by Business Application Version/Application Version report is displayed.

Note: You can change the release and business application/application version as needed.

NOTE

The following videos are extracted from the Test Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

Mark Tests as Must Run

This video shows you how to mark tests as Must Run in Continuous Delivery Director. This setting ensures that these

critical path tests run in every test execution.

Enable Adaptive Testing

This video shows how to enable adaptive testing for a Continuous Delivery Director release. Enable adaptive testing for

Continuous Delivery Director to intelligently run only the appropriate tests based on heuristics.

Test Orchestration Results And Reporting

This video shows how to view test results and key reports with test metrics in Continuous Delivery Director.

Continuous Testing Agents

Dedicated programs collect and analyze adaptive testing metrics.

Version 2.2

Continuous Testing (CT) agents are automated services that poll test sources to verify if specified test suites have been

updated. The agent is a data-gathering component. This component collects detailed information about applications

under test as test suites are executed. After the tests are run, the agent reports the collected data to Continuous Delivery

Director. An agent:

•

Analyzes the interactions between application source files and test suites.

•

Determines which test suites are executed when an application source file changes.

•

Is referenced by an AUT (application under test) when a new build triggers testing in a release.

•

Connects to Continuous Delivery Director using the WebSocket protocol.

Agents are installed in an environment where a business application/application is being tested. An agent receives a

notification from Continuous Delivery Director every time a test suite is started. The agent identifies the classes that are

examined. Then Continuous Delivery Director notifies the agent that the test suite is complete. At the end of the test

execution, the agent generates a mapped list of all the files that were changed and the test suites that examined the

changed files. This mapping is used by Continuous Delivery Director to instruct the Test Advisor to recommend running

only those tests that are associated with the changed code.

The following illustration shows a simple deployment in which an agent collects application and test metrics and relays this

information to Continuous Delivery Director. You can view these metrics in releases and reports.

180

Continuous Delivery Director 8.5

Figure 31: CT Agent Architecture

There are two types of CT agents:

•

.NET

For testing applications written in C# (C sharp).

•

Java

For testing Java applications.

Download Options

Use one of the following options to download the latest CT agent (ct_agent.jar) version:

181

Continuous Delivery Director 8.5

IMPORTANT

Downloading the ct_agent.jar file is a prerequisite for installing both the .NET and Java CT agents.

Method Info

wget wget -O ct_agent.jar https://

cspdl.broadcom.com/s/

vklrdye94fyyfi7nw99frkf2y7dnt1h8?

LCK=ent.box.com

MD5 edee233c7befd5bf96c6aa32047cd627

Click Download Button

Use one of the following options to download the latest CT agent DLL (ct_agent.dll) file:

IMPORTANT

Downloading the ct_agent.dll file is a prerequisite for installing the .NET CT agent only.

Method Info

wget wget -O ct_agent.jar https://

cspdl.broadcom.com/s/

d6cwhh8hht0n7p1dzm02xslzubacxg9l?

LCK=ent.box.com

MD5 4daf434c3dba818499302548e68a2a8b

Click Download Button

Configure Continuous Testing Agents

Add continuous testing (CT) agents to your release pipelines to monitor and optimize application testing.

A machine is provisioned where Continuous Delivery Director is installed and activated.

Continuous Delivery Director provides the following types of CT agents:

•

.NET

For testing applications written in C# (C sharp).

•

Java

For testing Java applications.

The following procedure contains setup instructions for the settings.properties files.

NOTE

These instructions are relevant to both the .NET and the Java CT agent types.

1. In the Continuous Delivery Director server, navigate to the home folder, and open settings.properties.

2. In settings.properties, ensure that the following property is set to true: cdd.ct_agent.enabled=true

3. In the Continuous Delivery Director server home folder, under the conf folder create a settings.properties file:

cdd.continuous_testing_agent.cdd.application=<application name from CDD>

182

Continuous Delivery Director 8.5

cdd.continuous_testing_agent.cdd.environment=<env name from CDD>

cdd.continuous_testing_agent.cdd.api_key=<API key from CDD>

cdd.continuous_testing_agent.cdd.url=http://<CDD hostname>:8080/cdd/

cdd.continuous_testing_agent.cdd.tenant_id=00000000-0000-0000-0000-000000000000

cdd.continuous_testing_agent.packages.include=com.ca.cdd

cdd.continuous_testing_agent.packages.exclude=com.ca.cdd.ws,com.ca.cdd.controllers,com.ca.cdd.dao

cdd.continuous_testing_agent.cdd.url_path=/ct_agent

cdd.continuous_testing_agent.cdd.trust_self_signed_certificate=true

cdd.continuous_testing_agent.cdd.disable_host_verification=true

cdd.continuous_testing_agent.log.configuration_file=/home/cdd/.cdd/ct_agent.logback.xml

cdd.continuous_testing_agent.log.maximum_memory_size=800

cdd.continuous_testing_agent.log.level=trace

4. Set a path type environment variable to the CT agent home folder: CDD_CT_AGENT_HOME_FOLDER.

After initialization, the agent determines that \conf\settings.properties is located at the specified path.

CDD_CT_AGENT_HOME_FOLDER=C:\Users\bob04\.cdd

Continue to the instructions for configuring either a .NET or a Java CT agent.

Configure a Java CT Agent

To monitor adaptive testing tasks running on Java applications in a release, you install and configure a Java CT Agent on

the Continuous Delivery Director server.

•

Continuous Delivery Director is installed with the Test module. For more information, see Install Continuous Delivery

Director with the Test Module

•

You have downloaded the ct_agent.jar file. For more information, see Continuous Testing Agent

The Continuous Testing Agent is a Java agent that is used by SUT (System Under Test) applications to monitor the

interactions between application source files and Continuous Delivery Director test suites.

This monitoring is used to determine which test suites to run when an application source file changes.

1. Stop the Tomcat service.

For example, enter shutdown.sh.

2. In the SUT setenv.sh in the Tomcat bin folder, add the following lines if not found:

export CDD_HOME_FOLDER=/home/cdd/.cdd

export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/home/cdd/.cdd/ct_agent.jar"

NOTE

The lines above are for the CentOS operating system.

3. Upload ct_agent.jar to the /home/cdd/.cdd/ location you defined in the preceding step in the setenv.sh file.

4. Restart Tomcat.

Configure a .NET CT Agent

Install and configure a .NET CT Agent on the Continuous Delivery Director server so that you can monitor adaptive testing

tasks running on C# (C sharp) applications in a release.

183

Continuous Delivery Director 8.5

•

Windows Server 2019 or Windows 10

•

Java (JRE) 8 or higher is installed and enabled

•

A CDD_HOME_FOLDER environment variable is configured on the Windows Server

Follow this procedure to prepare a Windows environment with a working CT agent for adaptive testing. The CT agent

requires that IIS and specific IIS components be enabled on Windows Server 2019 or Windows 10. The setup cannot

proceed if IIS is not detected and specific IIS components are not enabled.

1. Run the CT agent Java application on Windows.

a) Copy ct_agent.jar to the $CDD_HOME_FOLDER\lib directory. <link to the ct agent.jar download page>

•

The default home folder of OS user cdd is: \home\cdd

•

The default home folder of the Continuous Delivery Director product is: \home\cdd\.cdd

b) Under C:\<$CDD_HOME_FOLDER>\conf, create a settings.properties file.

C:\cdd\conf\settings.properties

c) Configure the settings.properties file as shown above.

d) Run ct_agent.jar <java -jar ct_agent.jar>

e) Verify that you are connected by checking the CT agent logs.

The log files are located at C:\<$CDD_HOME_FOLDER>\logs\ct_agent.log.

2. Install ct_agent dll on your Windows and run it with your application under test.

a) Install ct_agent.dll on your Windows machine.

Get ct_agent.dll from <link to the ct agent.dll download page> and put it under C:\<CUSTOM_PATH>. For example:

<C:\incoming\ctagent\x64>

b) Configure the application under test.

Ensure that the application under test is running with the following environment variables:

184

Continuous Delivery Director 8.5

•

name="COR_PROFILER" value="{f42148d0-acbe-4fbe-be18-b46845e1a26a}" - COR profiler ID of

ct_agent.dll ( need to be exact as display)

•

name="COR_PROFILER_PATH" value="C:\<CUSTOM_PATH>\ct_agent.dll" - path to ct_agent.dll 32 bit

•

name="COR_PROFILER_PATH_64" value="C:\<CUSTOM_PATH>\ct_agent.dll" - path to ct_agent.dll

64 bit

•

name="COMPLUS_ProfAPI_ProfilerCompatibilitySetting" value="EnableV2Profiler" -

Profiler compatibility setting, should be exact as displayed.

•

name="CDD_CT_AGENT_LOG_ENABLED" value="false" - (true/false; Default: false) Whether to disable

logging completely.

•

name="CDD_CT_AGENT_LOG_CONSOLE_ENABLED" value="true" - (true/false; Default: false) Lets the user

keep a clean console for the profiled process, and possibly output logs only to files.

•

name="CDD_CT_AGENT_LOG_LEVEL" value="trace” - (trace, debug, info, warning, error, fatal; Default:

debug)

•

name="CDD_HOME_FOLDER" value=“C:\<CDD_HOME_FOLDER> - (Default: read on) The logs will be written

to a /logs sub-directory of this folder. If none is provided, the logs will be written to /tmp/cdd_profiler_logs .

•

name="CDD_CT_AGENT_INCLUDED_MODULES" value=“<Application under test name>” -

(str1,str2,str3; Default: None) Filtering by the containing dll/exe file. Only functions from modules containing the

provided string(s) are treated. Comma separated strings - with no spaces before/after the commas.

•

name="CDD_CT_AGENT_EXCLUDED_MODULES" value="module_prefixlong" - (str1,str2,str3; Default:

None) Only when some includes (above) are defined - you are able to exclude - more specific module names.

•

name="CDD_CT_AGENT_INCLUDED_SOURCE_FILES" value=".cs" - (str1,str2,str3; Default: None)

Functions defined in source files which include those strings.

•

name="CDD_CT_AGENT_EXCLUDED_SOURCE_FILES"

value="file_path_prefix3,file_path_prefix4 " - (str1,str2,str3; Default: None)

•

name="_NT_ALT_SYMBOL_PATH" value="C:\pdbs" - application under test .pdb file should copy to this

path.

For example, if the application under test is running under IIS, add the environment variables above to the

applicationHost.config file.

c) Make sure that the application under test is running as .NET Framework 4.7.

d) Make sure that the following DLLs exist on your server.

The %PATH% environment variable specifies a set of directories where executable programs, such as DLLs, are

located. Validate that the Windows environment variable %PATH% points to all DLL locations.

NOTE

If you prefer, you can also copy these DLLs to a specific location, and add this location to the %PATH%

environment variable.

List of DLLs:

185

Continuous Delivery Director 8.5

•

C:\Windows\System32\advapi32.dll

•

C:\Windows\System32\bcrypt.dll

•

C:\Windows\System32\bcryptprimitives.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrjit.dll

•

C:\Windows\System32\combase.dll

•

C:\Windows\System32\gdi32.dll

•

C:\Windows\System32\gdi32full.dll

•

C:\Windows\System32\imm32.dll

•

C:\Windows\System32\kernel.appcore.dll

•

C:\Windows\System32\kernel32.dll

•

C:\Windows\System32\KernelBase.dll

•

C:\Windows\System32\mscoree.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll

•

C:\Windows\Microsoft.NET\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll

•

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorrc.dll

•

C:\Windows\System32\msvcp_win.dll

•

C:\Windows\System32\msvcp140d.dll

•

C:\Windows\System32\msvcrt.dll

•

C:\Windows\System32\ntdll.dll

•

C:\Windows\System32\ole32.dll

•

C:\Windows\System32\oleaut32.dll

•

C:\Windows\System32\psapi.dll

•

C:\Windows\System32\rpcrt4.dll

•

C:\Windows\System32\sechost.dll

•

C:\Windows\System32\shlwapi.dll

•

C:\Windows\System32\ucrtbase.dll

•

C:\Windows\System32\ucrtbase_clr0400.dll

•

C:\Windows\System32\ucrtbased.dll

•

C:\Windows\System32\user32.dll

•

C:\Windows\System32\vcruntime140_1d.dll

•

C:\Windows\System32\vcruntime140_clr0400.dll

•

C:\Windows\System32\vcruntime140d.dll

•

C:\Windows\System32\version.dll

•

C:\Windows\System32\win32u.dll

•

C:\Windows\System32\ws2_32.dll

Continue to the instructions for running a .NET CT agent.

Run a .NET Continuous Testing Agent

Perform these steps to ensure that the .NET agent is available for use.

The .NET agent is installed and configured.

1. In IIS, start the application under test.

2. From the command line, start ct_agent:

java -jar c:\cdd\ct_agent.jar

186

Continuous Delivery Director 8.5

To run the process in the background use javaw -jar c:\cdd\ct_agent.jar

The agent logs are available under C:\Users\<USER>\.cdd\logs\ct_agent.log or C:\Users\Administrator

\.cdd\logs\ct_agent.log. IIS profiler logs should appear under C:\Windows\System32\inetsrv, and can be

copied later to a custom-defined path such as C:\tmp\cdd_profiler\cdd_profiler_0.log.

When you access the application for the first time, a profiler success message should appear in Windows Event Viewer,

such as:

.NET Runtime version 4.0.30319.0 - The profiler was loaded successfully. Profiler CLSID: '{0gig07oymq-

vffh-2n29-zv6k-004h1v0f71}'. Process ID (decimal): 5624. Message ID: [0x2507].

Test Module Actions

This topic lists the actions available when the test module is configured.

TROUBLE

If the Test Advisor does not work as expected, check that the API key is configured correctly for the current

project.

Action Steps Description

Sync Tests

1. In Adaptive Testing Catalog, select

the Test Sources tab.

2. Select one or more test sources.

3. A floating actions menu appears above

the test sources table.

4. Click the Sync icon.

Syncs all tests added to or removed from

the system since the last import.

Filter Test Suites Filters test suites by tags.

187

Continuous Delivery Director 8.5

Sort Test Suites Select the icon next to the field header, to

sort the list in ascending or descending

order.

To find test suites quickly, you can sort the

Adaptive Testing Catalog list by Import

Date, Endpoint Name, Test Suite Name,

or Test Source Name.

Note: Uppercase letters are always sorted

first.

Edit Test Suites

1. In the Adaptive Testing Catalog,

select the Test Suites tab, and click a

test suite name.

The Edit Test Suite dialog opens.

2. You can add or remove tags. To

ensure that the test suites run in every

execution of the associated adaptive

testing task, select Must run - Run

Test Suite in Every Test Cycle.

Create an Adaptive Testing Task

1. Under Releases, select a release

2. In a phase, select Create Task.

3. In Task Type, select Run Adaptive

Testing.

4. In Tags, start to type to specify one or

more tags. Leave empty to execute all

the test suites under the application

version.

5. In Build/Commit ID, specify the build

number or commit ID of the code to

test.

6. Optionally, select Run a subset of test

suites selected by the Test Advisor.

7. Select Create.

View Application Testing Insights After a Phase that includes an Adaptive

Testing task runs, go to Tests and select

Application Testing Insights.

Application Testing Insights helps you

find the trend or anomaly in tests that have

run.

A bar graph displays the percentage of

successful test suite executions in a given

phase. If you want to see more details,

select on a specific column in the graph.

If you use Jenkins as your continuous

integration hub, you can click a build

number to directly access build-related

information and log files in Jenkins.

NOTE

The following videos are extracted from the Test Orchestration training course. This course provides extra

information, context, and examples to augment the product documentation.

To access this course, see Broadcom Enterprise Software Academy.

Mark Tests as Must Run

This video shows you how to mark tests as Must Run in Continuous Delivery Director. This setting ensures that these

critical path tests run in every test execution.

188

Continuous Delivery Director 8.5

Create Testing Task

This video shows how to create an adaptive testing task in Continuous Delivery Director. This task runs the relevant tests

each time the phase is run.

Run Testing Task

This video shows how to run an adaptive testing task in a Continuous Delivery Director release and how to view test

results after the task completes.

Update Test Tags

This view shows how to update test tags in a Continuous Delivery Director release. You can update tasks between

release runs to change whether or not the test runs.

Import and Export Test Sources

You can export and import the test sources of business application versions or application versions.

Importing and exporting test sources saves manual labor. You can either import test sources from a URL or from your

local machine.

Import a Test Source

1. From Tests, click Adaptive Testing Catalog.

2. Click the Import icon.

The IMPORT TEST SOURCE dialog opens.

3. Do one of the following:

•

a. Select Repository.

b. Specify a file source to retrieve application-related JSON files.

NOTE

To create a file source, in RELEASES, click File Sources, then New File Source.

c. Specify a relative file path to a JSON file in your source control repository.

•

a. Select Local Machine.

b. Browse to the required DSL file.

4. Click Import.

Export a Test Source

1. From Tests, click Adaptive Testing Catalog.

2. Configure the following filters:

•

Show By

Select either Application or Business Application.

•

Application/Business Application

Specify an application/business application name.

•

Application/Business Application Version

Specify an application/business application version number.

3. Click Test Sources.

A list of Test Sources for the specified application/business application version displays.

189

Continuous Delivery Director 8.5

4. Select a test source table row.

5. Click the Export icon.

Continuous Delivery Director generates a DSL file download with the test source JSON.

{

"objects": [

{

"applicationVersion": "Local|AppForNewWebBankingRegulations/VER01",

"name": "cdd-app-integration-testing",

"kind": "TestSource",

"endpoint": "Gradle WebBanking app repo",

"plugin": "proxy_id|Gradle Testing/1.9",

"parameters": {

"jvmParameters": "-Dtest.HOST=E2E-integration-unit-testing-platform.broadcom.net",

"branch": "nightly"

"type": "Import Test Suites",

"tags": [

"integrationTests"

]

}

]

}

Test Source Templates

Test Source Templates are predefined configurations that help test designers quickly create test sources for new

application versions.

When the CI tool sends a build notification for a new application version (branch), CDD creates the application version,

and based on the Test Source Templates creates the test sources and imports the tests. This process replaces the

manual step of copying the test source from the previous application version and allows for a fully automated CI/CD

pipeline without human intervention.

More Information:

•

Create Test Source Templates

•

Export Test Source Templates Parameters

•

Import/Export Test Source Templates

•

Remove Test Source Templates

Create Test Source Templates

You have been granted Can manage applications permissions.

1. From the Tests menu, click Test Source Templates.

2. Select the application.

3. Click New Test Source Template.

4. Enter a name for the test source template and select a plug-in and an endpoint.

A list of import and execution parameters appears for the selected plug-in and endpoint.

190

Continuous Delivery Director 8.5

5. Fill in the plug-in input parameters.

6. Specify one or more tags to label the imported test suites.

7. Click Create.

The test source template is listed in the Test Source Templates page under the application.

Export Test Source Templates Parameters

You have been granted Can manage applications permissions.

You can configure the CI tool to include specific parameters in the build notification data that can be used to create new

test sources based on the template. The field is specified in JSON format. To get the JSON format of a specific test source

template, you can export the test source template Parameters.

If you use Jenkins as your CI tool, you can copy and paste test source templates in JSON format into the Test Data field

in the Plug-in for Jenkins.

1. From the Tests menu, click Test Source Templates.

2. Select an application.

3. Select one or more test source template table rows.

A floating actions menu appears above the test source template table.

4. Click the export icon.

The test source template parameters file is downloaded to your machine in JSON format.

Import/Export Test Source Templates

You can export and import Test Source Templates as DSL.

You have been granted Can manage applications permissions.

Export Test Sources

1. From the Tests menu, click Test Source Templates.

2. Select an application.

3. Select one or more test source template table rows.

4. From the top menu click the export icon.

The test source object file is downloaded to your machine in JSON format.

Import Test Sources

1. From the Tests menu, click Test Source Templates.

2. Select an application.

3. From the top menu click the import icon.

A dialog opens that allows you to upload the DSL file either from a local machine or from a source code repository by

selecting a file source.

Remove Test Source Templates

Remove test source templates that you no longer need.

191

Continuous Delivery Director 8.5

You have been granted Can manage applications permissions.

1. From the Tests menu, click Test Source Templates.

2. Select an application.

3. Select one or more test source template table rows.

A floating actions menu appears above the test source template table.

4. Click the garbage can icon and remove.

The test source templates are removed from the test source template table.

192

Continuous Delivery Director 8.5

Security

The Security feature allows you to perform vulnerability assessment scanning and provides the status of the application

from a security perspective.

Using a Security Source, CDD Integrates with 3rd party vulnerability scanning tools and retrieves scanning results. The

Security Summary report presents the severity level using the industry standard scales: Critical, High, Medium, Low, and

None (if the item was not rated by the security scanning application).

The Security Items report lists the vulnerabilities that exist for a specific application version.

CDD integrates with Grafana to present security vulnerabilities metrics. At the Grafana dashboard, you can create a panel

to track the application’s security state at configured intervals. While CDD displays the total number of vulnerabilities,

Grafana’s security panel dynamically displays the number of newly created and resolved vulnerabilities. For more

information, see Plug-in for Grafana.

More Information

•

Security Sources

•

Security Summary Report

•

Security Items Report

Security Sources

The Security Sources page allows you to configure security sources to retrieve scan results from your vulnerability

scanning tools for a specific application version.

Use the ellipsis icon (three dots menu) associated with a security source to:

•

Disable a security scan. If a scan is disabled, no scan will be performed until the security source is enabled.

•

Retrieve the data for the project version scan status.

•

Delete a security source.

Create Security Source

When a user creates a new security source, they define what system CDD is connecting to, connect to an endpoint, and

then configure the security source and define to which project they are connecting to in the selected vulnerability tool.

If the 3rd party uses a different severity level scale, CDD maps to levels that CDD uses. For example, if the reported

levels are Blocker, Critical, Major, Minor, and Info, then CDD will map the security levels as:

•

Blocker = Critical

•

Critical = High

•

Major = Medium

•

Minor = Low

•

Info = None

To create a security source:

1. From the Security dropdown menu, select Security Sources. On the Security Sources page, select the required

Application and Application Version options.

2. In the SECURITY SOURCES screen, select New Security Source. The CREATE SECURITY SOURCE dialog box

opens.

3. Enter a Name and optionally, a description.

4. From the Plug-in dropdown list, select the required vulnerability scanning tool you want to use.

193

Continuous Delivery Director 8.5

5. From the Endpoint dropdown list, select the required endpoint.

NOTE

Registering an endpoint is mandatory while configuring a security source.

6. Fill in the required information in the Input Parameters area.

NOTE

The above entities are inherited from the plugin’s manifest of the selected vulnerability scanning tool that is

selected. These manifests may vary for each selected vulnerability scanning tool.

7. Select or create one or more tags to tag the security source.

8. In the Send Vulnerability Notifications To dropdown list, select the recipients assigned to the project.

NOTE

By default, the logged in user’s email address is selected.

9. In the Severity Level Notifications dropdown list, define the level of Severity included in the vulnerability notification

sent by CDD.

NOTE

Notifications are sent based on the level of severity you select from the dropdown list. If you select ‘Critical’

as an option, then only the critical notifications will be sent. If you select ‘Medium,’ then notifications will be

sent for Medium, High and Critical security levels. If left empty, then no notifications will be sent.

10. For First Occurrence, specify a time you want the vulnerability scan to be performed.

11. Select the Does not repeat option and set a recurrence for the security scan to be performed.

NOTE

If a recurrence is not set, the scan is not performed automatically. You need to perform the scan manually.

Use the Custom option to define a specific time you want the scan to be performed.

12. Select Create. A new security source is created and is shown in the Security Sources page.

Edit Security Source

To edit a security source:

1. In the Security Sources page, click the required Name link.

2. In the Edit Security Source dialog, make the required changes.

3. Click Save.

Import and Export Security Sources

You can export and import the security sources of application or application versions. Importing and exporting security

sources saves manual labor. You can either import security source templates from a URL or from your local machine.

Security Summary Report

The Security Summary Report allows you to view the summary of vulnerability scanning results for a specific Application

Version or group of Application Versions that are associated with a Business Application Version. You can also create

a view that lists all the application versions of the current project, selected project or all the projects which the user is

permitted to view the security details report.

The summary sections displays the sum of security vulnerabilities classified by ‘Critical,’ ‘High,’ ‘Medium,’ ‘Low’ and ‘None’

severity of all the Application Versions.

This line item shows the data for a specific Application Version. Several Application Versions can be associated with a

Business Application Version.

•

When the user selects an Application Version, the report shows the data for the selected Application Version.

•

When the user selects a Business Application Version, the report shows the data of all the Application Versions that

are associated with the selected Business Application Version.

194

Continuous Delivery Director 8.5

To run the Security Summary Report:

1. From the Security dropdown menu, select Security Summary Report.

2. Specify the Application/Business Application/Project and the Application Version/Business Application

Version/Project Version.

Using the filter icons on the columns header, you can filter the results by plugin or category.

The number of rows displayed in the Security Summary Report depends on the number of categories supported by the

selected plugin.

The user can show the report using the selected Reference ID (CVE).

NOTE

The numbers that appear in the Critical, High, Medium, Low and None columns in the report are links. When you

click a link, the Security Items Report is displayed for the selected vulnerability level. For more information, refer

to Security Items Report.

Security Items Report

This report displays the list of vulnerabilities for the selected Application and Application Version.

To generate the Security Items Report, you select the Application and then select Application Version.

After the report is generated, you can filter the number of rows to be displayed using:

•

the Plugin, Category and/or Severity filter for the selected plugin.

•

the Reference ID (CVE) option in the Reference column.

NOTE

In the Security Items Report, the values shown in the Reference column are links.

195

Continuous Delivery Director 8.5

Integrations

Integrate with other continuous delivery tools through configurable plug-ins

You can integrate Continuous Delivery Director with other continuous delivery tools through configurable plug-ins. Plug-ins

give you the flexibility to orchestrate your end-to-end continuous delivery process in a single release workflow.

Integration through plug-ins lets you extend Continuous Delivery Director functionality and can provide the following

capabilities:

•

Import Application Models from Deployment Tools

Plug-ins can import application models from Automic@ Continuous Delivery Automation for use in Continuous Delivery

Director.

•

Instrument Continuous Delivery Tasks

Plug-in tasks let you instrument important actions in your continuous delivery pipeline from remote components in the

context of Continuous Delivery Director releases.

•

Import Release Work Items from Agile Tracking Tools

Plug-ins can integrate with tracking tools to annotate releases with related work items.

You can also develop custom plug-ins for integrations that are not provided in a packaged plug-in.

This section describes how to work with packaged plug-ins and develop custom plug-ins.

Download Options for Integrations

Continuous Delivery Director makes your release pipeline work better by letting you integrate industry-leading software

and platforms with Continuous Delivery Director. You can download integrations in several ways:

•

From the plug-ins page on cddirector.io

•

Clicking the download icon in integration-related documentation topics:

Figure 32: download icon

•

For Linux users, entering wget commands such as

wget -O cdd-endevor-plugin.war https://cspdl.broadcom.com/shared/

static/88usmlbbk142rlvpkdqwkv8wbpkhnsyo.war?LCK=ent.box.com

You can also validate the integrity of your downloads using the MD5 hash checksums shown in integration-related

documentation topics, such as

0187bc8ff38f71247bad696deeb0ca8e

For testing-related integrations, such as the Maven Testing plug-in, you can:

•

Download Docker images from the Customer Support Portal

•

If you do not want to use docker pull, you can download TAR files from the Customer Support Portal

Instructional Video

The following video shows how to use plug-ins to extend the capabilities of Continuous Delivery Director so it can

communicate with other products:

196

Continuous Delivery Director 8.5

Integration Updates

Review the latest information about integrations with Continuous Delivery Director.

Continuous Delivery Director is committed to providing an ever-growing and evolving set of product integrations that

enable you to orchestrate complex release pipelines at high velocity and high quality. Read the latest updates about the

integrations we offer in the following section.

4-October-2022

New Features

Manual Deployment Plug-in

The Manual Deployment plug-in runs automatically and performs the 'set build' based on the task's specified application

version and build number for the phase's environment.

For more information, see Manual Deployment Plug-in.

21-September-2022

Enhanced

Red Hat Ansible Tower Plug-in

Added support for Job Slicing. The plugin now identifies that the job type is workflow and retrieves the same logs as the

'Run Workflow Job' task.

Automic Continuous Delivery Automation (CDA) Plug-in

Users can now use the CDD applications as the CDA components when creating a package. Also, the user can specify an

Application from which the components will be imported and created as applications in CDD.

SonarQube Plug-in

Security source capability was added to the plug-in version 2.0-10. This functionality allows you to retrieve the security

items from Sonarqube to CDD. This allows you to view a security summary report, view a detailed items report, and using

Grafana create a dashboard that shows the items’ resolution progress.

03-August-2022

Enhanced

DX App Synthetic Monitor Plug-in

You can now update the monitor’s attributes. For instance, if due to the new deployment the application URL has

changed, using the new task, users can update the monitor with the new application URL.

197

Continuous Delivery Director 8.5

29-June-2022

New Features

Test Data Manager Plug-in

This plug-in integrates with Test Data Manager and supports the API-driven tasks like running the data generation flows

and publishing the jobs.

For more information, see Test Data Manager Plug-in.

Enhanced

Slack Plug-in

The following update is made for plug-in version 2.0-3:

•

Added a new field to the slack plug-in endpoint - "Messaging Method". This field allows to select two options:

1. Webhook - existing functionality - the user must enter a Webhook that was generated by Slack.

2. Slack App - the user must enter the token with the "chat:write" permission.

The following update is made for plug-in version 2.0-2:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following update is made for plug-in version 2.0-1:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

For more information, see Slack Plug-in.

App Synthetic Monitor Plug-in

The following update is made for plug-in version 1.2-15:

•

Bugfix: Activate Monitor by Tag fails due to a large response.

The following update is made for plug-in version 1.2-14:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

For more information, see App Synthetic Monitor plug-in.

Micro Focus LoadRunner Enterprise Plug-in

The following update is made for plug-in version 1.0-3:

•

Filter by Folders: You can now specify a test folder path in the format of folder1/sub-folder/sub-folder-2. Only the tests

from the specified folder and sub folders will be imported.

The following update is made for plug-in version 1.0-2:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

For more information, see Micro Focus LoadRunner Enterprise Plug-in.

198

Continuous Delivery Director 8.5

31-May-2022

Enhanced

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 2.3-11:

•

Bugfix: Field name changed from job_id to jobId.

The following update was made for plug-in version 2.3-10:

•

Bugfix: Ansible Tower Plugin Icon is missing when registered via plugin proxy.

For more information, see Red Hat Ansible Tower Plug-in.

11-May-2022

Enhanced

Postman Plugin

The following update was made for plug-in version 1.0-5:

•

You can now pass the environment variables that are used during test execution. The specified values override the

values defined in the environment json file. For example, when a new SUT is provisioned during the phase run time,

you can pass the SUT address to the test.

The following update was made for plug-in version 1.0-4:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following update was made for plug-in version 1.0-3:

•

Bugfix: Tooltip for the successful sync/import.

For more information, see Plug-in for Postman.

SonarQube Plug-in

The following updates were made for plug-in version 2.0-8:

•

Java Binaries field is now an optional field. If the field is empty, "." is used by default.

•

Text change in the project key description.

The following update was made for plug-in version 2.0-7:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following update was made for plug-in version 2.0-6:

•

Bugfix: SonarQube Certificate Issue.

For more information, see SonarQube Plug-in.

199

Continuous Delivery Director 8.5

30-March-2022

Enhanced

Playwright Plug-in

The following update was made for plug-in version 2.0-12:

•

You can define the location of node_modules and yarn cache paths for the Playwright plugin in the containerized

properties.

Example:

cdd.plugins.containerized.playwright.container.volumes.artifacts.volumes=node_modules:/

home/cdd/node_modules,yarn/cache:/home/cdd/.yarn/cache

You can specify your desired local directory paths of the saved dependencies for node_modules and yarn/cache in

the above example.

When running the yarn install command, these volumes reduce the required time for the plugin steps (test suites

import and execution). The plugin does not download dependencies already stored in the mentioned volumes.

For more information, see Plug-in for Playwright.

Red Hat Ansible Plug-in

The following update was made for plug-in version 2.0-5:

•

At the endpoint, the "Private Key" field type has been changed to a password field that accepts Secret or strings. To

use a multi-line private key, store the private key in a "Secret" and use the secret in this field.

•

You can view the execution log during the task run-time. A link to the execution log is added to the task details (while

hovering the task) while the task is running and to the task status when the task is done.

For more information, see Red Hat Ansible Plug-in.

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 2.3-6:

•

Added a new task Run Workflow Template

•

Build Number (Deprecated) is removed; you can now specify the build number per application in the Builds For

Applications section of the task.

•

Shared File System Location is removed; the base url in the settings properties file is used for the Job Output URLs.

For more information, see Red Hat Ansible Tower Plug-in.

Helm Plug-in

The following updates were made for plug-in version 1.0-8:

•

Added support for Google Cloud Storage buckets as source control.

•

Bugfix: NULL Pointer Exception in Install Release by Helm Chart (Helm) Task.

For more information, see Helm Plug-in.

Containerized Plug-in Manager

The following update was made for version 2.9:

•

Added support to show the execution logs in the run-time even the containerized plug-in is connected using a proxy.

For more information, see Containerized Plug-in Manager.

200

Continuous Delivery Director 8.5

Jenkins Plug-in

The following updates were made for plug-in version 1.3.0-6:

•

Bugfix: Null Pointer Exception in Jenkins plugin of CDD (cdd-jenkins-plugin.war 1.3.0-4).

For more information, see Jenkins Plug-in.

07-March-2022

Enhanced

pytest Plugin

The following update was made for plug-in version 1.0-8:

•

Bugfix: Plugin fails on timeout while copying very large test reports.

For more information, see pytest Plug-in.

DX App Synthetic Monitor Plugin

The following update was made for plug-in version 1.2-13:

•

Bugfix: Wrong time in Set Time Window.

•

Bugfix: Change Monitor State for multi Folders fails.

For more information, see Plug-in for DX App Synthetic Monitor Plugin.

24-February-2022

New Features

Postman Plugin

The Postman plug-in is containerized and supports Adaptive Testing functionality. This plug-in provides you with a

Postman test automation framework for Git and SVN builds that is open-source and application-independent.

For more information, see Plug-in for Postman.

Enhanced

Red Hat Ansible Plug-in

The following update was made for plug-in version 2.0-2:

•

Bugfix: Plug-in terminates the playbook execution after 60 seconds. If the playbook runs for more than 60 seconds,

then the plug-in aborts the execution and fails.

For more information, see Red Hat Ansible Plug-in.

09-February-2022

New Features

Checkmarx Plugin

Checkmarx Plugin is now enhanced with a new Source code scanning task (CxSAST).

201

Continuous Delivery Director 8.5

For more information, see Plug-in for Checkmarx.

Enhancements

Sonatype Nexus Lifecycle (IQ Server) Plugin

New task that invokes nexus policy evaluation is included in the Sonatype Nexus Lifecycle (IQ Server) Plugin.

For more information, see Plug-in for Sonatype Nexus Lifecycle (IQ Server).

DX App Synthetic Monitor Plugin

New capabilities are added in the DX App Synthetic Monitor Plugin:

•

Rule check for multiple monitors or by tags

•

Activate/Deactivate multiple monitors or by tags

•

Create/remove immediate maintenance window

For more information, see Plug-in for DX App Synthetic Monitor Plugin.

Cucumber JVM Plugin

Enhanced the plugin to view the execution report even if all the tests are skipped.

For more information, see Plug-in for Cucumber JVM.

Playwright Plugin

Enhanced to view the execution report even if all the tests are skipped.

For more information, see Plug-in for Playwright.

13-December-2021

Enhanced

Runscope Plug-in

The following update was made for plug-in version 1.1-2:

•

Enhancement:- The plugin now support the use of system variable.

29-November-2021

Enhanced

Cucumber JVM Plug-in

The following update was made for plug-in version 1.4.1-11:

•

Bugfix: Import fails to retrieve all features defined in the Source Control.

For more information, see Cucumber JVM Plug-in.

202

Continuous Delivery Director 8.5

17-November-2021

New

Micro Focus LoadRunner Enterprise Plug-in

You can now automate your application performance testing with LoadRunner Enterprise. This plug-in lets you run

application performance tests in Continuous Delivery Director without using the LoadRunner Enterprise user interface.

You can import and execute LoadRunner Enterprise test suites within release pipelines. The LoadRunner Enterprise plug-

in supports Adaptive Testing functionality.

For more information, see Micro Focus LoadRunner Enterprise Plug-in.

Sonatype Nexus Lifecycle Plug-in

Evaluate the risks of your applications against Nexus Lifecycle (IQ) policies.

Nexus Lifecycle is a solution that lets you identify open source risk in your applications, allowing you to secure your entire

software supply chain. With Nexus Lifecycle, you can create custom security, license, and architectural policies based on

application type or organization and contextually enforce those policies across every stage of the SDLC.

The Nexus Lifecycle plug-in is containerized and supports Adaptive Testing functionality. This plug-in provides you with a

Nexus Lifecycle test automation framework for Git builds.

For more information, see Sonatype Nexus Lifecycle Plug-in.

Enhanced

Docker Plug-in

The following update was made for plug-in version 1.3-3:

•

Added support to define a schema for the "Check Readiness" option.

For more information, see Docker Plug-in.

DX App Synthetic Monitor Plug-in

The following update was made for plug-in version 1.2-8:

•

Bugfix: Importing a Release DSL using the activate/deactivate task fails due to invalid character.

For more information, see DX App Synthetic Monitor Plug-in.

Atlassian Jira Plug-in

The following update was made for plug-in version 2.4-14:

•

You can configure output parameters in the plug-in settings.properties file, store the information retrieved in tokens,

and reuse those details in other release tasks.

•

Support was added for the Bearer Authentication using Jira Personal Access Token.

•

Bugfix: After the authentication changes Jira plugin is not backward compatible.

The following update was made for plug-in version 2.4-13:

•

You can now use personal access tokens to authenticate to Jira in the endpoint configuration.

The following update was made for plug-in version 2.4-12:

•

Security enhancements.

203

Continuous Delivery Director 8.5

The following update was made for plug-in version 2.4-10:

•

The plug-in was modified to support the retrieval of detailed Jira issue data.

For more information, see Atlassian Jira Plug-in.

Plug-in for Azure DevOps Server

You can now download this extension from the Visual Studio Marketplace.

For more information, see Plug-in for Azure DevOps Server.

Plug-in for Grafana

Deployment and task execution metrics have been added. You can use these new metrics to track deployment cadence,

deployment success and failure, and plug-in usage of applications in specific environments.

For more information, see Plug-in for Grafana.

Microsoft Teams Plug-in

The following change was added for plug-in version 1.2-4:

•

Bugfix: Inconsistent name for the task "New Conversation."

For more information, see Microsoft Teams.

Rally Plug-in

The following update was made for plug-in version 2.18-5

•

The Release Quality Report now shows test information per work item as the data appears in Rally, such as the

number of flaky tests. To support this enhancement, the work item IDs of tests are now stored with the tests.

The following update was made for plug-in version 2.18-4

•

Security enhancement.

The following update was made for plug-in version 2.18-3

•

Bugfix: Test case results are not displayed as expected.

For more information, see Rally

Plug-in.

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 2.3-6:

•

Minor modifications were made to the Credentials input parameter in the Run Job Template task.

•

You can now use profiles defined in the plug-in's settings.properties file to add custom output parameters.

For more information, see Red Hat Ansible Tower Plug-in.

SonarQube Plug-in

The following update was made for plug-in version 2.0-2:

•

Default values for the File Suffixes Exclusions input parameter in the Run Code Analysis task have been added.

The following update was made for plug-in version 2.0-1:

•

The Coverage Exclusions input parameter in the Run Code Analysis task has been updated.

204

Continuous Delivery Director 8.5

The following update was made for plug-in version 2.0:

•

A Run Code Analysis task has been added, enabling you to run an analysis of your Java code from your release

pipeline.

The following update was made for plug-in version 1.2:

•

The endpoint now allows you to configure access to a Git project repository.

For more information, see SonarQube Plug-in.

27-October-2021

Enhanced

Cucumber JVM Plug-in

The following update was made for plug-in version 1.4.1-9:

•

Bugfix: Import fails when the feature name contains SPACE characters.

For more information, see Cucumber JVM Plug-in.

29-September-2021

New

Burp Suite Plug-in

A new plug-in lets you scan your web applications for vulnerabilities from your release pipeline. Burp Suite is a popular

and scalable set of tools used for penetration testing of web applications. This plug-in integrates with Burp Suite

Enterprise and lets you create scans.

For more information, see Burp Suite Plug-in.

pytest Plug-in

You can now add the popular pytest software test framework to your release pipeline.

pytest is a robust Python testing tool that is used by development teams and QA teams. The new pytest plug-in is

containerized and supports Adaptive Testing functionality. This plug-in provides you with a pytest test automation

framework for Git and SVN builds that is open-source and application-independent.

For more information, see pytest Plug-in.

Salesforce Plug-in

A new plug-in lets you retrieve, test, and deploy Salesforce apps from your release pipeline. This containerized plug-in lets

you use SFDX (Salesforce Developer Experience) together with Continuous Delivery Director to speed up the standard

development workflow.

For more information, see Salesforce Plug-in.

SOAP UI Plug-in

A new plug-in lets you import and execute API tests in your release pipeline with the most widely-used automated testing

tool for SOAP and REST APIs.

For more information, see SOAP UI Plug-in.

205

Continuous Delivery Director 8.5

Enhanced

AWS CodeDeploy Plug-in

The following updates were made for plug-in version 2.0-2:

•

Bugfix: list-deployment-instances is deprecated and does not support EC2 deployments. Use list-deployment-

targets instead.

For more information, see AWS CodeDeploy Plug-in.

Microsoft Teams Plug-in

The following change was added for plug-in version 1.2-3:

•

A new task, Start New Chat, lets you override the webhook URL defined in the endpoint by overriding the webhook

URL suffix only. This enhancement avoids the need to create a new endpoint when updating the webhook URL. This

task was developed following changes in the webhook URL format introduced by Microsoft in January 2021.

For more information, see Microsoft Teams.

REST Plug-In

The following updates were made for plug-in version 2.6-3:

•

The output parameter of REST tasks has been tokenized and now provides success and fail indicators. The fail value

can be used in on-failure phases.

For more information, see REST Plug-in.

25-August-2021

Enhanced

Atlassian Jira Plug-in

The following update was made for plug-in version 2.4-9:

•

Bugfix: Invalid external work item IDs set on test suites affected work item coverage reporting.

For more information, see Atlassian Jira Plug-in.

11-August-2021

New

Plug-in for Grafana

A new plug-in lets you build stunning data visualizations in Grafana dashboards based on test and release execution

metrics.

For more information, see Plug-in for Grafana.

Build Notifications for Business Application Versions

You can automate release creation per business application version through build notifications.

For more information, see Create a Release from Business Application-Related DSL.

206

Continuous Delivery Director 8.5

Enhanced

Atlassian Jira Plug-in

The following update was made for plug-in version 2.4-8:

•

The work item IDs of tests are now stored with the tests.

For more information, see Atlassian Jira Plug-in.

28-July-2021

New

Enhanced

Atlassian Jira Plug-in

The following updates were made for plug-in version 2.4-7:

•

The Test Execution Key parameter in the Get Test Assets task was moved to the Execution Parameters section.

The following updates were made for plug-in version 2.4-6:

•

Support was added for integration testing.

The following updates were made for plug-in version 2.4-5:

•

The Test Plan Key and Test Execution Key parameters in the Get Test Assets task now support dynamic values

import from Xray.

The following updates were made for plug-in version 2.4-4:

•

A new Trust Any SSL Certificate endpoint parameter lets you allow untrusted and unsigned SSL/TLS certificates.

The following updates were made for plug-in version 2.4-3:

•

A Test Execution Key parameter was added to the Import Tests task.

The following updates were made for plug-in version 2.4-2:

•

Support was added for the Xray Test Management for the Jira application. This enhancement lets you import test

issues as test suites into Continuous Delivery Director.

•

Log rotation was added. A new log is opened daily (regardless of file size) and the system stores up to 10 logs,

providing 10 days log history.

For more information, see Atlassian Jira Plug-in.

Docker Plug-in

The following updates were made for plug-in version 1.3-1:

•

In the Run Container task, only one port is exposed. The expected behavior is that all ports listed in the Ports to

Expose input parameter are exposed.

For more information, see Docker Plug-in.

207

Continuous Delivery Director 8.5

30-June-2021

New

Monitor Running Tests

You can now access a test execution log from a release page to see which tests are executed at any given time. The

execution log is updated in real-time so if problems occur in a test run, you can examine the log to determine whether to

stop or continue with the test execution. This feature is especially useful when you run a large set of tests on complex

business applications. For more information, see Monitor Running Tests

IMPORTANT

This functionality is supported by the CucumberJVM plug-in version 1.4.1-6 and higher and is not backward-

compatible. For more information, see Cucumber JVM Plug-in.

Karate Plug-in

You can now automate your API testing with the Karate open-source framework. This plug-in uses Maven projects to

import and execute Karate test suites within release pipelines. The Karate plug-in is containerized and supports Adaptive

Testing functionality. This plug-in provides you with a Karate test automation framework for Java-based Git and SVN

builds that is open-source and application-independent.

For more information, see Karate Plug-in.

Terraform Plug-in

You can now manage your Terraform runs from your release pipeline. Terraform is an infrastructure-as-code software

tool. Infrastructure as code is the process of managing and provisioning computer data centers through machine-readable

definition files.

In Terraform, a run is a process to make real infrastructure match the desired state (as specified by the contents of the

config version and variables at a specific moment in time). This plug-in integrates with Terraform Cloud and supports the

following API-driven run tasks:

•

Create a Run

•

Apply a Run

For more information, see Terraform Plug-in.

Enhanced

Apache Tomcat Plug-in

The following updates were made for plug-in version 1.5-1:

•

Bugfix: When a plug-in task failed to retrieve a Maven artifact, an unclear NullPointerException error message

displayed on the CDD user interface. This message was replaced with a clearer message that includes the expected

path to the missing Maven artifact.

For more information, see Apache Tomcat Plug-in.

AWS CodeDeploy Plug-in

The following updates were made for plug-in version 2.0-1:

•

Bugfix: A deployment task completed successfully, but an error message, NullPointerException: element

cannot be mapped to a null key, appeared on the release page.

208

Continuous Delivery Director 8.5

For more information, see AWS CodeDeploy Plug-in.

Azure DevOps Server Plug-in

The following updates were made for plug-in version 1.1-3:

•

Support was added for Azure DevOps Server 2020.0.1.

For more information, see Azure DevOps Server Plug-in.

Cucumber JVM Plug-in

The following update was made for plug-in version 1.4.1-6:

•

You can now view a test execution log that is updated in real-time to see which Cucumber tests are executed at any

given time. The execution log is updated in real-time so if problems occur in a test run, you can examine the log to

determine whether to stop or continue with the test execution.

NOTE

This feature is only available for plug-in version 1.4.1-6 and higher and is not backward-compatible.

For more information, see Cucumber JVM Plug-in.

Liquibase Plug-in

The following updates were made for plug-in version 1.0-1:

•

The Database endpoint parameter now supports relative classpaths to the lib folder.

For more information, see Liquibase Plug-in.

Rally Plug-in

The following updates were made for plug-in version 2.18-2

•

You can now import test cases into the Adaptive Testing Catalog.

•

A Milestone Name filter was added to the Import Work Items task.

For more information, see Rally

Plug-in.

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 2.3-5:

•

Bugfixes:

–

The log filename did not include the hostname.

–

The log filename used underscores and not hyphens.

For more information, see Red Hat Ansible Tower Plug-in.

Plug-in for Azure DevOps Server

The following update was made for plug-in version 1.0.2

•

Bugfix - A code vulnerability was detected in the third-party underscore:1.8.3 3rd party JS library.

For more information, see Plug-in for Azure DevOps Server.

Plug-in for Jenkins

The following update was made for plug-in version 3.4

209

Continuous Delivery Director 8.5

•

A new option has been added to Freestyle projects, Use Git Namespace as the Application Source.

If selected, when applications with the same name are imported into Continuous Delivery Director

from different application sources, Continuous Delivery Director can match the build notification

to the correct application. A similar property has been added to the Jenkinsfile Groovy script,

useSourceCodeRepositoryNamespaceAsApplicationSourceName: true/false . When this property is

set to true, the repository namespace is used as the application version (the value of applicationSourceName is

ignored.)

•

Lines are no longer added to the build history with release URLs when Continuous Delivery Director detects the

presence of one or more releases in the build notification. This function became redundant and was removed because

the build details contain links to the release(s).

For more information, see Plug-in for Jenkins.

26-May-2021

New

Liquibase Plug-in

You can now integrate Liquibase with your release pipeline to achieve full-stack continuous integration and continuous

delivery for your databases. This new plug-in lets you align your application and database deployments.

For more information, see Liquibase Plug-in.

Enhanced

BlazeMeter Plug-in

The following update was made for plug-in version 3.7-3:

•

Bugfix: Error messages in Continuous Delivery Director do not include the error code, causing delay in tracing the root

cause of errors.

For more information, see BlazeMeter Plug-in.

Cucumber for Java Plug-in

The following update was made for plug-in version 1.4.1-5:

•

Bugfix: Links to the error and debug logs are not generated when tests complete.

For more information, see Cucumber for Java Plug-in.

DX App Synthetic Monitor (ASM) Plug-in

The following updates were made for plug-in version 1.2-2

•

Bugfix: The plug-in does not handle empty dynamic values as expected

•

Bugfix: Dynamic fields are not working as expected.

For more information, see DX App Synthetic Monitor Plug-in.

GitLab Plug-in

The following updates were made for plug-in version 2.0-1:

210

Continuous Delivery Director 8.5

•

Bugfix: The Namespace Kind parameter in the Import Applications task was changed to mandatory and user was

set as the default.

•

Bugfix: The List Projects by Custom Attributes parameter in the Import Applications task was removed.

•

Bugfix: In the Namespace Kind Group field, the spaces before and after slash characters are ignored, causing sync

errors. To resolve this issue, the help text was updated.

•

Bugfix: In the Application Name parameter in the Import Applications task, the option to add a project path was

removed.

For more information, see GitLab Plug-in.

Red Hat Ansible Tower Plug-in

The following updates were made for plug-in version 2.3-4:

•

Log handling has been enhanced to prevent relevant logging information from being deleted:

–

A new log record is created daily

–

Logs are retained for 14 days

–

The size limit on log files has been removed

•

A Credentials input parameter was added to the Run Job Template task.

For more information, see Red Hat Ansible Tower Plug-in.

12-May-2021

Enhanced

Atlassian Jira Plug-in

The following updates were made for plug-in version 2.4-1:

•

Bugfix: No value was returned if no work items were found matching a commit.

For more information, see Atlassian Jira Plug-in.

BlazeMeter Plug-in

The following update was made for plug-in version 3.7-2:

•

End time and polling time were enhanced.

For more information, see BlazeMeter Plug-in.

Containerized Plug-in Manager

The following update was made for version 2.5:

•

When settings are changed and saved, settings.properties is automatically updated during runtime without the

need to restart the service.

The following update was made for version 2.4:

•

The Tenant ID was updated.

For more information, see Containerized Plug-in Manager.

GitLab Plug-in

The following update was made for plug-in version 2.0:

211

Continuous Delivery Director 8.5

•

You can now filter the applications you import from GitLab instances. To support this capability, the following input

parameters were add to the Add Application Source dialog for GitLab:

–

Namespace Kind

–

Project Name

–

Starred Projects Only

–

Membership

–

Ownership

–

Archived

–

Visibility Level

–

List Projects by Custom Attributes

For more information, see GitLab Plug-in.

Maven Testing Plug-in

The following update was made for plug-in version 1.5-2:

•

The Maven execution log is now created at the beginning of test execution (and not at the end).

The following update was made for plug-in version 1.5-1:

•

Three new import parameters. Settings File Path, Settings Security File Path, and System Properties, were added

to the Get Test Assets task. These additional parameters improve the support for TestNG Selenium testing.

For more information, see Maven Testing Plug-in.

Microsoft Teams Plug-in

The following change was added for plug-in version 1.2-2:

•

A new Group ID parameter in the Post Message task lets you override the group ID defined in the endpoint webhook

URL.

The following change was added for plug-in version 1.2-1:

•

Tooltip updated.

For more information, see Microsoft Teams.

Plug-in for JetBrains TeamCity (Deprecated)

The following update was made for plug-in version 2.3

•

You can now use build notifications to update release token values in Continuous Delivery Director releases. To

support this change, a new parameter, Update Release Token Values, was added to the Send Build Notification

action.

The following update was made for plug-in version 2.2

•

Two new parameters, Use Source Code Repository Name as Application Name and Use Source Code Branch

Name as Application Version, were added to the Send Build Notification action.

The following update was made for plug-in version 2.1

•

Application version build URLs were added to the header of build notifications. This update enables users to access

specific builds in TeamCity from a link in a Continuous Delivery Directorrelease.

Slack Plug-in

The following update was made for plug-in version 2.0:

212

Continuous Delivery Director 8.5

•

Support was added for slack-api-client 1.4.2.

WARNING

This plug-in update is not backward compatible.

For more information, see Slack Plug-in.

31-March-2021

New

Plug-in for Azure DevOps Server

A new integration lets you send Azure build notifications to Continuous Delivery Director and to trigger release creation

and testing automatically.

NOTE

This plug-in supersedes a previous integration with TFS.

For more information, see Plug-in for Azure DevOps Server.

Plug-in for JetBrains TeamCity (Deprecated)

A new integration lets you send TeamCity build notifications to Continuous Delivery Director and to trigger release creation

automatically.

NOTE

This plug-in supersedes a previous integration with TeamCity.

Enhanced

Automic Continuous Delivery Automation (CDA) Plug-in

The following update was made for plug-in version 4.1-4:

•

Bugfix: Internal defect.

The following update was made for plug-in version 4.1-3:

•

Bugfix: An ungrammatical error message was generated when the following scenario occurred. A CDA task to start an

Application workflow ran. However, two mutually exclusive options were both configured: provide a package and create

a package.

The following updates were made for plug-in version 4.1-2:

•

Bugfix: The link in the CDA deployments report under the CDA deployment column was missing. Additionally, the

domain name was missing in the link.

•

Bugfix: Setting dynamic values in a CDA task generated a 500 internal server error, indicating that the HTTP request

could not be fulfilled because an unexpected condition was encountered.

The following updates were made for plug-in version 4.1-1:

•

Bugfix: The set build action was performed on the package name instead of on the build number.

For more information, see Automic

Continuous Delivery Automation Plug-in.

AWS CodeDeploy Plug-in

The following updates were made for plug-in version 2.0

213

Continuous Delivery Director 8.5

•

Support was added for Amazon S3 buckets as source control repositories in endpoints.

WARNING

This plug-in update is not backward compatible. To avoid potential issues, unregister the plug-in, overwrite

the war file, and re-register.

•

Default values were added to the Version ID endpoint parameter.

For more information, see AWS CodeDeploy Plug-in.

BlazeMeter Plug-in

The following update was made for plug-in version 3.7-1:

•

Bugfix: When the plug-in was deployed onto multiple hosts, the log files were overwritten because all instances wrote

to the same log file.

For more information, see BlazeMeter Plug-in.

Containerized Plug-in Manager

The following updates were made for version 2.3:

•

Bugfix - Cucumber JVM test suite import failed on SaaS.

•

Bugfix - the containerized plug-in manager does not map volumes in connectivity tests.

The following update was made for version 2.2

•

The Fabric8 software component used by the containerized plug-in manager has been upgraded to version 5.1.1.

For more information, see Containerized Plug-ins.

Cucumber for Java Plug-in

The following update was made for plug-in version 1.4.1-4:

•

You can now specify system properties when importing test suites. To support this change, a System Properties input

parameter was added to the Get Test Assets task.

The following updates were made for plug-in version 1.4.1-3:

•

You can now specify the location of the settings-security.xml file. This improvement is essential in environments

where users do not have control over the home directory (such as a continuous integration farm, where each

project may have its own settings.xml configuration except for settings-security.xml). To support this change, a

Settings Security File Path input parameter was added to the Get Test Assets task.

•

When a Get Test Assets task fails, the error message now contains a URL linking to the import log file. This

enhancement helps users trace the root cause of a task failure. Previously, the error message did not contain full

information for troubleshooting purposes.

For more information, see Cucumber for Java Plug-in.

Kubernetes Plug-in

The following update was made for 2.3.3-3:

•

The Fabric8 software component used by this plug-in has been upgraded to version 5.1.1.

The following update was made for 2.3.3-2:

•

Bugfix: The log bridge from Catalina to cdd-server log files now records fabric8 HTTP traffic only. Previously, idle

Kubernetes/OpenShift plug-in activities were recorded, resulting in very large log files.

The following update was made for 2.3.3-1:

214

Continuous Delivery Director 8.5

•

The Kubernetes plugin now logs complete details of all HTTP requests and responses, including HTTP method, URL,

headers, and body).

For more information, see Kubernetes Plug-in.

Micro Focus ALM Plug-in

The following update was made for plug-in version 2.4-2:

•

Fixed: On the Folder field in the Get Test Assets task, the tooltip incorrectly states that tokens can be used.

For more information, see Micro Focus ALM Plug-in.

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 2.3-3:

•

You can now connect to an Ansible Tower endpoint through a proxy server. To support this change, a Use Proxy

checkbox was added to the endpoint configuration parameters.

For more information, see Red Hat Ansible Tower Plug-in.

Red Hat OpenShift Plug-in

The following updates were made for 2.2-2

•

The Fabric8 software component used by this plug-in has been upgraded to version 5.1.1.

The following updates were made for 2.2-1

•

Bugfix (DE490722): The log bridge from Catalina to cdd-server log files now records fabric8 HTTP traffic only.

Previously, idle Kubernetes and OS plug-in activities were recorded, resulting in very large log files.

For more information, see Red Hat OpenShift Plug-in.

ServiceNow

Plug-in

The following update was made for plug-in version 2.3-2:

•

The success message generated after a Create Change Request task executes now contains a URL linking to the

newly-created change request in ServiceNow.

For more information, see ServiceNow Plug-in.

Slack Plug-in

The following update was made for plug-in version 2.0:

•

Support was added for slack-api-client 1.4.2.

WARNING

This plug-in update is not backward compatible.

For more information, see Slack Plug-in.

215

Continuous Delivery Director 8.5

24-February-2021

Enhanced

GitHub Plug-in

The following update was made for plug-in version 1.0.3-1:

•

You can now authenticate to GitHub with a GitHub API key. To support this change, the Password endpoint parameter

has been renamed Password/API Key.

For more information, see GitHub Plug-in.

GitLab Plug-in

The following updates were made for plug-in version 1.7-2:

•

You can now import environments from GitLab repositories to use as Continuous Delivery Director environments.

For more information, see GitLab Plug-in.

Plug-in for Jenkins

The following updates were made for plug-in version 3.3

•

In the post-build notification action, a new Additional Information section was added. This section contains the

Update Release Token Values, Source Control Connection Parameters, and Test Data sections.

•

In the post-build notification action, the Update Token Values in CDDirector parameter was replaced with the Update

Release Token Values section. This new section lets you add multiple tokens in the form of "name":"value" pairs.

Previously, you could only add one token.

•

A new Enable Notifications for Unstable Builds option was added. In the post-build notification action in Freestyle

projects, you can select this option to prevent the plug-in from sending build notification to Continuous Delivery Director

if the build status is unstable.

For Jenkins Pipeline projects, the boolean sendNotificationOnUnstableBuild parameter was added.

•

In the post-build notification action, a new Source Control Connection Parameters section lets you add multiple

source control connection parameters in the form of "name":"value" pairs.

•

In the post-build notification action in Freestyle projects, a new Specify File Source option lets you create a release

from DSL files in your source control repositories. You specify the file source in the form of a "name":"value"

pair. After a Jenkins build completes, the release DSL is sent to Continuous Delivery Director. A new release is

automatically created according to the release defined in the file.

A new Override File Source Parameters section lets you override the file source parameters that are defined in

Continuous Delivery Director. You specify the required file source parameters in the form of a "name":"value" pair.

NOTE

This capability already existed in Jenkins Pipeline Groovy syntax.

•

In the post-build notification action in Freestyle projects, a new Create from Business Application File Source

option lets you create a release from a business application-related DSL file. You specify the file source using DSL

Parameters in the form of "name":"value" pairs. After a Jenkins build completes, the release DSL is sent to

Continuous Delivery Director. A new release is automatically created according to the business application defined in

the DSL file.

For more information, see Send Build Notifications from a Jenkins Freestyle Project.

216

Continuous Delivery Director 8.5

27-January-2021

Enhanced

Atlassian Bitbucket Plug-in

The following updates were made for plug-in version 2.3-1:

•

Support was added for Bitbucket webhook 7.6. This change allows customers to use BitBucket Data Center 7.6.

For more information, see Atlassian Bitbucket Plug-in.

Containerized Plug-in Manager

The following update was made for version 2.2:

•

Bugfix: The containerized plug-in log files were overwritten in a multi-node active-active high-availability cluster setup.

For more information, see Containerized Plug-ins.

Cucumber for Java Plug-in

The following update was made for plug-in version 1.4.1-2:

•

Bugfix: When test execution failed for a Cluecumber custom report, the link to the associated report was not

generated.

The following update was made for plug-in version 1.4.1-1:

•

Support was added for custom SSL TrustStore files. These files contain only those certificates trusted by the client.

These certificates are CA root certificates, that is, self-signed certificates.

For more information, see Cucumber for Java Plug-in.

Gradle Testing Plug-in

The following updates were made for plug-in version 1.11-1:

•

To improve usability, the following parameters were changed to textarea fields:

–

Source Set

–

JVM Parameters

–

Extra Execution Parameters

For more information, see Gradle Testing Plug-in.

Helm Plug-in

The following updates were made for plug-in version 1.0-1:

•

The locations for stable and incubator charts have changed. The new location for the stable repository is https://

charts.helm.sh/stable and the new location for the incubator repository is https://charts.helm.sh/

incubator. If you use charts in either of these old locations below you MUST update the repositories you used before

November 13, 2020. The new locations are hosted using GitHub pages.

Name Old Location New Location

stable https://kubernetes-

charts.storage.googleapis.com

https://charts.helm.sh/

stable

incubator https://kubernetes-charts-

incubator.storage.googleapis.com

https://charts.helm.sh/

incubator

217

Continuous Delivery Director 8.5

NOTE

Please upgrade the Helm plugin to the latest versions.

•

Bugfix: The sns prefix (for Amazon Simple Notification Service) was missing from the default value for the AWS S3

Service API URL endpoint parameter.

For more information, see Helm Plug-in.

Jenkins Plug-in

The following updates were made for plug-in version 1.3.0-2:

•

Bugfix: Upgrading from plug-in version 1.3.0 to 1.3.0-1 in release DSLs caused Missing details errors in Run

Build tasks.

For more information, see Jenkins Plug-in.

Plug-in for Jenkins

The following update was made for plug-in version 3.2.14

•

Bugfix: A Groovy script missing the overrideCDDConfig section did not use the settings in Jenkins from Manage

Jenkins > Configure System > CDDirector Plugin.

The following update was made for plug-in version 3.2.13

•

You can now use a single global Groovy file (stored in Jenkins global libraries) to support multiple per-project

Continuous Delivery Director API keys.

For more information, see Plug-in for Jenkins.

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 2.3-2:

•

Bugfix: Connection timeout issues to on-premise hosted plug-ins.

For more information, see Red Hat Ansible Tower Plug-in.

Robot Framework Plug-in

The following update was made for plug-in version 1.7-2:

•

To improve usability, the Extra Execution Parameters field in the Get Test Assets (Test Source) task was changed

to a textarea field.

The following update was made for plug-in version 1.7-1:

•

Fixed: Tests that were skipped and therefore were not associated with reports were reported as failures

For more information, see Robot Framework Plug-in.

218

Continuous Delivery Director 8.5

5-January-2021

New

Playwright Plug-in

A new plug-in lets you import and execute Playwright test suites as part of your release pipeline. This plug-in integrates

with Playwright, a node.js tool to automate end-to-end web testing. The Playwright plug-in is containerized and supports

Adaptive Testing functionality.

For more information, see Playwright Plug-in.

Enhanced

Automic Continuous Delivery Automation (CDA) Plug-in

The following updates were made for plug-in version 4.1:

•

Build numbers are now available as dynamic properties. This change allows you to dynamically update the

last_successful_change property dynamically in CDA with a build number passed from the task in Continuous

Delivery Director.

For more information, see Automic

Continuous Delivery Automation Plug-in.

DX App Synthetic Monitor (ASM) Plug-in

The following updates were made for plug-in version 1.2

•

A Run Rule Check task was added to enable users to check that the target machine is up and running and available

for use in the release pipeline.

The following updates were made for plug-in version 1.1

•

To improve usability, the Activate or Deactivate parameter in the Activate and Deactivate task was changed from a

checkbox to a dropdown with Activate and Deactivate options.

For more information, see DX App Synthetic Monitor Plug-in.

GitLab Plug-in

The following updates were made for plug-in version 1.7-1:

•

To avoid errors, the Get Commit Messages task now uses the first commit if previous builds have failed.

For more information, see GitLab Plug-in.

Jenkins Plug-in

The following updates were made for plug-in version 1.3.0-1:

•

You can now control how this plug-in handles an unstable Jenkins build. To support this capability, a new Task

Status for Unstable Build field was added to the Run Build task. This field allows you to define whether the task is

considered as Done or Failed.

For more information, see Jenkins Plug-in.

219

Continuous Delivery Director 8.5

25-November-2020

Enhanced

Azure DevOps Server Plug-in (formerly Microsoft Team Foundation Server plug-in)

The following updates were made for plug-in version 1.1.1:

•

This plug-in was renamed to the Azure DevOps Server plug-in to align with the vendor (Microsoft) name change

decision. Formerly, this plug-in was named the Microsoft Team Foundation Server plug-in.

For more information, see Azure DevOps Server Plug-in.

Maven Testing Plug-in

The following updates were made for plug-in version 1.5:

•

The functionality of the Maven Project parameter in the Get Test Assets (Import Test Suites) task has changed.

Previously, you specified the name of a project from which to import test suites. Now you specify one or more relative

paths to subprojects separated by commas from which to import test suites.

For more information, see Maven Testing Plug-in.

Microsoft Teams Plug-in

The following changes were added for plug-in version 1.2:

•

You can now send messages to different teams and channels using the same webhook which saves you unnecessary

effort. To support this change, a new parameter, Webhook Suffix has been added to the Post Message task. This

parameter overrides the endpoint webhook suffix.

•

You can now specify additional facts in the Post Message task in addition to the facts you specify in the Fact 1-3

Name and Fact Value 1-3 parameters. Previously, you could only define up to three facts. To support this change, a

new Additional Facts parameter was added.

For more information, see Microsoft Teams Plug-in.

Plug-in for Jenkins

The following update was made for plug-in version 3.2.12:

•

You can now create releases by specifying a file source in Groovy pipeline syntax in a Jenkinsfile in your

source control. To support this change, you can now specify the following parameters in Groovy for the

sendNotificationToCDD step:

–

File source name

–

File source parameters

–

DSL file name and path

–

DSL parameters

For more information, see Plug-in for Jenkins.

Red Hat Ansible Core Plug-in

The following update was made for plug-in version 2.0:

•

This plug-in now supports the capability to add multiple applications to tasks, and to assign different build numbers to

each application. To support this capability, the Build field in the Run Playbook task is now optional; previously this

field was mandatory.

220

Continuous Delivery Director 8.5

For more information, see Red Hat Ansible Core Plug-in.

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 2.3.1:

•

Bugfix: Entering a build number in the Run Job Template task is now optional, because builds are not relevant in user

scenarios such as hardware provisioning and network configuration.

For more information, see Red Hat Ansible Tower Plug-in.

Red Hat OpenShift Plug-in

The following updates were made for plug-in version 2.2

•

Support was added for the following source control systems: GitLab, AWS S3, Web Services.

•

Basic authentication using a username and password was added.

•

A Branch parameter was added to the GitHub endpoint parameters.

•

A Trust Any SSL Certificate option was added to the endpoint parameters.

•

A YAML Settings field was added to the Create Deployment task.

The following updates were made for plug-in version 2.1

•

Multiple bug fixes.

For more information, see Red Hat OpenShift Plug-in.

4-November-2020

New

Automic Continuous Delivery Automation (CDA) Plug-in

We have developed a new CDA plug-in, replacing the previous CDA plug-in, with the following changes:

•

Import Application from CDA to Continuous Delivery Director

The previous plug-in imported a CDA application as a Continuous Delivery Director application. The new plug-in

imports a CDA component as a Continuous Delivery Director application.

NOTE

A Continuous Delivery Director application is equivalent to a CDA component and a Continuous Delivery

Director business application is equivalent to a CDA application.

•

Create Package

In the CD pipeline, each component requires a separate build job, and the package must be created from the artifacts

created by all the build jobs.

The previous plug-in used Jenkins to create the package, meaning that if you wanted to create a CD pipeline, you had

to set up a separate package for each component.

The new plug-in can automatically create packages. If a build of any of the components is ready, the plug-in

automatically creates a package and runs the deployment.

•

Plug-in Downloads

The old plug-in was only available from the Automic Marketplace. Users can now download the new plug-in from the

Continuous Delivery Director home page.

For more information, see Automic

Continuous Delivery Automation Plug-in.

221

Continuous Delivery Director 8.5

Enhanced

Containerized Plug-in Manager

The following updates were made for version 2.2:

•

The containerized plug-in manager lets you run Continuous Delivery Director docker-based plugins

on Kubernetes (and not just on Docker engine).

For more information, see Run Containerized Plug-ins using Kubernetes.

•

You can configure settings.properties to support multiple container management platforms.

For more information, see Set Up Multiple Containerized Plug-in Managers.

Cucumber for Java Plug-in

The following updates were made for plug-in version 1.4.1:

•

A new execution parameter, Custom Reports, has been added to the Get Test Assets task, with the following

options, Default, Maven Cucumber Reporting, and Cluecumber. This field lets you store and present custom

cucumber reports based on the project pom.xml settings.

The following updates were made for plug-in version 1.3.2:

•

Support was added for importing Cucumber JVM repositories with multiple projects. To support this enhancement, two

new import parameters have been added to the Get Test Assets task: Settings File Path and Update Snapshots.

The following updates were made for plug-in version 1.3.1:

•

Bugfix: A missing Maven POM file error was invoked when trying to import from a subfolder.

For more information, see Cucumber for Java Plug-in.

GitLab Plug-in

The following updates were made for plug-in version 1.7:

•

You can now import files from GitLab repositories as applications.

The following updates were made for plug-in version 1.6:

•

You can now retrieve linked issues (work items) from GitLab.

For more information, see GitLab Plug-in.

Gradle Testing Plug-in

The following updates were made for plug-in version 1.9:

•

The New or Updated Test Suites heuristic is now supported for SVN test suites. This metric is a weighting factor

when the Test Advisor intelligently selects a subset of test suites to run in subsequent test cycles.

•

Fixed - DE473431. Test suites configured to be skipped were not calculated in the test execution result.

For more information, see Gradle Testing Plug-in.

Maven Testing Plug-in

The following updates were made for plug-in version 1.5:

•

The New or Updated Test Suites heuristic is now supported for SVN test suites. This metric is a weighting factor

when the Test Advisor intelligently selects a subset of test suites to run in subsequent test cycles.

For more information, see Maven Testing Plug-in.

222

Continuous Delivery Director 8.5

Rally Plug-in

The following updates were made for plug-in version 2.18

•

Bugfix: Work items in Rally with Released status are not treated in Continuous Delivery Director as completed work

items. A green checkmark indicating Complete status is not assigned to any associated work items with the Rally

statuses Accepted and Released.

The following updates were made for plug-in version 2.17

•

Bugfix: Multiple duplicate copies of "actual" work items were generated when applications were shared with multiple

releases.

The following updates were made for plug-in version 2.16

•

You can now import and execute manual test suites

The following updates were made for plug-in versions 2.12-2.15

•

Assorted bug fixes

For more information, see Rally Plug-in.

Robot Framework Plug-in

The following updates were made for plug-in version 1.7:

•

The New or Updated Test Suites heuristic is now supported for SVN test suites. This metric is a weighting factor

when the Test Advisor intelligently selects a subset of test suites to run in subsequent test cycles.

For more information, see Robot Framework Plug-in.

30-September-2020

Create Releases and Run Adaptive Tests from Jenkins Build Notifications

You can now use the plug-in for Jenkins to automatically create releases, and trigger adaptive testing in Continuous

Delivery Director, based on build notifications. These options are available for both freestyle and pipeline projects.

For more information, see Plug-in for Jenkins.

Helm Plug-in

Streamline the installation and management of Kubernetes/OpenShift applications and resources with our new Helm plug-

in.

For more information, see Helm Plug-in.

DX App Synthetic Monitor (ASM) Plug-in

Control your site and application performance monitoring from your release pipeline with our new DX App Synthetic

Monitor plug-in.

For more information, see DX App Synthetic Monitor Plug-in.

Enhanced

Kubernetes Plug-in

The following updates were made for 2.3.1:

223

Continuous Delivery Director 8.5

•

You can now select GitLab, AWS S3, and Web Service as source control systems from which to import YAML files.

These new options have been added to the Source Control endpoint parameter.

•

You can now use AWS S3 as a file source, a connection to JSON format representations of releases.

For more information, see Kubernetes Plug-in.

BlazeMeter Plug-in

The following update was made for plug-in version 3.7:

•

A new execution parameter, Enable JMeter Parameters, was added to the Get Test Assets (import tests/test

suites) function in the Adaptive Testing Catalog. This parameter lets you import BlazeMeter tests with the taurus

configuration type with a JMeter executor.

•

The cdd_BlazeMeter_plugin.log file was renamed as cdd-blazemeter-plugin.log.

For more information, see BlazeMeter Plug-in.

GitLab Plug-in

The following updates were made for plug-in version 1.5:

•

You can now synchronize issues (work items) between GitLab and Continuous Delivery Director and assign issues to

release tasks.

For more information, see GitLab Plug-in.

Atlassian Bitbucket Plug-in

The following updates were made for plug-in version 2.2:

•

A new Trust Any SSL Certificate endpoint parameter lets you allow untrusted and unsigned SSL/TLS certificates.

For more information, see Atlassian Bitbucket Plug-in.

Plug-in for Jenkins

The following update was made for plug-in versions 3.2.9 - 3.2.10

•

The order of the input parameters in the Send notification to CDDirector post-build action was changed.

The following updates were made for plug-in version 3.2.8:

•

Two new options have been added to the Send notification to CDDirector post-build action:

–

Create a release and/or execute an existing one

If you select this option, the following parameters display:

•

Update Token Values in CDDirector (pre-existing)

•

Ignore Nonexistent CDD Application (pre-existing)

•

DSL Parameter (new)

–

Only run my tests in CDD

If you select this option, the following parameters display:

•

Test Data (new)

•

Run a subset of test suites selected by the Test Advisor (new)

•

A new field has been added to the Send notification to CDDirector post-build action: Source Control Connection

Parameters.

•

Two new section headings have been added to the Send notification to CDDirector post-build action:

–

Set Application Name

–

Set Application Version Name

224

Continuous Delivery Director 8.5

For more information, see Plug-in for Jenkins.

9-September-2020

Enhanced

Cucumber for Java Plug-in

The following updates were made for plug-in version 1.3:

•

Two new parameters, Settings File Path, and Update Snapshots were added to the Run Adaptive Testing task.

The following updates were made for plug-in version 1.2:

•

A new parameter, Cucumber Tags was added to the Run Adaptive Testing task.

For more information, see Cucumber for Java Plug-in.

Plug-in for Jenkins

The following updates were made for plug-in version 3.2.7:

•

A new option has been added to freestyle projects, Ignore Nonexistent CDD Application? You select this option to

prevent the failure of a Jenkins post-build action in any of the following cases:

–

The specified application does not exist in Continuous Delivery Director

–

The specified application version does not exist in Continuous Delivery Director

–

No release exists that is associated with the specified application version

A similar Boolean parameter, ignoreNonexistentApplication, has been added to Jenkins pipeline projects.

•

You can now click a link in Jenkins to open a release in Continuous Delivery Director that is triggered by a specific

Jenkins Pipeline build. These links appear on the left panel of a Jenkins build in the format CDD {release-name}

Release.

For more information, see Plug-in for Jenkins.

Red Hat Ansible Core Plug-in

The following update was made for plug-in version 2.0:

•

This plug-in now supports the capability to add multiple applications to tasks, and to assign different build numbers to

each application. To support this capability, the Build field in the Run Playbook task is now optional; previously this

field was mandatory.

For more information, see Red Hat Ansible Core Plug-in.

REST Plug-in

The following update was made for plug-in version 2.6:

•

This plug-in now supports URLs that contain top-level domain names that do not appear in a list of valid generic top-

level domains. To support this capability, a new property was added to the settings.properties file of the REST

plug-in.

For more information, see REST Plug-in.

TFS Plug-in

The following update was made for plug-in version 1.1:

225

Continuous Delivery Director 8.5

•

You can now use TFS/VSTS as a file source so that releases are automatically created and run whenever you make

changes to a specified JSON file.

•

A new endpoint parameter has been added, TFS Version. You can choose from the following options:

–

TFS 2018 Update 3

–

TFS 2018 RTW

–

TFS 2018 RTW

For more information, see TFS Plug-in.

15-July-2020

New

Reduced Preconfiguration Effort for Jenkins Build Notifications

You do not need to create an application version as a precondition for accepting build notifications from Jenkins. When

a build notification arrives, Continuous Delivery Director creates the application version (if none exists) and if requested,

replaces the application version in the target release.

For more information, see Plug-in for Jenkins.

Unified Post-Build Notification setting in Jenkins

Instead of specifying the application and version per Jenkins project, you can use one setting for your entire organization.

The Continuous Delivery Director plug-in in Jenkins uses the Git setting to send the right data to Continuous Delivery

Director.

For more information, see Plug-in for Jenkins.

Multiple Plug-in Proxies

The following capabilities have been added to the plug-in proxy feature:

•

You can now assign multiple plug-in proxies to the same plug-in. Previously, you could only assign one plug-in proxy to

a specific plug-in.

•

You can now select a plug-in proxy when registering a plug-in. To support this capability, a Select Proxy parameter

has been added to the Register Plug-in dialog.

•

To support plug-in management, a new Plug-in Proxies page has been added. This page lists proxy details including

connectivity status and lets you update, enable/disable, and delete proxies.

•

When selecting a plug-in (while creating or editing endpoints, tasks, test/work item/commit/file sources), both the plug-

in name and any assigned plug-in proxy name are shown in the format {plug-in name}/{proxy display name}. You can

also see plug-in proxy names in exported DSL (release-as-code).

•

New configurable plug-in proxy parameters have been added to settings.properties.

•

To support the new plug-in proxy capabilities, two new cross-project permissions have been added:

–

Can connect plug-in proxy - only proxies that connect with an API key assigned this permission can connect to

Continuous Delivery Director.

–

Can manage plug-in proxy - lets you update, enable/disable, delete and retrieve plug-in proxies

For more information, see Plug-in Proxies.

Apache Tomcat Plug-in

A new plug-in helps you to deploy WAR files stored in a Maven repository to Tomcat using the Tomcat Web Application

Manager.

226

Continuous Delivery Director 8.5

For more information, see Apache Tomcat Plug-in.

Cucumber for Java Plug-in

A new plug-in lets you easily add Cucumber Java-based features as test suites to your release pipeline. This plug-in

integrates with Cucumber-JVM, a pure Java implementation of Cucumber.

For more information, see Cucumber for Java Plug-in.

Endevor SCM Plug-in

A new plug-in lets you automate deployments of mainframe software through Endevor Software Change Manager

(Endevor SCM) by generating Endevor packages dynamically throughout the lifecycle. The following tasks are available

for the creation and management of packages within your Continuous Delivery Director pipeline.

•

Create Package

•

Cast Package

•

Approve/Deny Package

•

Execute Package

•

Backout Package

•

Ship Package

•

Delete Package

For more information, see Endevor SCM Plug-in.

GitLab Plug-in

A new plug-in lets you use GitLab SCM (Source Control Management) as your source control system to retrieve commit

messages.

The following updates were made for plug-in version 1.4:

•

In the Branch field of the Get Files task, you can now enable the processing of GitLab webhook notifications from all

repository branches.

•

A new Trust Any SSL Certificate endpoint parameter lets you allow untrusted and unsigned SSL/TLS certificates.

For more information, see GitLab Plug-in.

Microsoft Teams Plug-in

A new plug-in lets you integrate Microsoft Team real-time messaging capabilities with your release pipeline.

For more information, see Microsoft Teams Plug-in.

Plug-in for GitLab

A new YAML-based integration lets you send change notifications from a GitLab CI pipeline to Continuous Delivery

Director using GitLab CI variables.

For more information, see Plug-in for GitLab.

Runscope Plug-in

A new plug-in lets you can add an Adapting Testing task to your release pipeline that executes a Runscope API test.

For more information, see Runscope Plug-in.

227

Continuous Delivery Director 8.5

TestCafe Plug-in

A new plug-in lets you execute TestCafe test suites as part of your release pipeline.

This plug-in integrates with TestCafe, a node.js tool to automate end-to-end web testing. The TestCafe plug-in

is containerized and supports Adaptive Testing functionality. You can import tests from TestCafe to run as test suites within

release pipelines.

For more information, see TestCafe Plug-in.

Enhanced

Atlassian Bitbucket Plug-in

The following updates were made for plug-in version 2.1:

•

A new optional endpoint parameter, Project Key, was added.

For more information, see Bitbucket Plug-in.

Atlassian Jira Plug-in

The following updates were made for plug-in version 2.4:

•

You can now retrieve child issues together with parent issues in one API call if an embed parameter is present in the

request. Previously, you could only retrieve parent and child issues in separate API calls. Additionally, the getContent

API call is now asynchronous; previously, this API call was synchronized.

For more information, see Atlassian Jira Plug-in.

Cucumber for Ruby Plug-in

The plug-in formerly called Cucumber is now renamed to Cucumber for Ruby.

For more information, see Cucumber for Ruby Plug-in.

Docker Plug-in

The following updates were made for plug-in version 1.2:

•

A new Remove Image task lets you remove specified images from a container.

For more information, see Docker Plug-in.

GitHub Plug-in

The following updates were made for plug-in version 1.0.3:

•

A new endpoint parameter, Owner, was added.

•

In the Branch field of the Get Files task, you can now enable the processing of GitHub webhook notifications from all

repository branches.

For more information, see GitHub Plug-in.

Plug-in for Jenkins

The following update was made for plug-in version 3.2.4:

•

You can now determine whether your Jenkins project uses a repository name as the application name or an application

name that you provide. You can also determine whether your project uses a Git branch name as the application

228

Continuous Delivery Director 8.5

version or an application version that you provide. This enhancement applies to Pipeline, Freestyle project, and

Multibranch Pipeline projects and is available if you integrate Jenkins with GitHub, GitLab, Bitbucket Server, or

Bitbucket (SaaS). To support this enhancement, new radio buttons and fields were added to the Send notification to

CDDirector post-build action:

–

Use Source Code Repository Name as Application Name

–

Use Application Name

–

Use Source Code Branch Name as Application Version

–

Use Application Version

For more information, see Plug-in for Jenkins.

19-February-2020

New

Cucumber Plug-in

A new plug-in lets you easily trigger Cucumber acceptance tests automatically from your releases.

For more information, see Cucumber Plug-in.

29-January-2020

New

Gradle Testing and Robot Framework Plug-ins

The Gradle Testing and Robot Framework plug-ins are now available in Continuous Delivery Director SaaS.

For more information, see Gradle Testing Plug-in and Robot Framework Plug-in.

Enhanced

Atlassian Bitbucket Plug-in

The following updates were made for plug-in version 2.0:

•

You can now use Bitbucket as your source control system to retrieve commit messages so you can track planned

vs actual work. To support this change, a Bitbucket Get Commit Messages task is now available in the Set Source

Control Connection page.

For more information, see Bitbucket Plug-in.

BlazeMeter Plug-in

The following updates were made for plug-in version 3.1:

•

Support for the Test Advisor was enhanced. This plug-in can now recognize new and updated test suites.

For more information, see BlazeMeter Plug-in.

229

Continuous Delivery Director 8.5

5-December-2019

Enhanced

Rally Plug-in

•

A new field, Success Rate, has been added to the Check Test Case Results task. Users can enter the percentage of

tests that are required to pass for the task to succeed.

•

Support has been added for Multi-Value Dropdown List, a custom field type in Rally.

For more information, see Rally

Plug-in.

Micro Focus ALM Plug-in

The following updates were made for plug-in version 2.2:

•

Tests can now run in batch mode. Previously, tests could only run one-by-one.

•

The Test Advisor can now run ALM test suites according to the New and Updated tests heuristic.

For more information, see Micro Focus ALM Plug-in.

2-October-2019

New

Gradle Testing Plug-in

A new plug-in lets you automate JUnit testing on Git and Apache Subversion (SVN) builds. This plug-in

is containerized and supports Adaptive Testing functionality.

For more information, see Gradle Testing Plug-in.

Robot Framework Plug-in

A new plug-in provides you with a test automation framework for Git builds that is open-source and application-

independent. This plug-in is containerized and supports Adaptive Testing functionality.

For more information, see Robot Framework Plug-in.

Plug-in for Jenkins

The following update was made for plug-in version 3.1:

You can now configure the notification sending functionality to work with different local settings per project.

You can override the global connectivity details of Continuous Delivery Director for any project. To support this feature,

an Override CDDirector Configuration checkbox has been added. If you select this option, the list of CDDirector

configuration parameters appears, with the global values as defaults. Any changes to the global Continuous Delivery

Director configuration will not affect this project.

For more information, see Plug-in for Jenkins.

230

Continuous Delivery Director 8.5

20-August-2019

Enhanced

Jenkins Plug-in Support

Jenkins Plug-in Support was added for the tree query parameter, used in Jenkins Enterprise (CloudBees). Additionally,

support was added for the CloudBees Request Filter Plugin. This plug-in is used to enhance the security of REST calls

that include a tree query parameter.

For more information, see Jenkins Plug-in.

Red Hat Ansible Plug-in

You can now configure secure connections to GitHub and Bitbucket.

For more information, see Red Hat Ansible Plug-in.

Red Hat Ansible Tower Plug-in

You can now download and access the standard output of jobs, enabling you to view the deployment details. To support

this change, two new settings are added to the endpoint configuration, Store Job Output and Shared File System

Location.

For more information, see Red Hat Ansible Tower Plug-in.

Plug-in for Jenkins

Support is added for Jenkins Pipeline.

For more information, see Plug-in for Jenkins.

Atlassian JIRA Plug-in

Imported work item IDs are now clickable.

For more information, see Atlassian JIRA Plug-in.

29-May-2019

Enhanced

10-April-2019

New

Email Plug-in

A new Email plug-in lets you send preconfigured auto-generated email messages from your continuous delivery pipeline.

For more information, see Email Plug-in.

Red Hat Ansible Plug-in

A new Ansible plug-in lets you run playbooks within releases. You can use playbooks to manage configurations of and

deployments to remote machines.

231

Continuous Delivery Director 8.5

For more information, see Red Hat Ansible Plug-in.

Containerized Plug-in Manager

Continuous Delivery Director now supports containerized plug-ins that automate the configuration of integration

environments. These plug-ins are based on Integration-as-a-Service (IaaS), which is a cloud service delivery model for

integration. This solution allows release managers to put together quickly integration flows and implement orchestrations,

thereby accelerating development time.

A new containerized plug-in manager tool helps you add containerized plug-ins to your CD pipelines in minutes.

NOTE

Currently, the containerized plug-in manager supports the addition of the Red Hat Ansible core plug-in to

releases.

For more information, see Set Up Containerized Plug-ins.

Enhanced

Rally

Plug-in

The following update was made for plug-in version 2.5:

•

Support was added for Java 11

The following update was made for plug-in version 2.4:

•

Two new input parameters have been added to the Add Work Items capability, Additional Filters and Import from

Child Projects.

For more information, see Rally

Plug-in.

JFrog Artifactory Plug-in

The following update was made for plug-in version 2.1:

•

Support was added for Java 11

The following update was made for plug-in version 2.0:

•

A new task, Copy Item, has been added. This task lets you copy an artifact or folder from a local Artifactory repository

to another repository.

For more information, see JFrog Artifactory Plug-in.

Kubernetes Plug-in

The following update was made for plug-in version 1.3:

•

A new task, Copy Item, has been added. This task lets you copy an artifact or folder from a local Artifactory repository

to another repository.

•

The method to authenticate to the Kubernetes service account has been changed from Basic (username/password)

to Bearer tokens. This method allows the Kubernetes plugin to interface with systems that allow authentication with an

API token.

•

Support was added for Java 11.

For more information, see Kubernetes Plug-in.

232

Continuous Delivery Director 8.5

Red Hat Ansible Tower Plug-in

The following update was made for plug-in version 1.0.5:

•

Support was added for Java 11

The following update was made for plug-in version 1.0.4:

•

A new Build/Change ID field has been added to the Run Job Template task. You can specify the number of a

successful build or commit to either mark the code change as deployed or to promote the change to the next phase.

For more information, see Red Hat Ansible Tower Plug-in.

Red Hat OpenShift Plug-in

The following updates were made for plug-in version 1.1

•

Support was added for Kubernetes versions 1.9 and higher.

•

Support was added for Java 11

For more information, see Red Hat OpenShift Plug-in.

REST Plug-in

The following updates were made for plug-in version 2.3

•

A new Authentication Method endpoint parameter has been added. In addition to Basic authentication, a

new method, Bearer, is now available. This method allows the REST plugin to interface with systems that allow

authentication with an API token.

•

Support was added for Java 11

For more information, see REST Plug-In.

5-February-2019

New

Docker Plug-in

A new Docker plug-in helps you deploy Docker images to run and to remove containers, and to run commands within

containers. Optionally, for the Run Container task, you can run a readiness probe to notify you when the container is

ready to accept traffic.

For more information, see Docker.

SonarQube Plug-in

A new SonarQube plug-in lets you verify the health of your project against quality gates. SonarQube quality gates contain

a set of Boolean conditions based on metrics such as code coverage on new code, no new blocker issues, and so on.

For more information, see SonarQube Plug-in.

233

Continuous Delivery Director 8.5

12-December-2018

New

Atlassian Bitbucket Plug-in

A new Atlassian Bitbucket plug-in lets you use Bitbucket as your file source, a connection to a JSON format file

representation of a release. You can also use Bitbucket as a file source to manage JSON files that reference other JSON

files.

After the Bitbucket file source is configured, any changes to a JSON file in your repository will automatically create and

run a release.

For more information, see Bitbucket.

Enhanced

GitHub Plug-in

You can now use the GitHub plug-in to use GitHub as a file source, a connection to a JSON format file representation of a

release.

For more information, see GitHub Plug-in.

Nolio Release Automation Plug-in

In the Run Deployment task, a new Manifest field lets you add a deployment manifest previously generated in Release

Automation. This new capability lets you pass parameters, including Continuous Delivery Director tokens, to a running

deployment, using the RA manifest in XML format.

In the Run Deployment task, a new field, Fail This Task When Step Errors Occur In, lets you specify that the task fails

if a step in a selected stage is in failed paused status.

For more information, see Nolio Release Automation Plug-In.

6-November-2018

New

ServiceNow

Plug-in

An additional ticket type, Request, is now supported. You can now update a request, add a task to a request item, update

a task for a request, and want for approval for a request ticket. To support this change, the following task types have been

updated:

•

Create Task

•

Update Task

•

Update Ticket

•

Wait for Approval

For more information, see ServiceNow.

234

Continuous Delivery Director 8.5

Rally Plug-in

The Check Test Case Results task now lets you check the results given test sets. To support this change, the User story

and/or Defect IDs field has been renamed to Work Item IDs. This field now lets you enter test set IDs in addition to user

story and defect IDs.

The CA Agile Central plug-in has been enhanced to support the new Work Items list functionality.

For more information, see Rally.

Plug-in for Jenkins

You can now configure the plug-in for Jenkins to automatically send Git Commit IDs to Continuous Delivery Director

whenever a build is created in Jenkins.

For more information, see Plug-in for Jenkins.

6-August-2018

New

Autosync for Plug-Ins

When a plug-in is updated with new or enhanced capabilities, Continuous Delivery Director automatically synchronizes

the plug-in version in your workspace. This features allows you to access any new fields and parameters added since the

previous plug-in version.

Micro Focus ALM Plug-in

A new Micro Focus Application Lifecycle Management (ALM) plug-in enables you to run functional test sets as your

applications progress through the Continuous Delivery Director pipeline. You can track milestones and defects in real-time

and can have visibility into the applications under development.

Note: The ALM plug-in is not autoregistered. You can only run the ALM plug-in on an on-prem Windows server connected

to Continuous Delivery Director with the plug-in proxy.

For more information, see Micro Focus ALM.

Red Hat OpenShift Plug-in

A new Red Hat OpenShift plug-in lets you control your Kubernetes environment from your CI/CD pipeline.

For more information, see Red Hat OpenShift Plug-in.

Red Hat Ansible Tower Plug-in

A new Red Hat Ansible Tower plug-in allows you to execute Ansible jobs from the Continuous Delivery Director pipeline,

according to job templates.

For more information, see Red Hat Ansible Tower Plug-in.

JetBrains TeamCity Plug-in (Deprecated)

A new JetBrains TeamCity plug-In lets you easily add completed builds to your pipeline for deployment, testing, and

production.

The TeamCity integration enables zero-touch continuous delivery, continuous testing, and continuous deployment. This

plug-in fully integrates TeamCity CI and build functionality into the robust Continuous Delivery Director pipeline planning,

235

Continuous Delivery Director 8.5

management, and orchestration functionality. Enable the TeamCity plug-in to connect TeamCity builds directly to the

Continuous Delivery Director pipeline so that a successful build triggers pipeline execution.

Plug-in for Microsoft Team Foundation Server

A new Continuous Delivery Director plug-in for Microsoft Team Foundation Server (TFS) lets you trigger the execution of a

release in Continuous Delivery Director when a TFS build completes.

For more information, see Plug-in for Microsoft Team Foundation Server.

Enhanced

Microsoft Team Foundation Server Plug-in

The new Run Build task lets you run TFS or VSTS project builds in the context of phases and releases.

For more information, see Microsoft Team Foundation Server Plug-in.

Atlassian JIRA Plug-in

Output parameters are added to the Create Jira Issue task. You can store the key, ID, and URL of a created issue as a

token and update the issue in other tasks.

For more information, see Atlassian JIRA Plug-in.

10-September-2017

New

Plug-in Proxy

Continuous Delivery Director has developed a plug-in proxy to allow Continuous Delivery Director SaaS users to execute

plug-in services through on-premise components securely, regardless of corporate firewalls.

To support this change, a Use Proxy checkbox has been added to the Plug-ins page for on-premise plug-ins, such as CA

Continuous Delivery Automation.

For more information, see Proxy Plug-in.

A new JFrog Artifactory plug-in is available.

A new Automic Release Automation plug-in is available for use with the plug-in proxy.

Enhanced

CA REST Plug-in

The CA REST plug-in now supports REST 2.0.

In Continuous Delivery Director SaaS, the upgrade from REST 1.0 to REST 2.0 is done automatically.

For more information, see REST Plug-In.

Atlassian JIRA Plug-in

The Create JIRA Issue task has been updated as follows:

A new checkbox, Show advanced settings has been added. If selected, additional fields display.

236

Continuous Delivery Director 8.5

A new field, Custom fields, has been added.

For more information, see Atlassian JIRA Plug-in.

A new Veracode plug-in is available.

The Twistlock plug-in is enhanced with timeout capabilities.

A new web page is available to access the latest plug-ins.

25-June-2017

The following new plug-ins are available:

•

Flowdock

•

Kubernetes

•

Twistlock

The following plug-ins are enhanced:

•

Atlassian JIRA

•

AWS Code Deploy

•

AWS Elastic Beanstalk

•

ServiceNow

Setting up a Local Plugin Server

System Requirements

Operating System Support

•

Red Hat Enterprise Linux 7.3 and higher

•

CentOS Enterprise OS 7.3 and higher

Hardware Requirements

Size Core CPU RAM (in GB) Disk Space (in GB)

Minimal 2 16 80

Mid-Scale 4 32 80

Large-Scale 8 128 100

Software Requirements

•

Latest Apache Tomcat 8.5.x

•

Latest Oracle JRE and OpenJRE/OpenJDK - Java JRE 8.x (64-bit) and Java JRE 11.0 (64-bit)

•

Latest Docker Engine

Setup Instructions

Enable Firewall ports and Perform OS Updates

•

It is recommended you update the host OS to the latest patches according to your selected operating system.

•

Enable the following ports in the firewall settings:

237

Continuous Delivery Director 8.5

–

443

–

8080

–

4550

•

Enable “WebSocket protocol (WSS)”.

Create OS user and group on CDD server

CDD’s Plugins will write its logs to the file system. It is recommended to create the same OS user and OS group, as the

embedded user in docker image, in the host.

•

Create OS user: cdd with UID = 1010

•

Create OS Group: cdd with GID = 1010

•

Create the home folder with the below structure:

–

/home/cdd/

–

/home/cdd/.cdd

–

/home/cdd/.cdd/conf and /home/cdd/.cdd/logs

•

Change ownership of all folders to the cdd user.

Install Docker Engine

•

Install the latest docker engine

•

Enable the remote Docker API (port 4550)

•

Update Docker daemon and set to auto restart

Install Tomcat

Install Tomcat and set it to run under the user “cdd” and the group “cdd”.

Install the Plugin Proxy

Follow the instructions of the Plugin-Proxy deployment in the CDD documentation.

Install and Register CDD Plugins

•

Install “war” plugins: Download the plugins war files and store them in the Tomcat WebApps folder.

•

Install Containerized Plug-ins: To use Containerized plugins (for example, Cucumber JVM, Gradle Testing, and so

on), see the Containerized Plug-ins section.

•

Manage Plug-ins

Integrate plug-ins with Continuous Delivery Director to enable essential integrations with remote components.

This document describes how to install plug-ins and integrate them with your Continuous Delivery Director installation. For

information about the functionality provided by each plug-in, see the online documentation.

Continuous Delivery Director provides the following plug-ins that are packaged and installable out-of-the-box:

[A] [B] [C] [D] [E] [F] [G] [H] [J] [K] [M] [N] [P] [R] [S] [T] [V]

238

Continuous Delivery Director 8.5

•

Atlassian Bitbucket

•

Atlassian JIRA

•

Apache Tomcat

•

Automic

Continuous Delivery Automation

•

AWS CodeDeploy

•

AWS Elastic Beanstalk

•

Azure DevOps Server (formerly Microsoft Team Foundation Server)

•

BlazeMeter

•

Cucumber for Java

•

Cucumber for Ruby

•

Docker

•

DX App Experience Analytics

•

DX App Synthetic Monitor Plug-in

•

Endevor SCM

•

Flowdock

•

GitHub

•

GitLab

•

Gradle Testing

•

Helm Plug-in

•

Jenkins

•

JFrog Artifactory

•

Kubernetes

239

Continuous Delivery Director 8.5

•

Maven Testing

•

Micro Focus ALM

•

Microsoft Teams

•

Nolio Release Automation

•

Playwright

•

Rally

(formerly CA Agile Central)

•

Red Hat Ansible

•

Red Hat Ansible Tower

•

Red Hat OpenShift

•

REST

•

Robot Framework

•

Runscope

•

ServiceNow

•

Slack

•

SonarQube

•

TestCafe

•

Twistlock

•

Veracode

Plug-in Management Workflow

The following steps represent the high-level plug-in management workflow:

1. Install plug-ins.

2. Register plug-ins.

3. Use endpoints to connect to remote component systems.

4. Import data from remote components, such as content or application model.

5. Use automatic tasks that are provided by the plug-ins to execute operations on the remote components.

6. (Optional) Synchronize plug-ins to apply the latest changes to the plug-in.

7. (Optional) Remove plug-ins.

240

Continuous Delivery Director 8.5

TIP

Steps 2, 3, 4 (application model), 6, and 7 require a product Administrator role. Steps 4 (content) and 5 require a

product Designer role.

Install Plug-ins

TIP

Plug-in installation is not required for SaaS users unless you need to install a custom plug-in that you have

developed. Packaged plug-ins are preinstalled with the SaaS instance.

NOTE

You can run packaged plug-ins on your own on-premise network.

From the support site https://casupport.broadcom.com, download the packaged plug-in, then deploy this plug-in

on a Tomcat 8 web container.

All packaged plug-ins require Tomcat 8.

Install plug-ins on the same server as Continuous Delivery Director or on remote servers. Consider the anticipated load on

the plug-ins before deciding to distribute, such as:

•

The amount, frequency, and potential concurrency of task execution

•

The size, frequency, and potential concurrency of imports (both application models and content)

•

The number of connected endpoints per plug-in

A remote plug-in server for packaged plug-in installation requires Tomcat 8 and Java 1.8 to be running on the remote

server.

In general, Continuous Delivery Director custom plug-ins can be developed using any programming language (Java,

Python, PhP, and so on) and can be hosted by any web container (Tomcat, JBoss, IBM Liberty, and so on). All Continuous

Delivery Director packaged plug-ins require Apache Tomcat 8.

Install a single instance of each required plug-in. One plug-in instance can support multiple endpoint connections.

Follow these steps:

NOTE

These steps might vary for custom plug-ins based on your implementation method. For example, if the plug-in

package is a .war file, you might want to deploy to a different servlet container or on the CDD Server Tomcat

instance.

1. Download the .war files for the packaged plug-ins.

2. Stop the Apache Tomcat service on the plug-in server.

3. Copy the plug-in .war file into the webapps folder of the Tomcat installation directory.

TIP

Plug-ins that you are installing on the same server as the CDD Server component can be installed at the

same time as the CDD Server.

4. Start the Apache Tomcat service.

The plug-ins are installed.

plug-ins that are installed on the Continuous Delivery Director Server are registered automatically.

241

Continuous Delivery Director 8.5

TIP

As a SaaS user, when you log in for the first time, all existing plug-ins are automatically registered for you. Plug-

in registration is only required for SaaS users when new plug-ins are added to the SaaS instance after your

initial login. Monitor release notes to be notified of new plug-ins, which you register using this procedure.

Packaged plug-ins are installed as .war files in an Apache Tomcat server. The .war file includes a manifest.json file. The

plug-in manifest specifies the plug-in capabilities and the URL for each of the plug-in services. To register a plug-in, you

enter the path to the manifest file in the UI.

While custom plug-in implementation methods can vary, all plug-ins require a manifest.json file. The manifest path might

differ if you implement a custom plug-in differently than the packaged plug-ins, but the concept is the same.

TIP

You can also register plug-ins using the REST API. For more information, see REST API Reference.

Follow these steps:

1. In Continuous Delivery Director, select Administration, and Plug-Ins.

2. Click Register Plug-In.

3. Specify the URL of the plug-in manifest. The plug-in manifest is the location of the JSON file.

On-Premise Examples:

–

Automic@ Continuous Delivery Automation plug-in manifest URL

http://<host>:<port>/cdd-ara-plugin/manifest.json

–

CA REST plug-in manifest URL

http://<host>:<port>/cdd-rest-plugin/manifest.json

These examples can represent locally or remotely installed plug-ins.

NOTE

If you configure the product to use HTTPS communication, you must update existing plug-in registrations

that previously used HTTP. For more information, see Secure Communications.

Example:

•

https://myhost:443/cdd-slack-plugin/manifest.json

4. Click Register.

The plug-in is discovered and registered and shows in the Plug-Ins page.

NOTE

Add Endpoints

To connect an endpoint with an instance of a remote component, add an endpoint for a registered plug-in. Each plug-in

uses a single endpoint type (Endpoint Template) and can connect to multiple endpoint instances of that type. For example,

you can connect a ServiceNow plug-in to multiple ServiceNow servers, if needed.

The information that is required for each endpoint connection varies by the plug-in. For more information, see the

documentation for each plug-in.

Follow these steps:

1. Go to Administration, Endpoints, and click Add Endpoint.

2. Specify the Name, Description, and select the Endpoint Type.

Each plug-in has an endpoint type. When you register a plug-in, its endpoint type becomes available to add in this

dialog.

3. Specify the information that is required for the endpoint type you selected, and click Add.

242

Continuous Delivery Director 8.5

The endpoint is added.

NOTE

Manage Endpoints

Import Plug-in Data

Plug-ins can support the import of the following data from their remote component:

•

Application models

•

Content Items

Import application models during the administration phase before you create releases. You can then add applications and

environments from the remote component to your releases, phases, and tasks.

Import content items during the release design phase to associate specific work items with a release.

NOTE

•

Manage Applications and Environments

•

Design and Create Releases

Use Plug-in Tasks

Tasks let you instrument functionality in the remote component. You add tasks to phases and provide the appropriate

input values to execute the provided functionality in your release. For example, the Check Test Case Results task that is

provided by the Rally plug-in queries the results of a test case in Rally.

You add tasks to releases during the design phase and execute them when you run the release. For more information

about the required inputs for each task, see the detailed documentation for each packaged plug-in.

NOTE

•

Design and Create Releases

•

Plug-ins

Synchronize Plug-ins

When you upgrade to a higher, or downgrade to a lower, plug-in version, synchronize the plug-in. This

synchronization captures the latest plug-in manifest. We also recommend that you synchronize the plug-in when you

update remote components or plug-in versions. For example, to synchronize with the latest Automic@ Continuous

Delivery Automation application model changes, synchronize the Automic@ Continuous Delivery Automation plug-in.

Follow these steps:

1. Select Administration, and Plug-Ins.

2. Mouse over the name of the plug-in, select the information icon, and select Sync Plugin.Continuous Delivery Director

updates the plug-in registration with the new plug-in capabilities based on the new plug-in manifest. For example,

the import application model capability is added, or a task is updated and shows under the plug-in name.

Remove Plug-ins

You can remove a plug-in from your workspace at any time. When you remove a plug-in:

•

All related endpoints are permanently deleted

•

The task configuration in all related tasks is permanently deleted

•

The task type in all related tasks reverts to Manual

243

Continuous Delivery Director 8.5

Follow these steps:

1. From the Administration menu, select Plug-ins.

2. Select the relevant plugin, click the actions icon, then Delete Plug-in.

3. Only for OnPrem and SaaS instances running plug-in proxy—On the plug-in server, remove the deleted plug-in

folder and .war file from the webapps folder of the Tomcat installation directory.

Plug-in Proxy

You configure a plug-in proxy to execute on-premise plug-in services that run behind a firewall. You can assign multiple

plug-in proxies to a single plug-in.

Why Do I Need a Plug-in Proxy?

Let us say that you want to integrate Continuous Delivery Director SaaS with on-premise DevOps components, such as

Automic Continuous Delivery Automation, your corporate GitHub or JFrog Artifactory.

However, these on-premise components reside inside your corporate network. These components are protected by the

corporate firewall from unauthorized internet access. The use of the firewall means that Continuous Delivery Director

SaaS cannot easily connect to these components from outside your corporate network.

Continuous Delivery Director has developed a solution that is based on a plug-in proxy. This solution allows Continuous

Delivery Director SaaS users to execute plug-in services through on-premise components securely, despite the firewall.

How does the Plug-in Proxy Work?

The following diagram shows the plug-in proxy architecture:

Figure 33: Plug-in Proxy

244

Continuous Delivery Director 8.5

Plug-in Proxy Workflow

1. The plug-in proxy is deployed inside the customer (tenant) on-premise network

2. The on-premise installed plug-in proxy initiates a connection request to the remote CDD installation (cddirector.io of a

CDD instance installed in an external firewall system). This connection uses the secured WebSocket protocol (WSS)

through ports 80 or 443.

NOTE

If your organization uses a Web proxy, the plug-in proxy connects to Continuous Delivery Director through

that web proxy.

The plug-in proxy cannot connect to https://cddirector.io if the WebSocket WSS protocol is blocked by on-

premise network elements such as the network router, firewall, and so on). The corporate firewall must be

configured to enable the WebSocket WSS protocol.

WebSocket connections generally work even if a firewall is in place. The connections succeed because

WebSocket connections use ports 80 and 443 which are also used by HTTP connections.

Sometimes WebSocket connections are blocked over port 80. If so, a secure SSL connection using WSS

over port 443 should successfully connect.

3. The plug-in proxy authenticates to the remote Continuous Delivery Director installation using a tenant ID and an API

Key of an user with administrator role.

4. Using the deployed plug-ins proxy, you now can register a plug-in which is installed within the on-premise data center.

You can use this plugin’s capabilities within your releases.

How can I Tell that a Plug-in Proxy is in Use?

Users select plug-ins when creating or editing endpoints, tasks, test/work item/commit/file sources. When selecting a plug-

in, both the plug-in name and any assigned plug-in proxy name are shown in the format {plug-in name}/{proxy

display name}.

For example, a user edits a Rally Update task. In the task type dropdown list, they see Rally/Dev, Rally/QA, and

Rally/Deploy, meaning that different plug-in proxies named Dev, QA, and Deploy, are assigned to the Rally plug-in.

You can also see plug-in proxy names in exported DSL: "plugin": "EMEA|Rally/Dev",

More Information

Set Up a Plug-in Proxy

Run Plug-in Proxy With Docker Compose

Run Plug-in Proxy Without Docker Compose

Configure Plug-in Proxy Properties

Manage Plug-in Proxies

Set Up a Plug-in Proxy

To enable a plug-in proxy, you need a Docker engine and a Docker image pulled from the support download center.

PREREQUISITES

•

A server with Docker Engine 19.x or higher is allocated inside your on-premise network.

•

Firewall access is enabled from the server to Continuous Delivery Director over the WebSocket protocol.

245

Continuous Delivery Director 8.5

NOTE

The plug-in proxy connects to Continuous Delivery Director through the WebSocket protocol. This step is

needed to enable the plug-in proxy to communicate through WebSocket.

•

The WSS protocol is enabled from the plug-in proxy machine to Continuous Delivery Director SaaS (cddirector.io).

•

Obtain your tenant ID and the API Key of an administrator user for authentication of the plug-in proxy.

CAUTION

If the administrator permissions of the user whose API key is used are removed, the communication fails!

Prepare Your Machine

1. From the Docker Engine server command line, create user cdd with uid 1010 , group cdd with gid 1010, and add

user cdd to the docker group .

useradd -u 1010 cdd

groupadd 1010 -g 1010 cdd

useradd 1010 -u 1010 -g 1010 -G docker cdd

NOTE

The code within the docker container runs with uid=1010 and gid=1010. To enable proper tracing, create

uid=1010 and gid=1010 on the host box.

2. Create the following folder structure:

/home/cdd/.cdd

/home/cdd/.cdd/logs

/home/cdd/.cdd/cdd-plugins-proxy

3. Change the directory to the required base folder.

/home/cdd/.cdd

NEXT STEPS

Install the docker image on your machine by downloading a tar.gz folder from the support download center or a download

link.

Pull the Plug-in Proxy Docker Image from the Support Site

NOTE

The following steps are only required if you have not received a download link and have not downloaded the

plug-in proxy tar.gz folder archive to your machine.

246

Continuous Delivery Director 8.5

In a Web browser, enter the URL https://casupport.broadcom.com/download-center/download-center.html and provide

valid credentials to download Broadcom software.

2. Type Continuous into the search box, and click a Continuous DLVRY DIRCTR tile.

Figure 34: Download Center

247

Continuous Delivery Director 8.5

3. In a table row, select the latest release and click the Docker icon:

Figure 35: Docker icon

248

Continuous Delivery Director 8.5

4. Save the instructions to a file or copy them to a text editor.

Figure 36: Docker command with token

5. Follow the instructions to create a local token, log in to the Broadcom repository and pull the required docker image.

On your docker engine machine:

Create token

token='eyJ2ZXIiOiIyIiwidHlwIjoiSldUIiwiYWxnIjoiUlMOiJqZnJ0QDAxZXA4M3F2MzFjcnowMHg2ZjZ6eWYwNHo2XC91c2Vyc1wvY29saW4ua3VycmFudEBicm9hZGNvbS5jb20iLCJzY3AiOiJtZW1iZXItb2YtZ3JvdXBzOkNERC1HRU4wMDAwMDAwMDAzMzA1IGFwaToqIiwiYXVkIjoiamZydEAwMWVwODNxdjMxY3J4cCI6MTYyMjAyNzMzMCwiaWF0IjoxNjIyMDIwMTMwLCJqdGkiOiIzMDRhNDJmNi05YTIzLTQyOGUtYjRjOC1kMTY1ZmVhMGIwZjYifQ.N9rWnq7B--9ZXp2EY26N04w6OKEHAc1DEZaWNSp01HyZKFcf8O-

G4VQNy3khDybsZIIBXblXnv-OhVdesqHQaJrWMu29H9X1ZOlkKVdzXmCNExKz4iLNbQs1KR5fLu1-

RpkRufUhr4dMFbaXcpvT0ScdH6UUECwYIkTv4yV5KNeHjovdyKwhWvZYl8njyjLfVUbA6O7wXpV37FPfiazJZSu7dScRhfzbuS0OF83lveTGZmAbq4DbdwcomR7rMKkQ92jnTGerU722jU6VfmkIg

docker login <docker-registry-name> -u <docker-registry-username> -p <docker-registry-password>

For example:

docker login -u '[email protected]' -p$token cdd.packages.broadcom.com

Pull the plug-in proxy docker image, for example:

docker pull cdd.packages.broadcom.com/plugins-proxy:1234

6. On the target machine, in the command line, for example, PuTTY, paste the generated command lines to access your

registry and to pull the plug-in proxy image.

Add the token, for example:

G4VQNy3khDybsZIIBXblXnv-OhVdesqHQaJrWMu29H9X1ZOlkKVdzXmCNExKz4iLNbQs1KR5fLu1-

RpkRufUhr4dMFbaXcpvT0ScdH6UUECwYIkTv4yV5KNeHjovdyKwhWvZYl8njyjLfVUbA6O7wXpV37FPfiazJZSu7dScRhfzbuS0OF83lveTGZmAbq4DbdwcomR7rMKkQ92jnTGerU722jU6VfmkIg

249

Continuous Delivery Director 8.5

docker login <docker-registry-name> -u <docker-registry-username> -p <docker-registry-password>

For example:

docker login -u '[email protected]' -p$token cdd.packages.broadcom.com

Pull the plug-in proxy docker image, for example:

docker pull cdd.packages.broadcom.com/plugins-proxy:1092

NEXT STEPS

Choose one of the following methods for running the plug-in proxy docker image:

•

With Docker Compose – Choose this method if you want to utilize docker compose capabilities. This will allow you

to run several docker images concurrently (for example, run the plug-in proxy and other plug-ins that run as docker

images). For more information, see Run Plug-in Proxy With Docker Compose.

•

Without Docker Compose – Choose this method if you only want to run the plug-in proxy with the docker run

command. For more information, see Run Plug-in Proxy Without Docker Compose.

Run Plug-in Proxy With Docker Compose

PREREQUISITES

You have carried out the setup procedure described in Set Up a Plug-in Proxy.

1. Initialize swarm mode:

docker swarm init

2. Create a Docker secret to hold your Continuous Delivery Director API key:

echo "{Your API KEY}" | docker secret create cdd_plugins_proxy_api_key -

NOTE

Use the API key of a user with an administrator role. To find your API key, in Continuous Delivery Director,

click the user initials icon and click the My Settings option.

An API key is specific to a Continuous Delivery Director project. If you want to use on-premise plug-ins to

connect to cddirector.io using multiple projects, you need to run multiple instances of the plug-in proxy.

3. On your docker engine machine, connect using the cdd user and change the directory to /home/cdd/.cdd.

4. Create a docker-compose.yaml file.

5. Copy the following code block:

version: '3.1'

services:

cdd-plugins-proxy:

image: "cdd.packages.broadcom.com/plugins-proxy:latest"

environment:

CDD_PLUGINS_PROXY_ID: {plugin-proxy-id}

CDD_PLUGINS_PROXY_CDD_API_KEY_PATH: '/run/secrets/cdd_plugins_proxy_api_key'

CDD_PLUGINS_PROXY_CDD_TENANT_ID: {cdd-tenant-id}

CDD_PLUGINS_PROXY_PLUGINS_WHITE_LIST: {plugin-white-list}

CDD_PLUGINS_PROXY_CDD_URL: {cdd-web-address}

volumes:

- /home/cdd/.cdd:/home/cdd/.cdd

250

Continuous Delivery Director 8.5

secrets:

- cdd_plugins_proxy_api_key

deploy:

replicas: 1

restart_policy:

condition: on-failure

secrets:

cdd_plugins_proxy_api_key:

external: true

6. Replace the following values in the YAML indicated by the curly braces '{}':

CAUTION

Do not change the code except for the values within the curly brackets '{}'. Doing so may cause

unpredictable results, including data loss.

Do not change the indentation or use tab characters.

•

{plug-in-proxy-latest-docker-image-tag}

NOTE

If you have obtained the plug-ins proxy image using the wget commant, make sure to update the full

image URL as defined for the image

•

{plugin-proxy-id}

•

{cdd-tenant-id}

•

{plugin-white-list}

•

{cdd-web-address}

Explanation of parameters:

•

CDD_PLUGINS_PROXY_ID

Unique ID of the plug-in proxy

CAUTION

Assign a meaningful name to the plug-in proxy (the CDD_PLUGINS_PROXY_ID property) to facilitate easy

management and traceability. To avoid possible conflicts with other plug-in proxies, make sure that the

proxy ID you enter is unique.

•

CDD_PLUGINS_PROXY_CDD_API_KEY_PATH

Path to the Docker secret file on the Docker Engine server

•

CDD_PLUGINS_PROXY_CDD_TENANT_ID

The Continuous Delivery Director tenant ID. To find your tenant ID, in Continuous Delivery Director, go to the User

Settings menu.

•

CDD_PLUGINS_PROXY_PLUGINS_WHITE_LIST

A list of the on-premise plug-ins server addresses.

•

CDD_PLUGINS_PROXY_CDD_URL

The web address of Continuous Delivery Director SaaS. Value: https://cddirector.io/

version: '3.1'

services:

cdd-plugins-proxy:

image: "cdd.packages.broadcom.com/plugins-proxy:latest"

environment:

CDD_PLUGINS_PROXY_ID: cdd-plugins-proxy-hostname

CDD_PLUGINS_PROXY_CDD_API_KEY_PATH: '/run/secrets/cdd_plugins_proxy_cddirectorio_api_key'

CDD_PLUGINS_PROXY_CDD_TENANT_ID: 96z98z94-b041-4zf5-9ze85-z41c942z211z

CDD_PLUGINS_PROXY_PLUGINS_WHITE_LIST: abcdev003773.mycompany.net

251

Continuous Delivery Director 8.5

CDD_PLUGINS_PROXY_CDD_URL: https://cddirector.io

volumes:

- /home/cdd/.cdd:/home/cdd/.cdd

secrets:

- cdd_plugins_proxy_api_key

deploy:

replicas: 1

restart_policy:

condition: on-failure

secrets:

cdd_plugins_proxy_api_key:

external: true

7. Deploy the new Docker stack:

docker stack deploy --compose-file=docker-compose.yaml cdd-plugins-proxy-stack

8. Check that the Docker stack is ready:

docker stack services cdd-plugins-proxy-stack

The plug-in proxy is enabled and is available for use for on-premise plug-ins.

Handy Docker Compose Commands

You may find the following commands useful when you manage the plug-in proxy Docker image with Docker Compose.

You enter these commands from the Docker engine server command line.

To do this... Enter

Validate Docker stack is available docker stack services cdd-plugins-proxy-

stack

Stop a running Docker stack docker stack rm cdd-plugins-proxy-stack

Create a Docker secret file echo "{Your API KEY}" | docker secret create

cdd_plugins_proxy_api_key -

List existing Docker secret files docker secret ls

Remove a Docker secret file docker secret rm cdd_plugins_proxy_api_key

Run Plug-in Proxy Without Docker Compose

After you have downloaded the Docker image from the support site, you run the image through a command sequence.

Use this method if you want to run specific on-premise plug-ins only.

This method requires a local Apache Tomcat 8.x instance on which you install the required on-premise plug-ins.

ATTENTION

To enable the communication of the plug-in proxy through WebSocket, you must authenticate to Continuous

Delivery Director with the API key of an administrator. You set up a Docker secret to hold your API key.

CAUTION

If the administrator permissions of the user whose API key is used are removed, the communication will fail!

Use the following command to run the Docker image:

docker run -d \

--name plugins-proxy \

--restart=on-failure \

-v /home/cdd/.cdd:/home/cdd/.cdd \

252

Continuous Delivery Director 8.5

-e CDD_PLUGINS_PROXY_ID=<plugins-proxy-id> \

-e CDD_PLUGINS_PROXY_CDD_API_KEY=<cdd-api-key> \

-e CDD_PLUGINS_PROXY_CDD_TENANT_ID=<tenant-id> \

-e CDD_PLUGINS_PROXY_PLUGINS_WHITE_LIST=<plugin-server1,plugin-server2,...> \

-e CDD_PLUGINS_PROXY_CDD_URL=https://cddirector.io \

cdd.packages.ca.com/com/ca/cdd/plugins-proxy:{plug-in-proxy-latest-docker-image-tag}

If your organization uses a web proxy, to run the Docker image, add the following lines:

docker tag cdd.packages.ca.com/com/ca/cdd/plugins-proxy plugins-proxy:latest

docker run -d \

--name plugins-proxy \

--restart=on-failure \

-v /home/cdd/.cdd:/home/cdd/.cdd \

-e CDD_PLUGINS_PROXY_ID=<plugins-proxy-id> \

-e CDD_PLUGINS_PROXY_CDD_API_KEY=<cdd-api-key> \

-e CDD_PLUGINS_PROXY_CDD_TENANT_ID=<tenant-id> \

-e CDD_PLUGINS_PROXY_PLUGINS_WHITE_LIST=<plugin-server1,plugin-server2,...> \

-e CDD_PLUGINS_PROXY_CDD_URL=https://cddirector.io \

-e CDD_PLUGINS_PROXY_INTERNET_PROXY_URL=http://proxy:8080 \

-e CDD_PLUGINS_PROXY_INTERNET_PROXY_USERNAME=username \

-e CDD_PLUGINS_PROXY_INTERNET_PROXY_PASSWORD=password \

cdd.packages.ca.com/com/ca/cdd/plugins-proxy:{plug-in-proxy-latest-docker-image-tag}

Explanation of parameters:

•

CDD_PLUGINS_PROXY_ID

Unique ID of the plug-in proxy

CAUTION

To avoid possible conflicts with other plug-in proxies, make sure that the proxy ID you enter is unique.

•

CDD_PLUGINS_PROXY_CDD_API_KEY

Use the API key of a user with an administrator role. To find your API key, in Continuous Delivery Director, click the

user initials icon and click the My Settings option.

NOTE

An API key is specific to a Continuous Delivery Director project. If you want to use on-premise plug-ins to

connect to cddirector.io using multiple projects, you need to run multiple instances of the plug-in proxy.

•

CDD_PLUGINS_PROXY_CDD_TENANT_ID

Continuous Delivery Director Tenant ID. To find your tenant ID, in Continuous Delivery Director, go to the User Settings

menu.

•

CDD_PLUGINS_PROXY_PLUGINS_WHITE_LIST

Comma-separated list of Continuous Delivery Director plug-in servers.

•

CDD_PLUGINS_PROXY_CDD_URL

Web address of Continuous Delivery Director SaaS. Value: (default) https://cddirector.io

Explanation of parameters for web proxy only:

•

CDD_PLUGINS_PROXY_INTERNET_PROXY_URL

Web address to access organization web proxy.

•

CDD_PLUGINS_PROXY_INTERNET_PROXY_USERNAME

(Optional) Username to authenticate access to the organization web proxy.

•

CDD_PLUGINS_PROXY_INTERNET_PROXY_PASSWORD

(Optional) The password to authenticate access to the organization's web proxy.

253

Continuous Delivery Director 8.5

After the command executes, the plug-in proxy is enabled and is available for use for on-premise plug-ins.

Location of plug-in proxy log files

The plugins_proxy.log files are created in the logs sub-folder of the cdd user local folder:

/home/cdd/.cdd/logs/

plugins_proxy.log

plugins_proxy_out.log

NEXT STEP

Validate Plug-in Proxy Status

In Continuous Delivery Director, you can check the plug-in proxy status. Click the cross-project cogwheel icon

then Plug-in Proxy. You can also review logs for the status.

After you enable the plug-in proxy, you can register on-premise plug-ins (that run behind a firewall) to use that proxy in

Continuous Delivery Director.

1. Click Administration, then Plug-ins.

2. Click Register Plug-in.

3. Specify the plug-in manifest URL.

https://<whitelist-plugin-server>:<port>/cdd-<plugin-name>-plugin/manifest.json. For

example, https://cdd-plugin-server:8443/cdd-github-plugin/manifest.json.

NOTE

You can use either the hostname or the IP address of the plug-in server.

4. In Select Proxy, choose the required proxy from the dropdown list.

5. Click Register.

The plug-in is discovered and registered and appears in the Plug-Ins page.

Configure Plug-in Proxy Properties

You can edit settings.properties to support multiple plug-in proxies.

Except where indicated, the following content is relevant for both on-premise and SaaS Continuous Delivery Director

instances.

•

To enable plug-in proxies, in settings.properties (/home/cdd/.cdd/conf/settings.properties), ensure

that the following line is set to true :

cdd.pop.enabled = true

NOTE

Only relevant for on-premise.

•

To specify an optional unique ID of the plug-in proxy instance either in setttings.properties or in environment

variables:

•

In settings.properties: cdd.plugins_proxy.id = {proxy ID}

•

In environment variables: CDD_PLUGINS_PROXY_ID

254

Continuous Delivery Director 8.5

NOTE

A proxy ID is limited to 200 characters which can include alphanumeric characters, hyphens, dots, and

underscores.

•

To define heartbeat intervals that indicate normal operation, edit the following line in settings.properties:

cdd.plugins_proxy.cdd.heartbeat_interval_in_millis = {number of milliseconds}

•

To enable/disable message services for plug-in proxies such as Kafka or RabbitMQ, edit the following line in

settings.properties:

cdd.plugins_proxy.message_queue.enabled =

NOTE

Only relevant for on-premise.

cdd.plugins_proxy.id=Dev

cdd.plugins_proxy.cdd.heartbeat_interval_in_millis = 30000

cdd.plugins_proxy.message_queue.enabled = false

Manage Plug-in Proxies

You manage plug-in proxies in the Plug-in Proxies page. This page lists proxy details including connectivity status and

lets you edit, enable/disable, and delete proxies.

PREREQUISITE

To manage plug-in proxies, you need the Can manage plug-in proxy permission.

Edit a Plug-in Proxy

1. Click the cross-project settings icon, then Plug-in Proxy.

2. In the Plug-in Proxies page, either select a name in a table row or click the actions menu on the right of a table row

and choose Edit.

3. Configure and set values for the following parameters:

•

Display Name in UI

Specify the plug-in proxy name to be shown in the user interface. If left empty, the proxy ID is shown.

•

Choose which IP addresses can connect

Determine whether only whitelisted or all IP addresses are allowed to connect to the plug-in proxy.

•

IP Addresses

Specify the IP addresses that can connect to the plug-in proxy. Ex. 192.19.250.253. You can enter IP addresses

manually when the whitelist option is disabled. Any IP addresses through which you have connected will be listed.

If the whitelist option is enabled, only whitelisted IP addresses will be listed.

255

Continuous Delivery Director 8.5

4. Click Save.

Enable/Disable a Plug-in Proxy

1. Click the cross-project settings icon, then Plug-in Proxy.

2. In the Plug-in Proxies page, click the actions menu on the right of a table row and choose Enable/Disable.

Delete a Plug-in Proxy

1. Click the cross-project settings icon, then Plug-in Proxy.

2. In the Plug-in Proxies page, click the actions menu on the right of a table row and choose Delete.

Containerized Plug-ins

Continuous Delivery Director provides some integrations as container images, referred to as containerized plug-ins. These

plug-ins automate the configuration of integrated environments.

Containerized plug-ins are based on Integration-as-a-Service, which is a cloud service delivery model for integration.

These plug-ins deliver an integration solution that can greatly reduce the time involved in setting up third-party clients

and servers as part of your continuous delivery pipeline. This solution allows release managers to quickly put together

integration flows and implement orchestrations, thereby accelerating development time.

Containerized plug-ins are docker images, stored in a registry that is either private or public on a repository, such as

Artifactory. You can also pull the containerized plug-in images from the Broadcom Customer Support Portal.

A single containerized plug-in can be deployed as multiple identical containers on multiple container management

platforms.

Containerized plug-ins are comprised of system libraries, system tools, and other platform settings a third-party service

provider needs to run on container management platforms.

Continuous Delivery Director has developed a tool, the Containerized Plug-in Manager, that enables you to work with

the following container management platforms:

•

Docker Engine. For more information, see Run Containerized Plug-ins using Docker Engine.

•

Kubernetes. For more information, see Run Containerized Plug-ins using Kubernetes.

Continuous Delivery Director provides the following containerized plug-ins:

•

Checkmarx Plug-in

•

Cucumber JVM Plug-in

•

Cucumber for Ruby Plug-in

•

Gradle Testing Plug-in

•

Helm Plug-in

•

Karate Plug-in

•

Maven Testing Plug-in

•

Playwright Plug-in

•

pytest Plug-in

•

Red Hat Ansible Plug-in

•

Robot Framework Plug-in

•

Salesforce Plug-in

•

SoapUI Plug-in

•

TestCafe Plug-in

256

Continuous Delivery Director 8.5

Containerized Plug-in Manager

To use containerized plug-ins in Continuous Delivery Director, install the Containerized Plug-in Manager.

Version 2.9.2

Containerized plug-ins are comprised of system libraries, system tools, and other platform settings a third-party service

provider needs to run on container management platforms.

Continuous Delivery Director has developed a tool, the Containerized Plug-in Manager, that enables you to work with

the following container management platforms:

•

Docker Engine. For more information, see Run Containerized Plug-ins using Docker Engine.

•

Kubernetes. For more information, see Run Containerized Plug-ins using Kubernetes.

Download Options

Use one of the following options to download the latest containerized plug-in manager version:

Method Info

wget wget -O containerized.war https://

cspdl.broadcom.com/shared/static/

emqgzflvrt0oogpinucfhtqjayr78lgk.war?

LCK=ent.box.com

MD5 d49d141dacc2a9fe22b4aa953656258f

Click Download Button

Change History

The following update was made for version 2.9.2:

•

Add Security Source Capabilities to the containerized Plugin.

The following update was made for version 2.9.1:

•

Bugfix - Blackduck fixes.

The following update was made for version 2.9:

•

Added support to show the execution logs in the run-time even the containerized plug-in is connected using a proxy.

The following update was made for version 2.6:

•

Gradle properties were updated.

The following update was made for version 2.5:

•

When settings are changed and saved, settings.properties is automatically updated during runtime without the

need to restart the service.

The following updates were made for version 2.4:

•

The tenant ID was updated.

The following updates were made for version 2.3:

257

Continuous Delivery Director 8.5

•

Bugfix - Cucumber JVM test suite import failed on SaaS.

•

Bugfix - the containerized plug-in manager does not map volumes in connectivity tests.

The following updates were made for version 2.2:

•

The Fabric8 software component used by the containerized plug-in manager has been upgraded to version 5.1.1.

•

The containerized plug-in manager lets you run Continuous Delivery Director docker-based plugins on Kubernetes

(and not just on Docker engine).

•

You can configure settings.properties to support multiple container management platforms.

•

Bugfix: The containerized plug-in log files were overwritten in a multi-node active-active high-availability cluster setup.

Set Up Multiple Containerized Plug-in Managers

You can configure settings.properties to support multiple container management platforms.

You can use multiple container management platforms to run containerized plug-ins (for example, either for multiple

Docker Engines, or for Docker Engine and Kubernetes). To support this scenario, you set up a containerized manager

instance for each container management platform. You can configure settings.properties with multiple

containerized plug-in manager settings.

You must set the CDD_CONTAINERIZED_ID environment variable to specify the unique ID of each containerized manager

instance per container management platform instance. Each containerized manager instance must run using a unique

value of the CDD_CONTAINERIZED_ID environment variable. The value of the CDD_CONTAINERIZED_ID environment

variable is free text.

You can update the settings.properties file and add the concrete value of {cdd-containerized-id} right after

the cdd.plugins.containerized. prefix.

If the {cdd-containerized-id} prefix is not found, the plug-in reverts to the same property name without the {cdd-

containerized-id} prefix.

You have a Docker Engine platform and a Kubernetes platform. You need two containerized manager

instances, one instance with CDD_CONTAINERIZED_ID set to 1, and the other instance with

CDD_CONTAINERIZED_ID set to 2. Your settings.properties file includes the following lines:

cdd.plugins.containerized.1.platform_provider=docker

cdd.plugins.containerized.2.platform_provider=kubernetes

Your settings.properties file includes the following sections:

settings.properties

==================================

cdd.plugins.containerized.{cdd-containerized-id-1}.platform_provider=docker

cdd.plugins.containerized.{cdd-containerized-id-1}.container_engine.home_folder_base_url=http://

cdddev001234.mpc.mycompany.net

cdd.plugins.containerized.{cdd-containerized-id-1}.container_engine.home_folder=/home/cdd/.cdd

cdd.plugins.containerized.{cdd-containerized-id-1}.container_engine.host=http://

cdddev001234.mpc.mycompany.net

cdd.plugins.containerized.{cdd-containerized-id-1}.container_engine.port=4550

cdd.plugins.containerized.{cdd-containerized-id-2}.platform_provider=kubernetes

cdd.plugins.containerized.{cdd-containerized-id-2}.cluster.namespace=

cdd.plugins.containerized.{cdd-containerized-id-2}.cluster.username=

cdd.plugins.containerized.{cdd-containerized-id-2}.cluster.password=

cdd.plugins.containerized.{cdd-containerized-id-2}.cluster.server_url=

cdd.plugins.containerized.{cdd-containerized-id-2}.cluster.persistence_volume_claim_name=

258

Continuous Delivery Director 8.5

cdd.plugins.containerized.{cdd-containerized-id-2}.cluster.access_token=

cdd.plugins.containerized.{cdd-containerized-id-1}[email protected]

cdd.plugins.containerized.{cdd-containerized-id-1}.registry.password=Cdd1234$

cdd.plugins.containerized.{cdd-containerized-id-1}.registry.url=docker-release-candidate-

local.artifactory-xyz.broadcom.net

cdd.plugins.containerized.{cdd-containerized-id-1}.registry.username=bld_cdd_build

cdd.plugins.containerized.{cdd-containerized-id-1}.container.volumes.artifacts=/home/cdd/.cdd/

artifacts

cdd.plugins.containerized.{cdd-containerized-id-2}.cucumberjvm.container.image_name=docker-release-

candidate-local.artifactory-xyz.mycompany.net/com/cdd/trunk/8.0/plugins/cucumberjvm\:15

cdd.plugins.containerized.{cdd-containerized-id-2}.cucumberjvm.container.volumes.artifacts=/home/

cdd/.cdd/artifacts

cdd.plugins.containerized.{cdd-containerized-

id-2}.cucumberjvm.container.volumes.artifacts.volumes=dependencies\:/home/cdd/.m2

cdd.plugins.containerized.{cdd-containerized-id-2}.cucumberjvm.container.volumes.logs=/home/

cdd/.cdd/logs

You also have multiple instances of the same container management platform type, docker. Your

settings.properties file includes the following lines:

cdd.plugins.containerized.1.platform_provider=docker

cdd.plugins.containerized.2.platform_provider=docker

Set Up Containerized Plug-ins

•

You have a working knowledge of Docker.

•

An Apache Tomcat 8.5 server is installed with the containerized-manager plug-in deployed.

•

The Tomcat server is owned and run by an OS user whose UID/GID are 1010/1010 .

The Continuous Delivery Director solution includes a number of plug-ins that are packaged as Docker container images.

These containerized plug-ins support the Adapting Testing functionality.

1. Download and load the plug-in Docker image, using one of the following methods:

•

NOTE

Use this option if you are unable to use docker pull

From the command line, enter the wget command listed in the Download Options section in the plug-in

documentation. For example, Maven Testing Plug-in.

wget -O cdd-maventesting-plugin-v1.5b124.tar.gz https://cspdl.broadcom.com/shared/

static/xu6uvenjk1bfml7jbrw38p9tpq8nu065.gz?LCK=ent.box.com

Enter:

docker load -i <the gz file name>

•

Connect to https://support.broadcom.com/enterprise-software/download-center.

Select either Continuous Delivery Director or Continuous Delivery Director SaaS and click the Docker button.

Follow the on-screen instructions to pull the image to your localhost.

2. Set up a shared mounted filesystem or create the following folder structure:

NOTE

Skip this step if the setup already exists.

259

Continuous Delivery Director 8.5

mkdir /home/cdd/.cdd

mkdir /home/cdd/.cdd/logs

mkdir /home/cdd/.cdd/conf

mkdir /home/cdd/.cdd/artifacts

mkdir /home/cdd/.cdd/certificates

3. Create a settings.properties file under /home/cdd/.cdd/conf/, and add the following lines:

NOTE

Skip this step if the setup already exists.

cdd.plugins.containerized.container.volumes.artifacts=/home/cdd/.cdd/artifacts

cdd.plugins.containerized.container.volumes.logs=/home/cdd/.cdd/logs

cdd.plugins.containerized.container.volumes.certificates=/home/cdd/.cdd/certificates

#Container (Docker) Engine

cdd.plugins.containerized.container_engine.host=localhost

cdd.plugins.containerized.container_engine.port=4550

cdd.plugins.containerized.container_engine.home_folder=/home/cdd/.cdd

cdd.plugins.containerized.home_folder=/home/cdd/.cdd

#Registry

cdd.plugins.containerized.registry.url=

cdd.plugins.containerized.registry.username=

cdd.plugins.containerized.registry.password=

cdd.plugins.containerized.registry.email=

4. In settings.properties, add a line such as the following:

cdd.plugins.containerized.<plug-in name>.container.image_name=<repository>:<tag>

IMPORTANT

Replace plug-in name with the required plug-in name, such as maven . You must update this line every

time you update the relevant plug-in.

5. Restart the containerized-manager service.

cd /opt/apache-tomcat-<tomcat version>/webapps

rm -rf containerized

ls -ltr

6. Register the new plug-in using the following manifest URL: http://<plugin-server>:<port>/

containerized/plugins/cdd-<name of plug-in>-plugin/manifest.json.

Run Containerized Plug-ins using Docker Engine

Learn how to set up containerized plug-ins to work in Continuous Delivery Director using Docker Engine.

260

Continuous Delivery Director 8.5

•

A home folder is set up and includes containerized folders. For more information, see Configure the Home Folder.

•

A Docker Engine machine is provisioned, preferably running Red Hat Linux 7.4.

•

For Continuous Delivery Director SaaS users, a plug-in proxy is defined so that the Docker Engine machine is included

in the approved list. For more information, see Plug-in Proxies.

•

The containerized manager war file and a containerized plug-in tar file (which holds the required docker images) have

been downloaded to the Docker Engine machine.

NOTE

Enhanced Security

Optional. To restrict the access to the Docker remote API port to allow localhost origin only, follow all the steps in

the following Enhanced Security notes.

1. Enable access to Docker containers and images.

a) From the command line, as a root user, create a user with the name cdd and the uid 1010 , and a group with the

name cdd and the gid 1010 on the Docker Engine machine. Add the user cdd to the existing docker group

to allow this user to run Docker images. This step enables the Docker container to read and write the required

settings and logs to a persistent volume on the Docker Engine machine:

groupadd 1010 -g 1010 cdduseradd 1010 -u 1010 -g 1010 -G docker cdd

NOTE

The purpose of the cdd user and cdd group is to limit read-write permissions between the host machine

and the Docker containers to authorized users only.

All cdd services are run on behalf of the cdd OS user. All Continuous Delivery Director artifacts are

stored in the cdd home folder using cdd user access permissions.

b) Set a password for the cdd user:

passwd cdd {provide a password}

2. Enable access to the Docker remote API port for communication between the containerized plug-in and the Docker

Engine:

a) Create the docker.service.d directory:

mkdir /etc/systemd/system/docker.service.d

b) Create the docker-external.conf configuration file:

vi /etc/systemd/system/docker.service.d/docker-external.conf

c) Add the following content to the docker-external.conf file:

[Service] ExecStart=ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:4550 -H unix:///var/run/docker.sock

NOTE

Enhanced Security

Replace 0.0.0.0 with 127.0.0.1 or with the server name of the Docker Engine machine.

d) Reload and restart the Docker daemon:

systemctl daemon-reload systemctl restart docker

a) Connect as the cdd user:

su - cdd

b) Prepare the docker images:

NOTE

In the following command, replace:

261

Continuous Delivery Director 8.5

{path-to-local-containerized-plug-in-tar-file}

with the download location of the docker images on the Docker Engine machine.

docker load -i {path-to-local-containerized-plug-in-tar-file}

4. Create a settings.properties file with the following content and place this file under the /home/cdd/.cdd/

conf folder:

NOTE

In the following code block, make sure you provide a value for the

cdd.plugins.containerized.container_engine.host parameter.

NOTE

Enhanced Security

When you configured the docker-external.conf file in a previous step, if you replaced 0.0.0.0 with another

value for enhanced security in the following line:

ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:4550 -H unix:///var/run/docker.sock

Set the cdd.plugins.containerized.container_engine.host parameter to the same value, for

example, 127.0.0.1.

#Provider

cdd.plugins.containerized.platform_provider=docker

#Container Template

cdd.plugins.containerized.container.port=8080

cdd.plugins.containerized.container.user_id=1010

cdd.plugins.containerized.container.group_id=1010

cdd.plugins.containerized.container.volumes.logs=/home/1010/.cdd/logs

#Container Readiness

cdd.plugins.containerized.container_readiness.check_intervals=25

cdd.plugins.containerized.container_readiness.check_interval_duration_ms=1000

#Container (Docker) Engine

cdd.plugins.containerized.container_engine.host=

cdd.plugins.containerized.container_engine.port=4550

cdd.plugins.containerized.container_engine.home_folder=/home/1010/.cdd

#Registry

cdd.plugins.containerized.registry.url=cdd.packages.ca.com

cdd.plugins.containerized.registry.password=

cdd.plugins.containerized.registry.username=

cdd.plugins.containerized.registry.email=

#Container

cdd.plugins.containerized.ansiblecore.container.image_name=isl-dsdc.ca.com:5000/com/ca/cdd/

trunk/7.2/ plugins/ansiblecore:82

cdd.plugins.containerized.ansiblecore.container.port=8080

cdd.plugins.containerized.ansiblecore.container.name_prefix=ac

262

Continuous Delivery Director 8.5

5. Verify that the docker-engine hostname was added. Run the following command:

NOTE

In the following command, replace {hostname} with the Docker Engine machine name or IP address.

more /home/cdd/.cdd/conf/settings.properties | grep {hostname}

6. Optionally, run the containerized manager as a docker container. Alternatively, you can run the containerized manager

as a standard Tomcat war file. If you choose to run the containerized manager as a docker container, from the

command prompt enter the following:

NOTE

Enhanced Security

Run the containerized plug-in using the network of the Docker Engine host (add --network=host to the

following docker run command).

Running the containerized plug-in using the network of the Docker Engine host may create a port conflict

between the docker container and the Docker Engine machine ('Address in use' error message). In this case,

do not use port 8080 as the Tomcat port of the containerized plugin. Instead, in the following command,

replace {port} with an available port on the Docker Engine machine.

docker run --name containerized-plugin --network=host -e CONNECTOR_PORT={port} -e

SECURITY_FLAG=false -e CDD_HOME_FOLDER=/home/cdd/.cdd -v /home/cdd/.cdd:/home/cdd/.cdd -d isl-

dsdc.ca.com:5000/com/ca/cdd/trunk/7.0/plugins/containerized:31

7. Register the containerized plug-in.

For more information, see Manage Plug-ins.

NOTE

In the following command, replace {hostname} with the server or IP address of the machine running the

containerized plug-in and replace {port} with the external Tomcat port of the containerized plug-in.

http://{hostname}:{port}/containerized/plugins/cdd-{name of containerized plugin}-plugin/manifest.json

http://10.121.64.90:8080/containerized/plugins/cdd-ansiblecore-plugin/manifest.json

Run Containerized Plug-ins using Kubernetes

Learn how to set up containerized plug-ins to work in Continuous Delivery Director using Kubernetes.

•

A cdd home folder is set up and includes containerized folders. For more information, see Configure the Home Folder

•

You are familiar with Kubernetes and the concepts of Persistent Volume and Persistent Volume Claim. For more

information, see Kubernetes documentation.

•

For Continuous Delivery Director SaaS users, the plug-in proxy is defined so that the Kubernetes machine is included

in the approved list. For more information, see Plug-in Proxy.

•

The containerized manager war file has been downloaded to the Kubernetes machine.

•

A containerized plug-in tar file which holds the required docker images has been downloaded to the Kubernetes

machine.

1. Create a namespace with the name cdd . From the command prompt:

kubectl create ns cdd

2. Create a persistent volume for the cdd home folder (/home/cdd/.cdd):

kubectl create -f PersistentVolume.yaml

263

Continuous Delivery Director 8.5

3. Add the following content to PersistentVolume.yaml.

apiVersion: v1

kind: PersistentVolume

metadata:

labels:

spec:

capacity:

storage: 2Gi

accessModes:

- ReadWriteMany

storageClassName: hostpath

persistentVolumeReclaimPolicy: Retain

hostPath:

path: /home/cdd/.cdd

type: DirectoryOrCreate

4. Create a persistent volume claim at the cdd namespace:

kubectl create -n cdd -f PersistentVolumeClaim.yaml

5. Add the following content to PersistentVolumeClaim.yaml.

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

namespace: cdd

spec:

selector:

matchLabels:

accessModes:

- ReadWriteMany

storageClassName: hostpath

resources:

requests:

storage: 1Gi

volumeName: cdd

6. Create a settings.properties file with the following content and place this file under the /home/cdd/.cdd/

conf folder:

#Provider

cdd.plugins.containerized.platform_provider=kubernetes

#Cluster

cdd.plugins.containerized.cluster.namespace=

cdd.plugins.containerized.cluster.username=

cdd.plugins.containerized.cluster.password=

cdd.plugins.containerized.cluster.server_url=

cdd.plugins.containerized.cluster.persistence_volume_claim_name=

cdd.plugins.containerized.cluster.access_token=

264

Continuous Delivery Director 8.5

7. Register the containerized plug-in. For more information, see Manage Plug-ins.

NOTE

In the following command, replace {hostname} with the server or IP address of the machine running the

containerized plug-in and replace {port} with the external Tomcat port of the containerized plug-in.

http://{hostname}:{port}/containerized/plugins/cdd-{name of plugin}-plugin/manifest.json

http://10.121.64.90:8080/containerized/plugins/cdd-ansiblecore-plugin/manifest.json

Plug-ins

View information about the available plug-ins.

Plug-ins enable users of third-party solutions to execute Continuous Delivery Director processes and deployments from

within the specific solution.

Plug-in Versioning

Plug-in version numbers are incremented if there is a change to the plug-in input/output parameters or a major

functionality change. For bug fixes or minor changes, the plug-in minor version number is updated. Version and minor

version numbers appear on the Plug-ins page for each plug-in. If there is no minor version in the plug-in manifest, the

minor version does not appear.

If you import a DSL file containing a plug-in reference, the file import fails in the event of a regular plug-in version

mismatch. However, the import does not fail if there is only a minor version mismatch.

On the user interface, the numbering syntax for plug-in versions is <plug-in version>-<minor version>. For example, if

the version is 3.5 and the minor version is 2, the plug-in version is displayed as "3.5-2". If there is no minor version, the

hyphen and the minor version are not displayed.

In a DSL file, the numbering syntax for minor versions is <plug-in version>/<minor version>. For example:

{

"kind": "TestSource",

"plugin": "Robot Framework/1.2/7",

Available Plug-ins

Continuous Delivery Director provides the following plug-ins that are packaged and installable out-of-the-box:

[A] [B] [C] [D] [E] [F] [G] [H] [J] [K] [L] [M] [N] [P] [R] [S] [T] [V]

•

Atlassian Bitbucket

•

Atlassian JIRA

•

Apache Tomcat

•

Automic

Continuous Delivery Automation

•

AWS CodeDeploy

•

AWS Elastic Beanstalk

•

Azure DevOps Server (formerly Microsoft Team Foundation Server)

265

Continuous Delivery Director 8.5

•

BlazeMeter

•

Burp Suite

•

Checkmarx

•

Coverity

•

Cucumber JVM

•

Cucumber for Ruby

•

Docker

•

DX App Experience Analytics

•

DX App Synthetic Monitor Plug-in

•

Endevor SCM

•

Flowdock

•

GitHub

•

GitLab

•

Gradle Testing

•

Helm Plug-in

•

Jenkins

•

JFrog Artifactory

•

Karate

•

Kubernetes

•

Liquibase

266

Continuous Delivery Director 8.5

•

Manual Deployment

•

Maven Testing

•

Micro Focus ALM

•

Micro Focus LoadRunner Enterprise

•

Microsoft Teams

•

Nolio Release Automation

•

Playwright

•

Postman

•

pytest

•

Rally

(formerly CA Agile Central)

•

Red Hat Ansible

•

Red Hat Ansible Tower

•

Red Hat OpenShift

•

REST

•

Robot Framework

•

Runscope

•

Salesforce

•

ServiceNow

•

Slack

•

Soap UI

•

SonarQube

•

Sonatype Nexus Lifecycle

•

Terraform

•

TestCafe

•

Test Data Manager

•

Twistlock

•

Veracode

Each plug-in has unique characteristics, including:

267

Continuous Delivery Director 8.5

•

Required information for endpoint connections

•

Required security for endpoint connections

•

Task types

•

Import capabilities

•

Task input values

This section provides detailed content for each packaged plug-in to help you use its capabilities in your releases.

Apache Tomcat Plug-in

Use this plug-in to deploy WAR files stored in a Maven repository to Tomcat using the Tomcat Web Application Manager.

Plug-in Version 1.5-2

This plug-in helps you to automatically deploy a built war file to a Tomcat instance. Both Artifactory and Nexus type

repositories are supported.

Supported Versions

This plug-in supports Apache Tomcat 8.x.

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-tomcat-plugin.war https://

cspdl.broadcom.com/shared/static/

e2shgys90lw0bahngnxcq9fs37h4azr0.war?

LCK=ent.box.com

MD5 4869c5ce1068ceec13a1fd13b844b592

Click Download Button

Change History

The following updates were made for plug-in version 1.5-1:

•

Bugfix: When a plug-in task failed to retrieve a Maven artifact, an unclear NullPointerException error message

displayed on the CDD user interface. This message was replaced with a clearer message that includes the expected

path to the missing Maven artifact.

The following updates were made for plug-in version 1.4:

•

Bugfix: Tomcat plug-in uses the snapshot version of the pom record instead of the snapshot version of the artifact

record.

The following updates were made for plug-in version 1.3:

•

A new output parameter in the Deploy Artifact task, Artifact URL, returns a clickable URL to the deployed artifact.

268

Continuous Delivery Director 8.5

Configuration

The URL of the Tomcat manifest for plug-in registration is http://<plugin-server>:<port>/cdd-tomcat-plugin/manifest.json.

Select the Tomcat plug-in in the ADD ENDPOINT dialog to create an endpoint for the Tomcat plug-in. The following

Tomcat information is required wtomhen you create an endpoint:

•

Tomcat URL

Enter the Tomcat URL with the target location for the deployed artifact.

Syntax: http://${tomcat-server}:${port}

NOTE

The URL can be specified as http or https

•

Tomcat Username

Specify a user name to authenticate to Tomcat.

•

Tomcat Password

Specify a password to authenticate to Tomcat.

•

Maven Repository URL

Enter the required Maven repository URL. This is the base URL prefix of the remote artifact repository. For example,

http://artifactory.acme.net/artifactory or https://repository.apache.org.

NOTE

An Artifactory URL must end with: [/artifactory]. A Nexus URL must end with: [/repository].

•

Repository Name

Specify the name of the Maven repository where the project artifacts are stored, for example, maven-repository.

•

Maven Repository Credentials

Specify the authentication method for the Maven repository, either Basic or Bearer.

•

Basic

–

Maven Repository Username

Specify the username to authenticate to the Maven repository.

–

Maven Repository Password

Specify the password to authenticate to the Maven repository.

•

Bearer

–

Maven Repository Access Token

Specify the Maven repository access token

Deploy Artifact

This task helps you to deploy a Maven artifact in WAR format to a Tomcat container.

Configure the following input parameters:

•

Tomcat Context Path

Specify the context path part of the URL under which your application will be published in Tomcat, with or without a

preceding slash [/]. For example: [tomcatPluginApp] or [/tomcatPluginApp].

•

Build Number

Specify the build number to be deployed.

•

Artifact Package Group Name

Specify the package group of the repository.

•

Artifact Package Name

Specify the artifact name.

•

Artifact File Path

269

Continuous Delivery Director 8.5

Specify the path to the folder location where the artifact is stored.

•

Artifact Classifier

Specify the artifact classifier.

•

Request Timeout in Seconds

Specify the request timeout for each operation: download and upload.

Output Parameters

•

Artifact URL

Returns the full URL of the specified artifact, either release or snapshot. You can use this URL in the phase or release.

Atlassian Bitbucket Plug-in

This plug-in lets you use Bitbucket as your source control system to retrieve commit messages so you can track planned

vs actual work.

Plug-in Version 2.3-3

This plug-in also lets you use Bitbucket as your file source, a connection to a JSON format representation of a

release. Additionally, you can also use file sources to manage JSON files that reference other JSON files.

IMPORTANT

Only on-premise Bitbucket instances are supported by this plug-in.

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-bitbucket-plugin.war https://

cspdl.broadcom.com/shared/static/

tpkp2jjdp4srqhfbwqdgwbjatgzzujvk.war?

LCK=ent.box.com

MD5 943e7a6781d3b365f0eb1aec3930ce8a

Click Download Button

Change History

The following updates were made for plug-in version 2.3-3:

•

Security enhancements.

The following updates were made for plug-in version 2.3-2:

•

Security enhancements.

The following updates were made for plug-in version 2.3-1:

•

Support was added for Bitbucket webhook 7.6. This change allows customers to use BitBucket Data Center 7.6.

The following updates were made for plug-in version 2.3:

•

Assorted bug fixes.

270

Continuous Delivery Director 8.5

The following updates were made for plug-in version 2.2:

•

A new Trust Any SSL Certificate endpoint parameter lets you allow untrusted and unsigned SSL/TLS certificates.

The following updates were made for plug-in version 2.1:

•

A new optional endpoint parameter, Project Key, was added.

The following updates were made for plug-in version 2.0:

•

You can now use Bitbucket as your source control system to retrieve commit messages so you can track planned

vs actual work. To support this change, a Bitbucket Get Commit Messages task is now available in the Set Source

Control Connection page.

The following updates were made for plug-in version 1.1:

•

Support was added for Java 11.

Configuration

The URL of the Bitbucket manifest for plug-in registration is http://<plugin-server>:<port>/cdd-bitbucket-plugin/

manifest.json.

Select the Bitbucket plug-in in the ADD ENDPOINT dialog to create an endpoint for the Bitbucket plug-in. The following

Bitbucket information is required when you create an endpoint:

•

Bitbucket API URL

Enter the URL of the remote Bitbucket instance to be used for connection purposes.

Example: https://myBitbucket.mycompany.com:7990

Note: The URL can be specified as http or https

•

Username

Specify a user name to authenticate to Bitbucket.

•

Password

Specify a password to authenticate to Bitbucket.

•

Project Key

Specify the project key of the Bitbucket repository.

•

Trust Any SSL Certificate

Select this option if you want to allow untrusted and unsigned SSL/TLS certificates.

Get Commit Messages

The Bitbucket plug-in lets you retrieve and parse commit messages. Use this capability when you deploy applications in a

release to see the status of related work items.

Optionally, you can configure paths to include and exclude files from the list of changed files that are part of test coverage

metrics. For example, you might not want your tests (written in Java) to be counted as files that are not covered.

Follow these steps:

1. In a release, expand the Apps & Work Items tree on the left menu, and select the version number.

2. Select Set Source Control Connection.

Note: This option is only enabled if a work item source, such as Rally

, has been configured.

3. Configure the following parameters, then select Set:

271

Continuous Delivery Director 8.5

–

Source Control - Select Bitbucket and Get Commit Messages.

–

Select Endpoint - Select a Bitbucket endpoint.

–

Project Key - Specify the project key of the Bitbucket repository.

–

Repository - Specify the source control repository to bring the commit messages from. This should be the

repository that corresponds with the project in the build server that you configure to send notifications to this

application version.

Example: https://myBitbucket.mycompany.com/[organization]/[Repository]

–

Regular Expression - (Optional) Specify a regular expression with which to parse the commit comments for work

item IDs.

–

Include Path - (Optional) Specify one or more paths to map the packages and/or classes to include in test

coverage.

Syntax: app/src/java/**

–

Exclude Path - (Optional) Specify one or more paths to map the packages and/or classes to exclude from test

coverage.

Syntax: app/src/tests/**

When the source control connection is configured, the plug-in returns a list of commit IDs with the following information:

•

The commit message

•

The user who made the commit (author)

•

The files that have been changed

•

The time of the commit

NOTE

The list of commit IDs is not visible in the user interface.

Get Files

The Bitbucket plug-in lets you use Bitbucket as a file source so that releases are automatically created and run whenever

you make changes to the JSON file.

NOTE

To use this capability, first create a top-level folder in the relevant repository with the following name: CDD-

FileSource. Place all release-related JSON files in this folder.

NOTE

The CDD-FileSource folder does not apply if you use file sources to manage JSON files that reference other

JSON files.

Follow these steps:

1. From RELEASES, select New File Source.

2. In CREATE FILE SOURCE, configure the following parameters, then select Create:

–

Name - Specify a name for the file source.

–

Select Source Control - Select BITBUCKET and Get Files.

–

Project Key - Specify the project key of the Bitbucket repository.

–

Repository - Specify the name of the Bitbucket repository to bring the files from.

–

Branch - Specify the branch name.

–

Releases Created On Behalf Of (API Key) - Specify the API key of a user on whose behalf future releases will be

created.

Example: The API key of the product owner.

–

Send Error Notifications To - Specify one or more recipients to receive error notifications.

272

Continuous Delivery Director 8.5

3. Save your changes. A COPY WEBHOOK popup is displayed containing an auto-generated webhook. This webhook

supports the connection between Continuous Delivery Directorand Bitbucket. Copy this webhook and paste it into

Bitbucket.

The newly-created file source is added to the FILE SOURCES page.

NOTE

More Information

•

How to Set Up Webhooks in your Source Control

Atlassian Jira Plug-in

This plug-in integrates with the issue tracking and project management capabilities that Jira provides.

Plug-in Version 2.4-15

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-jira-plugin.war

https://cspdl.broadcom.com/shared/

static/4xillp8ttzg8wg0eubfta0d8c2432xmg.war?

LCK=ent.box.com

MD5 bb03d0e4d58f953d1267daaaa9fbcd82

Click Download Button

Supported Versions

The Jira plug-in has been validated for the following Jira versions:

•

8.13x

NOTE

This plugin is compatible only with the Jira Server due to changes in the Jira Cloud REST Client compatibility.

Capabilities

The Jira plug-in lets you perform the following tasks:

•

Add Jira Issue Comments

•

Create Jira Issue

•

Get Jira Issue

•

Update Jira Issue Status

•

Wait for Approval

•

Import Work Items

•

Get Test Assets

273

Continuous Delivery Director 8.5

Change History

The following update was made for plug-in version 2.4-15:

•

Security enhancements.

The following update was made for plug-in version 2.4-14:

•

You can configure output parameters in the plug-in settings.properties file, store the information retrieved in tokens,

and reuse those details in other release tasks.

•

Support was added for the Bearer Authentication using Jira Personal Access Token.

•

Bugfix: After the authentication changes Jira plugin is not backward compatible.

The following update was made for plug-in version 2.4-13:

•

You can now use personal access tokens to authenticate to Jira in the endpoint configuration.

The following update was made for plug-in version 2.4-12:

•

Security enhancements.

The following update was made for plug-in version 2.4-10:

•

The plug-in was modified to support the retrieval of detailed Jira issue data.

The following update was made for plug-in version 2.4-9:

•

Bugfix: Invalid external work item IDs set on test suites adversely affected work item coverage reporting.

The following update was made for plug-in version 2.4-8:

•

The work item IDs of tests are now stored with the tests.

The following update was made for plug-in version 2.4-7:

•

The Test Execution Key parameter in the Get Test Assets task was moved to the Execution Parameters section.

The following update was made for plug-in version 2.4-6:

•

Support was added for integration testing.

The following update was made for plug-in version 2.4-5:

•

The Test Plan Key and Test Execution Key parameters in the Get Test Assets task now support dynamic values

import from Xray.

The following update was made for plug-in version 2.4-4:

•

A new Trust Any SSL Certificate endpoint parameter lets you allow untrusted and unsigned SSL/TLS certificates.

The following update was made for plug-in version 2.4-3:

•

A Test Execution Key parameter was added to the Import Tests task.

The following updates were made for plug-in version 2.4-2:

•

Support was added for the Xray Test Management for the Jira application. This enhancement lets you import test

issues as test suites into Continuous Delivery Director.

•

Log rotation was added. A new log is opened daily (regardless of file size) and the system stores up to 10 logs,

providing 10 days log history.

The following updates was made for plug-in version 2.4-1:

•

Bugfix: No value was returned if no work items were found matching a commit.

The following updates was made for plug-in version 2.4:

274

Continuous Delivery Director 8.5

•

You can now retrieve child issues together with parent issues in one API call if an embed parameter is present in the

request. Previously, you could only retrieve parent and child issues in separate API calls. Additionally, the getContent

API call is now asynchronous; previously, this API call was synchronized.

The following updates was made for plug-in version 2.3:

•

The following issue was resolved: Import Content Items failed with an IO Exception: Too many open files error. This

error was due to the number of open file descriptors exceeding the maximum number of open files permitted.

The following update was made for plug-in version 1.2.3:

•

Support was added for Java 11.

Configure a Jira Endpoint

Enable communication and synchronization of work items between Jira and Continuous Delivery Director.

You are familiar with Jira.

You have been granted the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

The manifest for the Jira plug-in is http://<host>:<port>/cdd-jira-plugin/manifest.json .

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the Jira plug-in.

4. Configure the following endpoint parameters:

•

URL

Enter the URL of your Jira instance.

•

Authentication Method

Select an authorization method to use to establish the connection to Jira. Values: Basic, Personal Access Token

–

Basic

•

Username

Enter a user name to authenticate to the Jira instance.

•

Password

Enter the password of the specified user to authenticate to the Jira instance.

NOTE

For Jira SaaS, select the Basic authentication method, enter the username, and enter the API key

generated on the Jira account in the password field.

–

Personal Access Token.

•

Personal Access Token

Specify a personal access token created in Jira.

•

Trust Any SSL Certificate

Select this option if you want to allow untrusted and unsigned SSL/TLS certificates.

•

(Optional) Use Proxy

Select this option to connect to Jira through a proxy server.

NOTE

If selected, the Proxy Host, Proxy Port, Proxy Username, Proxy Password, and Use HTTPS fields

appear.

–

Proxy Host

Specifies the HostName or IP for the proxy server.

–

Proxy Port

275

Continuous Delivery Director 8.5

Specifies the port for the proxy server.

–

Proxy Username

Specifies the user name for the proxy server.

–

Proxy Password

Specifies the password for the proxy server.

–

Use HTTPS

Specifies whether the Jira connection uses an SSL connection.

•

Time Out

Specify the number of seconds to wait before the operation is aborted.

5. Click Test Connection to check the connection to Jira.

6. Click Add.

Add Jira Issue Comments

Add comments to issues to record additional details about these issues and to collaborate with your colleagues.

One or more Jira endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Issue Key

Specify the Jira project key that is used for the issue. This is usually the Jira project initials.

•

Comment

Specify a comment to add to the specified Jira issue.

•

Role

Specify the role that can view the comment. Roles belong to project issues. If null, the default value is all roles. If

you select Others, use the Other Role field to define a customized role.

3. Click Create.

Create Jira Issue

Use tasks to automatically create issues in your Jira project from your release pipeline.

276

Continuous Delivery Director 8.5

One or more Jira endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field.

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Jira Project Key

Specify the Jira project key that is related to the issue. This is usually the Jira project initials.

•

Issue Type

Select one of the following issue types that is defined in the project to which the issue belongs:

–

Task

–

Sub-task

–

Story

–

Bug

–

Epic

NOTE

If you select Epic, specify the Epic Name.

•

Epic Name

Specify the associated epic name in the Jira agile boards. This input is only valid when you select Epic in the Issue

Type field.

•

Summary

Specify a summary of the issue.

•

Priority

Specify the priority level of the issue.

•

Due Date

Specify the issue due date in the format YYYY-MM-DD. Example: 2022-9-29

•

Show Advanced Settings

Displays the following additional fields:

–

Affects Versions

Specify an array of affected versions separated by a semicolon. Each element is a version. Jira lets you

track different versions for software projects. You can assign issues to version that are configured in project

administration.

–

Fix Versions

Specify an array of versions separated by a semicolon. Each element is a version. Jira lets you track different

versions for software projects. You can assign issues to version that are configured in project administration.

–

Assignee

Specify the name of the issue assignee. This field defaults to the current logon user. Use the user name used to

–

Reporter

277

Continuous Delivery Director 8.5

Specify the name of the issue reporter. This field defaults to the current logon user. Use the user name used to

–

Environment

Specify environment details relevant to the issue such as operating system, software platform, or hardware

specifications.

–

Description

Specify the Jira issue description.

–

Labels

Specify an array of issue labels separated by a semicolon. Each element is a label. Labels cannot contain

spaces.

–

Custom Fields

Specify a list of custom field names and values. The following Jira custom field types and JSON syntax are

supported:

•

Text Field (single line). Syntax: {"field_name":"textual_value"}

•

Select List (single choice). Syntax: {"field_name":"choice_1"}

•

Checkboxes. Syntax: {"field_name":["check_1.","check_2"]}

•

Cascade field. A cascading select list with two levels of select lists. What you see in the second select list

depends on what you choose in the first select list. Syntax: {"field_name":["Parent Value", "Child

Value"]}. If you want to enter the parent value only, the syntax is {"field_name":["Parent Value",

""]} (that is, no space between the double quotes).

NOTE

If a standard field and a custom field have identical field names, the merged field displays the custom

field value.

Values: You can update multiple values in the following JSON syntax:

{"field1":"value1","field2":"value2"...}

For example: {"Links":"Reporter","Votes":"Watcher","Updated":"Remaining"} .

For Cascade: {"Task Type":["Tests","Run UI Test"]}

Output Parameters

NOTE

You can store the returned values in tokens (except for built-in tokens) for use in other release items.

•

Issue Key

Returns the key of the created issue. Example: AP-51

•

Issue ID

Returns the ID of the created issue.

•

Self Link

Returns the URL of the created issue.

3. Click Create.

Get Jira Issue

Retrieve detailed information about a Jira issue (ticket).

278

Continuous Delivery Director 8.5

One or more Jira endpoints are available.

You can configure output parameters in the plug-in settings.properties file, store the information retrieved in tokens, and

reuse those details in other release tasks.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field.

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Jira Project Key

Specify the Jira project key that is related to the issue. This is usually the Jira project initials.

•

Issue Type

(Optional) Select one of the following issue types that is defined in the project to which the issue belongs:

–

Task

–

Sub-task

–

Story

–

Bug

–

Epic

NOTE

If you select Epic, specify the Epic Name.

•

Issue Key

Specify the key of the Jira issue. Usually, the key has the Jira product initials as a prefix. Example: AP-51

3. Configure the output parameters.

For more information, see Define Output Parameters (Jira).

4. Click Create.

Update Jira Issue Status

Use tasks to automatically change issue statuses in your Jira project from your release pipeline.

One or more Jira endpoints are available.

A transition is a link between two statuses that enables an issue to move from one status to another. For an issue to move

between two statuses, a transition must exist.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field.

279

Continuous Delivery Director 8.5

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Issue Key

Specify the issue key that is used for the Jira issue. This is usually the Jira project key plus a numeric key that is

unique. For example: CDD-2021.

•

Transition I would like to perform

Specify a transition according to your issue workflow. Examples:

–

Resolve Issue

–

Reopen

–

Closed

–

Start Progress

–

Stop Progress

–

Start Work

–

Stop Work

–

Define

–

Restart Work

–

Block

–

Complete

–

Verified

–

Assign

–

To Do

–

In Progress

–

Done

–

Others

•

Resolution

Specifies how the issue is resolved if you are resolving the issue. Select from an available resolution, or add

custom codes to the Jira default codes. In some workflows, this field is mandatory. Refer to your Jira workflow

configuration.

•

Comment

Enter a comment for a reopened issue. In some workflows, this field is mandatory. Refer to your Jira workflow

configuration.

3. Click Create.

Wait for Approval (Jira)

Determine that tasks are queued until the completion and approval of a specified issue.

280

Continuous Delivery Director 8.5

One or more Jira endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field.

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Jira Issue ID

Specify the ID of a Jira issue to be completed and approved before the next task starts.

•

Required Status

Specify the required status for the selected Jira issue to reach before the next task starts.

•

Poll Interval

Specify the length of time in seconds between system requests for the Jira issue status. Default: 120 seconds

3. Click Create.

Define Output Parameters (Jira)

Configure the output data for Jira tasks by editing the plug-in setting.properties file.

When you create a task in a release, you see a list of output fields provided that the Jira plug-in settings.properties

file is configured accordingly. This list of fields is based on the default output profile defined in settings.properties.

You can add tokens to the fields. After a Jira task executes, the tokens are populated with values based on the JSON path

that is defined in the profile.

1. From the command line, open the settings.properties file.

A typical file path is ../webapps/cdd-jira-plugin/WEB-INF/classes/settings.properties.

2. For each profile, define the following settings:

•

A unique profile name

•

A display name. Syntax: cdd.plugins.jira.profiles.1.display_name

•

An associated task. Each profile must be associated with a specific task by name (the task name that appears in

the plugin manifest). Syntax: cdd.plugins.jira.profiles.<number>.task.<Number>.name

3. Set a specific profile as the default profile. Syntax: cdd.plugins.jira.profiles.default_profile

4. For each output field, define the following settings:

•

A display name. Syntax:

cdd.plugins.jira.profiles.<num>.task.<number> .output.parameters.<number>.display_name

•

A description. Syntax: cdd.plugins.jira.profiles.1.task.1.output.parameters.1.description

NOTE

The description appears in the field help text.

•

An output value. Syntax: cdd.plugins.jira.profiles.1.task.1.output.parameters.1.metadata

281

Continuous Delivery Director 8.5

NOTE

In a Get Jira Issue task, this is a JSON path or property.

If you want to get the value of an attribute directed under Issue, such as

description, you can just provide metadata as the property name. Example:

cdd.plugins.jira.profiles.1.task.1.output.parameters.3.metadata=description.

If you want to get the value of a nested attribute (for example, Issue/Project/Name),

you can specify the property using a dot (.) separator as metadata. Example:

cdd.plugins.jira.profiles.1.task.1.output.parameters.1.metadata=project.name

Sample settings.properties file:

cdd.plugins.jira.profiles.default_profile=Profile 1

cdd.plugins.jira.profiles.1.display_name=Profile 1

cdd.plugins.jira.profiles.2.display_name=Profile 2

cdd.plugins.jira.profiles.1.task.1.name=getJiraIssue

cdd.plugins.jira.profiles.2.task.1.name=getJiraIssue

cdd.plugins.jira.profiles.1.task.1.output.parameters.1.display_name=Project

cdd.plugins.jira.profiles.1.task.1.output.parameters.1.description=

cdd.plugins.jira.profiles.1.task.1.output.parameters.1.metadata=project.name

cdd.plugins.jira.profiles.1.task.1.output.parameters.2.display_name=Comment

cdd.plugins.jira.profiles.1.task.1.output.parameters.2.description=

cdd.plugins.jira.profiles.1.task.1.output.parameters.2.metadata=commentsUri

cdd.plugins.jira.profiles.1.task.1.output.parameters.3.display_name=Description

cdd.plugins.jira.profiles.1.task.1.output.parameters.3.description=

cdd.plugins.jira.profiles.1.task.1.output.parameters.3.metadata=description

cdd.plugins.jira.profiles.2.task.1.output.parameters.1.display_name=Project

cdd.plugins.jira.profiles.2.task.1.output.parameters.1.description=

cdd.plugins.jira.profiles.2.task.1.output.parameters.1.metadata=project.name

cdd.plugins.jira.profiles.2.task.1.output.parameters.2.display_name=Summary

cdd.plugins.jira.profiles.2.task.1.output.parameters.2.description=

cdd.plugins.jira.profiles.2.task.1.output.parameters.2.metadata=summary

Import Work Items (Jira)

Sync work items between Jira and Continuous Delivery Director releases.

You have configured an endpoint between Jira and Continuous Delivery Director as described in Configure a Jira

Endpoint.

The Jira plug-in uses the Jira Query Language (JQL), to import Jira work items into a release. Use this capability when

you create a release to see the related Jira information.

1. In a release, click the Work Items tab on the left menu.

2. Select Add Work Items.

The ADD WORK ITEMS window opens.

282

Continuous Delivery Director 8.5

3. Select External Items.

4. Enter a name for the work items source.

Jira Feed

5. Under Work Items Source, select the Jira plug-in and a configured Jira endpoint.

6. Provide information in the required parameter fields. These fields let you build a query that searches Jira for work

items that match the specified criteria.

•

Query

You can import the following Jira metadata into a release by entering a JQL query into the Query field:

–

Summary - Example:summary = issue ID_123456

–

Type - Example:type = bug and status = resolved

–

External Id - Example:External issue ID ~ YourID_123456

–

Display Type - Example:type = status = open

–

Status - Example:status = open and priority = urgent and assignee = jsmith

7. Click Create.

The content source is saved and a list of the returned work items is displayed under the application in the left menu.

These work items are now available to assign to tasks in phases to associate with the release.

Get Test Assets (Jira)

The Jira plug-in lets you import test issues into the Adaptive Testing Catalog.

You have the Xray Test Management for Jira application integrated with your Jira instance and are familiar with this app.

NOTE

This plug-in has been validated for Xray Test Management for Jira 5.0.1.

You can add Jira as a test source to import test issues as test suites into Continuous Delivery Director. Organizations use

the Xray Test Management for Jira application to facilitate test management using Jira issues. Xray uses special Jira issue

types to support the testing lifecycle. Xray also includes support for Cucumber and other test frameworks.

This plug-in integrates the Test, Test Execution, and Test Plan Jira issue types, as well as TestXY, a custom Jira issue type

for testing. Test assets such as test issues, test plans, and test executions are available according to the Jira project that

you specify.

1. Select Tests, then Adaptive Testing Catalog.

2. Specify the Application and the Application Version. The menu next to the application name and version is

activated.

3. Fill in the following fields:

TIP

Open your Jira instance so that you can check input values.

NOTE

Use the @ symbol in the following fields to select from a dynamic list of entities associated with the selected

project.

•

Test Source Name

Enter a name for the test source.

•

Plug-in

Select Jira and Import Tests (Jira).

•

Endpoint

283

Continuous Delivery Director 8.5

Select a Jira endpoint.

•

Jira Project Key

Specify the key of the Jira project that contains the tests you want to import.

•

Test Issue Type

Select a test issue type from the dropdown menu; either Test or TextXY.

•

Test Plan Key

Specify the test plan key to import the associated tests.

•

Test Execution Key

Specify the test execution key to retrieve the test results.

•

Build Number

Enter the tested build number.

•

Execution Duration in Hours

•

Polling Period in Minutes

•

Tags

Select or create one or more tags to label the imported tests.

NOTE

To import manual test results from Jira, enter the tag Manual.

4. Select Get Test Assets.

Jira is added as a test source. When an adaptive testing task is run, the test results for the specified build appear on the

Adaptive Testing Results page, together with links to the associated reports in Jira.

Automic

Continuous Delivery Automation Plug-in

Release automation is a key component of your continuous delivery pipeline. The Automic Continuous Delivery

Automation (CDA) plug-in enables you to apply core CDA deployment modeling (applications, environments, and so

on) and deployment capabilities.

This plug-in lets you start both Application and General workflows in CDA directly from the Continuous Delivery Director

user interface.

NOTE

This plug-in is available for both on-premise installations and SaaS (through a plug-in proxy).

Plug-in Version 4.1-10

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-cda-plugin.war https://

cspdl.broadcom.com/shared/static/

ypqyd6xzz4adfzbwsms9ob2udycx1kxy.war?

LCK=ent.box.com

MD5 8b086e26e38b29d7ea89d0f5e255c0f2

Click Download Button

284

Continuous Delivery Director 8.5

Change History

The following update was made for plug-in version 4.1-10:

•

Bugfix: Error when running CDA deployment.

The following update was made for plug-in version 4.1-9:

•

Users can now use the CDD applications as the CDA components when creating a package. Also, the user can

specify an Application from which the components will be imported and created as applications in CDD.

The following update was made for plug-in version 4.1-8:

•

Bugfix: Create package fails for the 'Run Application Workflow' task.

The following update was made for plug-in version 4.1-7:

•

Security fixes.

The following update was made for plug-in version 4.1-6:

•

Security enhancements.

The following update was made for plug-in version 4.1-5:

•

Security enhancements.

The following update was made for plug-in version 4.1-4:

•

Bugfix: Internal defect.

The following update was made for plug-in version 4.1-3:

•

Bugfix: An ungrammatical error message was generated when the following scenario occured. A CDA task to start an

Application workflow ran. However two mutually exclusive options were both configured: provide a package and create

a package.

The following updates were made for plug-in version 4.1-2:

•

Bugfix: The link in the CDA deployments report under the CDA deployment column was missing. Additionally, the

domain name was missing in the link.

•

Bugfix: Setting dynamic values in a CDA task generated a 500 internal server error, indicating that the HTTP request

could not be fulfilled because an unexpected condition was encountered.

The following updates were made for plug-in version 4.1-1:

•

Bugfix: The set build action was performed on the package name instead of on the build number.

The following updates were made for plug-in version 4.1:

•

Build numbers are now available as dynamic properties. This change allows you to dynamically update the

last_successful_change property dynamically in CDA with a build number passed from the task in Continuous

Delivery Director.

The following updates were made for plug-in version 4.0:

•

Import Application from CDA to Continuous Delivery Director

The previous plug-in imported a CDA application as a Continuous Delivery Director application. The new plug-in

imports a CDA component as a Continuous Delivery Director application.

NOTE

A Continuous Delivery Director application is equivalent to a CDA component and a Continuous Delivery

Director business application is equivalent to a CDA application.

•

Create Package

285

Continuous Delivery Director 8.5

In the CD pipeline, each component requires a separate build job, and the package must be created from the artifacts

created by all the build jobs.

The previous plug-in used Jenkins to create the package, meaning that if you wanted to create a CD pipeline, you had

to set up a separate package for each component.

The new plug-in can automatically create packages. If a build of any of the components is ready, the plug-in

automatically creates a package and runs the deployment.

•

Build Promotion

The previous plug-in performed the set build action on a package and not on a build. Therefore build promotion did

not take place per component, but per package instead. Furthermore, a workaround to create a package name was

required before build promotion could be used.

The new plug-in resolves this issue and you can simply use the last successful change of any of the other deployments

tools that Continuous Delivery Director supports.

•

Plug-in Downloads

The old plug-in was only available from the Automic Marketplace. Users can now download the new plug-in from the

Continuous Delivery Director home page.

Supported Versions

The CDA plug-in supports CDA 12.0 and above.

To learn more about CDA, see https://docs.automic.com/documentation

Capabilities

This plug-in lets you perform the following activities:

•

Import applications and environments from a CDA instance. You can include all CDA applications and their

environments in releases, phases, tasks, and reports.

•

Start a workflow in CDA from a task in a release.

Import CDA Applications and Environments

You can import applications and environments from your CDA endpoint to be used in the continuous delivery orchestration

pipeline.

NOTE

You must make any changes to the applications or environments directly within your CDA instance.

Continuous Delivery Director converts any imported CDA environments with the same name to a single shared

environment.

TIP

Import applications and environments from CDA before using this CDA plug-in.

For more information about the application and environment model import, see Applications and Environments.

Workflows

In CDA, workflows are used to carry out physical deployments. A workflow describes all necessary steps for the

deployment of your application.

Workflows consist of a set of tasks or actions, which are organized in a combination of sequential and parallel execution

paths, which are combined with conditions, loops, pre-conditions, and post-conditions. Each action can run in parallel or

sequentially for one or multiple deployment targets within an environment.

286

Continuous Delivery Director 8.5

In Continuous Delivery Director, after you configure CDA workflows using the CDA plug-in, you can execute workflows

at any time or schedule workflows to run at a specific time. You can monitor the executions to see how the workflows are

progressing. You can also take action to influence the execution process, such as rolling back to a specific task, when the

execution fails or gets delayed.

The CDA plug-in supports the following types of workflows:

•

Application workflows. For more information, see Start Application Workflow.

•

General workflows. For more information, see Start General Workflow.

ATTENTION

Application workflows are stored in folders with the application (no separate access control), whereas general

workflows are stored in separate folders.

Configure a CDA Plug-in Endpoint

You are familiar with Automic Continuous Delivery Automation (CDA).

You have been granted the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

The manifest for the CDA plug-in is http://<host>:<port>/cdd-cda-plugin/manifest.json .

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the CDA plug-in.

4. Configure the following endpoint parameters:

•

CDA URL

Specify the URL to the required CDA instance.

•

Username/Password

Specify the credentials of a CDA user (client/name/department and password) with sufficient permissions to

execute a CDA application (the equivalent of a Continuous Delivery Director business application) deployment.

5. Click Test Connection to check the connection to CDA.

6. Click Add.

Start Application Workflow

This task lets you run an Automic Continuous Delivery Automation (CDA) application workflow in the context of

Continuous Delivery Director phases and releases.

One or more CDA endpoints are available.

Applications and environments have been imported from CDA.

Application workflows combine and orchestrate different component workflows for complete end-to-end application

deployment. You can use application workflows for installations, updates, and removal of one or more components that

are involved in deployment for a specific application. To provide a clear structure that is easier to build and to monitor,

application workflows are made up of two kinds of workflows:

•

Application deployment workflow

Defines the overall process of an application deployment by defining the components which are deployed.

An application workflow typically has only one main purpose, for example, installing a program, deploying an update,

or provisioning a new instance.

•

Component workflow

287

Continuous Delivery Director 8.5

Orchestrates the deployment of an individual component (or parts of it) on one or more deployment targets within an

environment. Here you define the steps for the deployment of a single component of an application. You can regard

components as the building blocks for application deployment.

For example, a website may have frontend, backend, and database components. Each component should be

independent of the other components so that only those components that have been updated are deployed.

This task creates a package upon build notification and uses the Continuous Delivery Director applications of the task as

the component names,

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following input parameters:

TIP

Values: Applies to the Application, Application Workflow, Package, and Deployment Profile properties.

To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

•

Application

Specify a CDA application name to execute an application workflow. You can find the application names in the

Applications pane if you imported the CDA deployment model and assigned the relevant applications to the

release.

•

Workflow

Specify the name of the application workflow to be executed.

•

Provide a Package

Specify an existing package to execute an application workflow. A package is an instance (a version, a revision, a

tag, and so on) of an application and defines the content to deploy.

NOTE

If you enter a package name, you cannot select the Create a Package? option.

•

Create a Package?

Select this option if you want to create a package to execute an application workflow. The following fields appear:

NOTE

If you select this option, you cannot specify a package name in Provide a Package.

–

Package Name Prefix

Specify a prefix for the package name. This plug-in appends the current timestamp to this prefix to generate a

unique name.

–

Package Type

Specify the package type, such as Deployment, Generic, and so on.

–

Folder

Specify the folder name. If left empty, the folder name as 'DEFAULT' is used.

–

Package Dynamic Properties

Specify name and values for the Package Dynamic Properties.

–

Artifacts

Specify the artifacts for the package in JSON format. An artifact is a version of a file to be deployed, located in

a specific repository. In a deployment package, an artifact is created for each component. For each component

specify the following:

288

Continuous Delivery Director 8.5

•

Package Name Prefix

Specify a prefix for the package name. This plug-in appends the current timestamp to this prefix to generate a

unique name.

•

Package Type

Specify the package type, such as Deployment, Generic, and so on.

•

Artifacts

Specify the artifacts for the package in JSON format. For each component specify the following:

•

Component Name

Component name to assign to package. Specified components must match applications added to this

task.

•

Artifact Source

Specify artifact source name from which to retrieve the artifact.

•

Artifact Name

Specify artifact name to include in the package.

JSON format:

{

"Artifacts": [

{

"Component Name": "{component name}",

"Artifact Source": "{artifact source}",

"Artifact Name": "{artifact name}"

}

]

}

Example:

{

"Artifacts": [

{

"Component Name": "Joe-Comp1",

"Artifact Source": "ArtifactSource",

"Artifact Name": "PetShop.war"

}

]

}

•

Deployment Profile

Specify a deployment profile to execute an application workflow. A deployment profile links an application to one

specific environment. Typically a profile is an intersection between the application components and the environment

deployment targets. The deployment profile is used during the deployment execution and defines the target

deployment location.

•

Installation Mode

Select one of the following options:

–

SkipExisting to only deploy the application on deployment targets where the package has not yet been

deployed.

–

OverwriteExisting to deploy the package on every deployment target and overwrite existing components.

•

Dynamic Property

(Optional). Specify a dynamic property to use as an input parameter for the workflow execution. Select a dynamic

property and a value to pass on.

•

Value

289

Continuous Delivery Director 8.5

(Optional). If you have specified a dynamic property to be used as an input parameter for the workflow execution,

specify a value to pass on.

•

Additional Dynamic Properties

(Optional). Specify additional dynamic properties and values (in JSON format) to pass on.

•

Compensation Parameters

Define parameters for a compensation workflow to be executed if the CDA status of the main workflow is rejected,

revoked or canceled.

–

Workflow

–

Dynamic Property

–

Value

–

Additional Dynamic Properties

3. Configure the following output parameters:

•

Package Name

Specify the package name that is created in CDA.

•

ExecutionID

Specify the ID of the execution.

•

RunID

Specify the run ID in the Automation Englne.

4. Click Create.

Application Model Import

You can import the application and environment models from the Automic Continuous Delivery Automation (CDA) plugin.

During product configuration, you can import the application and environment models from the Automic Continuous

Delivery Automation (CDA) plugin. Using the CDA Application Models, you can tie the release activities and the content to

the real applications and environments.

For more information about Application Model Import, see Applications and Environments.

Start General Workflow

This task lets you run an Automic Continuous Delivery Automation general workflow in the context of Continuous Delivery

Director phases and releases.

One or more CDA endpoints are available.

Applications and environments have been imported from CDA.

General workflows are available as an option for more generic tasks (as the name implies), such as a single starting

point for larger-scale process automation, maintenance tasks, or for any action that does not require access to the CDA

object model. General workflows are used for generic CDA processes only (such as checking an internal CDA resource).

Typically, any actions outside of deployment are executed here.

General workflows are most often used for the orchestration of multiple application deployments alongside other tasks,

or for user-triggered maintenance tasks. General workflows do not belong to any CDA application (equivalent to a

Continuous Delivery Director business application).

290

Continuous Delivery Director 8.5

This task lets you orchestrate core CDA activities at a high level. For example, a Continuous Delivery Director release

might include multiple applications that you can deploy through the CDA deployment model.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following input parameters:

TIP

Values: Applies to the Application, Application Workflow, Package, and Deployment Profile properties.

To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

•

Workflow

Specify the name of the general workflow to be executed.

•

Dynamic Property

(Optional). Specify a dynamic property to use as an input parameter for the workflow execution. Select a dynamic

property and a value to pass on.

•

Value

(Optional). If you have specified a dynamic property to be used as an input parameter for the workflow execution,

specify a value to pass on.

To define a value, perform one of the following actions:

–

To select from a list of possible values, type an at sign "@"

–

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows), type a

percent sign "%"

–

Type free text

–

Enter a combination of free text and tokens

•

Additional Dynamic Properties

(Optional). Specify additional dynamic properties and values (in JSON format) to pass on.

•

Compensation Parameters

Define parameters for a compensation workflow to be executed if the CDA status of the main workflow is rejected,

revoked or canceled.

–

Workflow

–

Dynamic Property

–

Value

–

Additional Dynamic Properties

3. Configure the following output parameters:

•

ExecutionID

Specify the ID of the execution.

•

RunID

Specify the run ID in the Automation Englne.

4. Click Create.

AWS CodeDeploy Plug-in

This plug-in lets you deploy to AWS cloud environments from a GitHub repository.

291

Continuous Delivery Director 8.5

To configure endpoints, see Configure an AWS CodeDeploy Endpoint .

To configure tasks, see Create Deployment (AWS CodeDeploy).

Plug-in Version 2.0-5

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-awscodedeploy-plugin.war

https://cspdl.broadcom.com/shared/static/

k6o510qt4fhbvhmp9foagrmzu569ogpy.war?

LCK=ent.box.com

MD5 1b83308540bb951c22f7d8ad0b331b2e

Click Download Button

Supported Versions

The AWS CodeDeploy plug-in supports the core AWS CodeDeploy SaaS solution.

For more information, see the AWS CodeDeploy documentation at https://aws.amazon.com/documentation/codedeploy/

Change History

The following updates were made for plug-in version 2.0-5:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 2.0-2:

•

Bugfix: list-deployment-instances is deprecated and does not support EC2 deployments. Use list-deployment-

targets instead.

The following updates were made for plug-in version 2.0-1:

•

Bugfix: A deployment task completed successfully, but an error message, NullPointerException: element

cannot be mapped to a null key, appeared on the release page.

The following updates were made for plug-in version 2.0:

•

Support was added for Amazon S3 buckets as source control repositories in endpoints.

WARNING

This plug-in update is not backward compatible. To avoid potential issues, unregister the plug-in, overwrite

the war file, and re-register.

•

Default values were added to the Version ID endpoint parameter.

The following updates were made for plug-in version 1.2:

•

Support was added for Java 11.

Configure an AWS CodeDeploy Endpoint

Enable communication and synchronization of assets between AWS CodeDeploy and Continuous Delivery Director.

292

Continuous Delivery Director 8.5

You are familiar with AWS Code Deploy.

You have been granted the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

The manifest for the AWS Code Deploy plug-in is http://<host>:<port>/cdd-AwsCodeDeploy-plugin/

manifest.json .

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the AWS CodeDeploy plug-in.

4. Configure the following endpoint parameters:

•

Name

Specify the name of the endpoint.

•

Region

Specify the AWS region to use, such as us-west-1.

•

Access Key ID

Specify the access key ID that is used to access the AWS CodeDeploy instance.

•

Secret Access Key

Specify the secret access key that is used to access the AWS CodeDeploy instance.

•

Source

Specify the application source type from the following options:

–

GitHub

–

AWS S3

GitHub

–

GitHub Repository Owner

Specify the name of the GitHub repository owner.

–

GitHub Repository

Specify the name of the required GitHub repository, such as RepositoryName.

–

GitHub User Name

(Optional) Specify a GitHub user name.

NOTE

This field is not required when using an API key for authentication (GitHub Cloud only supports API

Key).

–

GitHub Password

(Optional) Specify a password or a personal access token to authenticate to GitHub.

For AWS S3

–

Service API URL

Specify the service endpoint either with or without an https prefix, such as https://s3.us-

west-1.amazonaws.com or s3.us-west-1.amazonaws.com.

–

Region

Specify the region to use for SigV4 signing of requests, such as us-west-1.

–

Bucket Name

Specify the required S3 bucket name.

–

File Name

Specify the required file name.

–

Revision File Type

Specify the revision file type. Possible values: zip, tar, tar.gz, tgz, or leave blank.

293

Continuous Delivery Director 8.5

5. Click Test Connection to check the connection to AWS CodeDeploy.

6. Click Add.

Create Deployment (AWS CodeDeploy)

This task lets you deploy application revisions stored in GitHub repositories or Amazon S3 buckets to AWS CodeDeploy

instances.

One or more AWS CodeDeploy endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following input parameters:

•

Application

Specify the name of the application as the application appears in your AWS account in the endpoint region.

•

Deployment Group

Specifies the name of the deployment group that is a member of the application.

NOTE

If you do not have a deployment group that is configured, first create a deployment group in AWS.

•

Deployment Configuration

(Optional) Specifies the name of a deployment configuration that is associated with the applicable IAM user or

AWS account. Default: The value that is configured in the deployment group.

•

Version ID

Specify the version ID of the S3 object or the SHA1 commit ID of the GitHub commit that represents the bundled

artifacts for the application revision. When left empty, the HEAD is taken.

•

Description

(Optional) Specify a description of the deployment.

3. Click Create.

AWS Elastic Beanstalk Plug-in

The AWS Elastic Beanstalk plug-in lets you deploy web applications from Amazon S3 cloud storage to AWS Elastic

Beanstalk application container environments.

NOTE

You can deploy web applications that are packaged in a web application archive (WAR) file.

Plug-in Version 2.1-2

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-awselasticbeanstalk-plugin.war

https://cspdl.broadcom.com/shared/static/

gb16spt5474ve3cxj7alm1bq07u9ngin.war?

LCK=ent.box.com

MD5 2888d8455a826e30954abbf3dd6768c3

294

Continuous Delivery Director 8.5

Click Download Button

Supported Versions

The AWS Elastic Beanstalk plug-in supports the core AWS Elastic Beanstalk SaaS solution.

For more information, see the AWS Elastic Beanstalk documentation at https://docs.aws.amazon.com/console/quickstarts

What's New

The following updates were made for plug-in version 2.1-2:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 2.1:

•

Support was added for Java 11.

Configuration

Manifest URL

For plug-in registration, use the following AWS Elastic Beanstalk manifest URL:

http://<plugin-server>:<port>/cdd-awselasticbeanstalk-plugin/manifest.json

Endpoint Parameters

The following parameters are required to create an endpoint:

•

Access Key ID

Specifies the AWS Access Key ID that provides permission to access the AWS Elastic Beanstalk instance

Example: AKIAIOSFODNN7EXAMPLE

•

Secret Access Key

Specifies the AWS secret access key that is used to access the AWS Elastic Beanstalk instance

Example: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

•

AWS Region

Specifies the AWS region

Example: eu-west-1

•

Source

Specifies the source type

Example: S3

•

S3 Bucket

Specifies the name of the Amazon S3 bucket that is used to cache your source archives

To check the connection to AWS Elastic Beanstalk and to Amazon S3, use the endpoint Test Connection option. The

Test Connection option returns the following results:

•

Success

Both connections were successful

•

Failure

One or more connections failed

295

Continuous Delivery Director 8.5

Tasks

The following task types are available in the AWS Elastic Beanstalk Plug-in:

Deploy

The Deploy task contains the following fields:

Input Parameters

•

Application Name

Specifies the logical name of the application as the name appears in your Amazon S3 account

Values: Free text, or a combination of text and tokens

Note: For a list of available values, enter the commercial at sign (@). For a list of available tokens, enter the

percent sign (%)

•

Environment Name

Specifies the name of the AWS Elastic Beanstalk environment to update

Values: Free text, or a combination of text and tokens

Note: For a list of available values, enter the commercial at sign (@). For a list of available tokens, enter the percent

sign (%)

Example: Tomcat 8

•

S3 Key

Specifies the WAR file name or a folder name as these items appear in your Amazon S3 account

•

Values: Free text, or a combination of text and tokens

Note: For a list of available tokens, enter the percent sign (%)

•

Build Number

Specifies the build number that is associated with the selected WAR file

Values: Free text, or a combination of text and tokens

Note: For a list of available tokens, enter the percent sign (%)

•

Description

(Optional) Specifies a description of the deployment

Output Parameters

•

Application URLSpecifies the URL of the deployed application

Values: Free text or a combination of text and tokens

Note: For a list of available tokens, enter the percent sign (%).

Tutorial Videos

Configuration

The following video shows how to configure Continuous Delivery Director integration with AWS Elastic Beanstalk:

Azure DevOps Server Plug-in

This plug-in lets you track work items through the release pipeline.

Plug-in Version 1.1-6

This plug-in synchronizes work items between Azure DevOps Server (formerly Team Foundation Server (TFS) and Visual

Studio Team System (VSTS) and Continuous Delivery Director. This integration allows Azure DevOps Server to be used

as any other content source for a release in Continuous Delivery Director.

296

Continuous Delivery Director 8.5

Content synced includes features, epics, code review requests, tasks, test cases, and bugs. You can also import content

into Continuous Delivery Director from Azure DevOps Server.

Method Info

wget wget -O cdd-tfs-plugin.war https://

cspdl.broadcom.com/shared/static/

nb4twkai3laqb513vueq0it6asteptz3.war?

LCK=ent.box.com

MD5 883f94b02e3c817a398c7bbffa334342

Click Download Button

Supported Versions

The TFS plug-in supports TFS 2017, TFS 2018, Azure DevOps Server 2019 and above, Azure DevOps Services (Cloud).

To learn more about Azure DevOps Server, see https://azure.microsoft.com/en-us/services/devops/server/

Capabilities

The Azure DevOps Server plug-in supports the following capabilities:

•

Release Tasks

–

Run Build

–

Create Work Item

–

Update Work Item

–

Wait for Approval

•

Get Files

•

Import Work Items

Change History

The following updates were made for plug-in version 1.1-6:

•

Security enhancements.

The following updates were made for plug-in version 1.1-5:

•

Security enhancements.

The following updates were made for plug-in version 1.1-4:

•

Security enhancements.

The following updates were made for plug-in version 1.1-3:

•

Support was added for Azure DevOps Server 2020.0.1.

The following updates were made for plug-in version 1.1-2:

•

A Get Commit Messages task was added to the Set Source Control Connection feature. This task lets you use

Azure DevOps Server to retrieve and parse commit messages. Use this capability when you deploy applications in a

release to see the status of related work items and to compare planned and actual work items.

•

You can now retrieve parent work items together with child work items. Use this capability when comparing planned

and actual work items.

297

Continuous Delivery Director 8.5

The following updates were made for plug-in version 1.1:

•

You can now use TFS/VSTS as a file source so that releases are automatically created and run whenever you make

changes to the JSON file.

•

A new endpoint parameter has been added, TFS Version.

The following updates were made for plug-in version 1.0.3:

•

Support was added for Java 11.

Configure an Azure DevOps Server Endpoint

Enable communication and synchronization of assets between Azure DevOps Server and Continuous Delivery Director.

You are familiar with Azure DevOps Server (formerly Team Foundation Server (TFS) and Visual Studio Team System

(VSTS).

You have been granted the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

The manifest for the Azure DevOps Server plug-in is http://<host>:<port>/cdd-tfs-plugin/

manifest.json .

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the Azure DevOps Server plug-in.

4. Configure the following endpoint parameters:

•

URL

Enter the URL of your Azure DevOps Server machine or Azure DevOps Services instance.

•

Collection

Enter the name of your team project collection (a group of team projects).

•

Authentication Type

Select one of the following methods to authenticate to the TFS service:

–

Personal Access Token

–

NTLM

For Personal Access Token

–

Azure DevOps Server Username

Enter the user name to authenticate to the Azure DevOps Server service.

–

Personal Access Token

Enter your personal access token to authenticate to the TFS service.

For NTLM

–

Azure DevOps Server Username

Enter the user name to authenticate to the Azure DevOps Server service.

–

Azure DevOps Server Password

Enter your password to authenticate to the Azure DevOps Server service.

–

Domain

Enter the Azure DevOps Server domain.

Example: ca.com

•

Version

Select one of the following versions based on your AzureDevOps version and API usage. For information

about Azure DevOps APIs and version mapping, refer to the Microsoft documentation.

298

Continuous Delivery Director 8.5

–

(Default) For API version 4.1 TFS 2018 Update 3

–

For API version 4.0 TFS 2018 RTW

–

For API version 2.3 TFS 2015 Update 4

5. Click Test Connection to check the connection to Playwright.

6. Click Add.

Import Work Items (Azure DevOps Server)

The Azure DevOps Server plug-in lets you sync work items between Azure DevOps Server and Continuous Delivery

Director releases. Use this capability when you create a release to see the related Azure DevOps Server information.

You have configured an endpoint between Azure DevOps Server and Continuous Delivery Director as described in

Configure an Azure DevOps Server Endpoint.

You can also connect applications to Azure DevOps Server to see which work items are being developed and entering

your release pipeline on every notification arrival from your build server. To set up this configuration, follow the instructions

in Set Work Items Connection.

1. In a release, click the Work Items tab on the left menu.

2. Select Add Work Items.

The ADD WORK ITEMS window opens.

3. Select External Items.

4. Enter a name for the work items source.

Azure Feed

5. Under Work Items Source, select the Azure DevOps Server plug-in and a configured Azure DevOps Server

endpoint.

6. In Import Using, select either Filter or WIQL. WIQL lets you write queries in Work Item Query Language to import

content.

7. Provide information in the required parameter fields. These fields let you build a query that searches Azure DevOps

Server for work items that match the specified criteria.

WIQL

•

Query

Specify a WIQL query to import work items. For example:

SELECT [System.ID],[System.WorkItemType],[System.Title],[System.State]

FROM WorkItems

WHERE [System.TeamProject] = 'TFS Demo'

Filter

Use the following fields to filter the work item import results:

TIP

Values: To select from a list of possible values, type an at sign "@" in the field. You cannot combine values

with free text or tokens. Applies to all fields except Work Item Tags.

•

Team Project

Specify the name of the Azure DevOps Server team project that contains the content you want to import. Type an

at sign "@" to select from a list of team projects in the Azure DevOps Server endpoint. Type the at sign "@" in other

fields to select from a dynamic list of entities that are associated with the selected team project.

Values: An alphanumeric string.

299

Continuous Delivery Director 8.5

–

Must not contain any Unicode control characters or surrogate characters

–

Must not contain the following characters: / : \ ~ & % ; @ ' " ? < > | # $ * } { , + = [ ]

–

Must not start with an underscore (_)

–

Must not start or end with a period (.)

•

Area Path

Specify the area path that is defined for the team project.

•

Iteration Path

Specify the iteration path that is defined for the team project.

•

Work Item Type

Specify the type of work item that you want to import.

•

Work Item State

Specify the work item states to import. This field lets you filter what is imported based on the state.

Example: Import only work items that are in the Done state.

•

Work Item Tags

Specify the work item tags stored in Azure DevOps Server. This field lets you filter what work items are imported as

long as the items contain at least one specified tag.

8. Select Create.

The content source is saved and a list of the returned work items is displayed under the application in the left menu.

These work items are now available to assign to tasks in phases to associate with the release.

Get Files (Azure DevOps Server)

Use Azure DevOps Server as a file source so that releases are automatically created and run whenever you make

changes to a JSON file in source control.

•

You have configured an endpoint between Azure DevOps Server and Continuous Delivery Director as described in

Configure an Azure DevOps Server Endpoint.

•

You have created a top-level folder in the relevant repository in Azure DevOps Server with the following name: CDD-

FileSource and placed all release-related JSON files in this folder.

1. Do one of the following:

•

From RELEASES, click File Source, then New File Source.

•

From the Administration menu, click File Sources, then New File Source.

2. In CREATE FILE SOURCE, configure the following parameters:

•

Name

Enter a name for the file source.

•

Select Source Control

Select Azure Devops Server and Get Files.

•

Select Endpoint

•

SCM Type

Select either Git or TFVC, according to the source control management system used in Azure Devops Server.

•

Project

Specify a Azure Devops Server project name or ID.

•

Repository

Specify the name of the Azure Devops Server repository from which to import the files.

•

Branch

300

Continuous Delivery Director 8.5

Specify a branch used by the specified project. To allow processing of webhook notifications from all repository

branches, keep this field empty.

•

Releases Created On Behalf Of (API Key)

Specify the API key of a user on whose behalf future releases will be created. For example, the API key of the

product owner.

•

Send Error Notifications To

Specify one or more recipients to receive error notifications.

3. Click Create.

A COPY WEBHOOK popup is displayed containing an auto-generated webhook.

4. Copy this webhook and paste it into Azure Devops Server.

The newly-created file source is added to the FILE SOURCES page.

NOTE

For more information, seeHow to Set Up Webhooks in your Source Control.

Run Build (Azure DevOps Server)

Run Azure DevOps Server project builds in the context of Continuous Delivery Director phases and releases.

One or more Azure DevOps Server endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Project Name

Specify the name of an Azure DevOps Server team project.

•

Build Definition Name

Specify the name of an Azure DevOps Server build definition related to the specified project.

•

Ignore Warnings

Determine whether warnings are suppressed at the build level.

•

Agent Queue

Specify the agent queue used by the specified build definition.

•

Branch

Specify the version control branch used by the project.

•

Parameters

Specify the parameters for an Azure DevOps Server parametrized build to pass to the specified build configuration.

Define the parameters in JSON format. Syntax:

{“param1”:”value”, “param2”:”value” }

301

Continuous Delivery Director 8.5

Output Parameters

•

Build Number

Returns the ID of the build that was run.

•

Build Result

Returns the status of the build that was run.

•

Source Version

Returns a link to the change-set of the build.

3. Click Create.

Create Work Item (Azure DevOps Server)

Create a work item and return the work item ID for future use.

One or more Azure DevOps Server endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Team Project

Specify the name of an Azure DevOps Server team project where you want to create the work item.

•

Work Item Type

Specify the type of work item that you want to create.

NOTE

(For Azure DevOps Services) Enter a valid Azure DevOps Services work item type. This field is case-

sensitive.

•

Work Item Title

Specify the name of the work item that you want to create.

•

Work Item Tags

Specify the work item tags to be added to the work item that you want to create. Use simple text and separate

multiple tags with commas. Syntax: tag1, tag2, ...

•

Additional Fields

Specify one or more "field name":"value" pairs. You can update multiple fields using the following format:

{"field1":"value1","field2":"value2"…}. You can use this parameter for both standard and custom fields. For

example, {"System.Description": "Follow the code samples from MSDN"}

Output Parameters

•

Work Item ID

Specifies the ID of the newly-created work item.

302

Continuous Delivery Director 8.5

3. Click Create.

Update Work Item (Azure DevOps Server)

Update an existing work item with customized fields.

One or more Azure DevOps Server endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Work Item IDs

Specify one or more IDs of work items to update. Separate multiple IDs with commas.

NOTE

The fields to update must be common to all work items you list here.

•

Fields to Update

Specify one or more "field name":"value" pairs. You can update multiple fields using the following format:

{"field1":"value1","field2":"value2"…}. You can use this parameter for both standard and custom fields. For example:

{"System.Description": "Follow the code samples from MSDN"}

3. Click Create.

Wait for Approval (Azure DevOps Server)

Determine what tasks are queued until the completion and approval of a specified work item.

One or more Azure DevOps Server endpoints are available.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

303

Continuous Delivery Director 8.5

•

Work Item ID

Specify the ID of a work item to be completed and approved before the next task starts.Note: (For VSTS) Enter a

valid VSTS work item type. This field is case-sensitive.

NOTE

(For Azure DevOps Services): Enter a valid Azure DevOps Services work item type. This field is case-

sensitive.

•

Required State

Specify the required state for the selected work item to reach before the next task starts.

•

Poll Interval

Specify the length of time in seconds between system requests for the work item state. Default: 120 seconds

3. Click Create.

BlazeMeter

Plug-in

The BlazeMeter plug-in lets you run load and performance tests as part of your releases. This plug-in also lets you import

test suites from BlazeMeter to run Adaptive Testing tasks.

Plug-in Version 3.7-7

This plug-in automatically registers the BlazeMeter load testing capabilities with Continuous Delivery Director.

Watch the following video for a summary of how Continuous Delivery Director works with the BlazeMeter plug-in:

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-blazemeter-plugin.war

https://cspdl.broadcom.com/shared/

static/942ic59jaoq9ytym4xe6yufkbz5dgxbi.war?

LCK=ent.box.com

MD5 e1b7b25e0715eb587a53bd9dcd13ce3f

Click Download Button

Supported Versions

The BlazeMeter plug-in supports the core BlazeMeter SaaS solution.

For more information, see the BlazeMeter documentation at https://guide.blazemeter.com/

Change History

The following update was made for plug-in version 3.7-3:

•

Bugfix: Error messages in Continuous Delivery Director do not include the error code, causing delay in tracing the root

cause of errors.

The following update was made for plug-in version 3.7-2:

•

End time and polling time were enhanced.

304

Continuous Delivery Director 8.5

The following update was made for plug-in version 3.7-1:

•

Bugfix: When the plug-in was deployed onto multiple hosts, the log files were overwritten because all instances wrote

to the same log file.

The following update was made for plug-in version 3.7:

•

A new execution parameter, Enable JMeter Parameters, was added to the Get Test Assets (import tests/test

suites) function in the Adaptive Testing Catalog. This parameter lets you import BlazeMeter tests with the taurus

configuration type with a JMeter executor.

•

Thecdd_BlazeMeter_plugin.log file was renamed as cdd-blazemeter-plugin.log.

The following updates were made for plug-in version 3.6:

•

Four optional filter fields were added to the Get Test Assets (import tests/test suites) function in the Adaptive Testing

Catalog:

–

Test Configuration Type

–

Test Execution Type

–

Test Script Type

–

Test Executor Type

These filters are available for the Test option only and are not applicable to the Multi Test option.

•

Users can now view a BlazeMeter report without logging in to BlazeMeter.

•

A new dynamic endpoint parameter, Use Proxy, was added. This parameter determines whether to use a proxy

server.

•

Support was added for the enhanced API key authentication. To support this enhancement, two new parameters were

added to the Authentication Type field, API Key ID and API Key Secret.

The following updates were made for plug-in version 3.1:

•

Support for the test advisor was enhanced. This plug-in can now recognize new and updated test suites.

The following updates were made for plug-in version 2.3:

•

Support was added for Java 11.

Configuration

Manifest URL

For plug-in registration, use the following BlazeMeter manifest URL:

http://<plugin-server>:<port>/cdd-blazemeter-plugin/manifest.json

Endpoint Parameters

The following parameters are required to create an endpoint:

•

Name

Specify the name of the endpoint.

•

URL

Specify the URL that is used to access the BlazeMeter instance.

Default: https://a.blazemeter.com

•

Authentication Type

Select one of the following methods to authenticate to the BlazeMeter service:

305

Continuous Delivery Director 8.5

NOTE

For more information on API keys, see the BlazeMeter documentation.

–

Legacy

–

Advanced

For Legacy only

–

API Key

Specify the unique identifier for the BlazeMeter user.

Values: A string of alphanumeric characters.

For Advanced only

–

API Key ID

Specify the enhanced BlazeMeter API Key ID.

–

API Key Secret

Specify the enhanced BlazeMeter API Key Secret.

•

Use Proxy

{Optional} Determines whether a proxy server is used

Note: If selected, the Proxy Server URL, Proxy Server Username, and Proxy Server Password fields appear.

–

Proxy Server URL

Specify the web address that is used to access the proxy server

–

Proxy Server Username

{Optional} Specify the username that is used to authenticate to the proxy server

–

Proxy Server Password

{Optional} Specify the password that is used to authenticate to the proxy server

Test Failure Criteria

You can define test failure criteria in BlazeMeter to set your test pass / fail criteria for various metrics, such as response

times, errors, hits/s, test duration, and so on.

If test failure criteria have been defined in BlazeMeter, Continuous Delivery Director will show test pass/fail results of

BlazeMeter tests. If test failure criteria have not been defined in BlazeMeter, Continuous Delivery Director will always

show the tests as passed. In BlazeMeter, the test results appear as not set.

Tasks

The following task types are available in the BlazeMeter plug-in:

TIP

To select from a list of available BlazeMeter Values, enter the commercial At symbol (@) in the task field.

Run Test

The Run Test task requires the following fields:

•

Workspace

Specify the name of the workspace to which the test creator belongs

•

Project

Specify the project where the test is defined

•

Test

Specify the test to run

306

Continuous Delivery Director 8.5

Run Collection

The Run Collection task requires the following fields:

•

Workspace

Specify the name of the workspace to which the test collection belongs

•

Project

Specify the project where the test is defined

•

Collection

Specify the test collection to run

Get Test Assets

This plug-in lets you import test suites into the Adaptive Testing Catalog.

Follow these steps:

1. Select Tests, then Adaptive Testing Catalog.

2. Specify the Application and the Application Version. The menu next to the application name and version is

activated.

3. Select Get Test Assets.

4. Fill in the following fields:

–

Test Source Name

–

Plug-in

Select BlazeMeter and Import Test Suites.

–

Endpoint

Select a BlazeMeter endpoint.

–

Workspace Name

Specify the name of the BlazeMeter workspace where the test suites you want to import are located.

–

Project Name

Specify the name of the BlazeMeter project where the test suites you want to import are located. If left empty, test

suites will be imported from all sub-projects.

–

Type

Select either Test to import a specific test suite or Multi Test to import multiple test suites. If you select Test, the

following filters appear:

•

Test Configuration Type.

Possible Values: "external", "externalFunctionalMobile", "followme", "functionalApi", "functionalGui", "http",

"jmeter", "taurus", "webdriver"

•

Test Execution Type

Possible Values: "blazemeterImage", "taurusCloud"

•

Test Script Type

Possible Values: "jmeter", "selenium", "taurus"

•

Test Executor Type

Possible Values: "gatling", "grinder", "jmeter", "locust", "newman", "pbench", "selenium", "siege", "taurus",

"tsung"

–

Is Public Report

Select this option to enable users to access a link to the test report without logging in to BlazeMeter.

–

Enable JMeter Parameters

Select this option to enable the Jmeter Parameters text box.

NOTE

This option is applicable for BlazeMeter tests with thetaurus configuration type with a JMeter executor.

307

Continuous Delivery Director 8.5

•

Specify a JSON array of "key"/"value" pairs. On execution, the BlazeMeter test source sets the JMeter properties

of all taurus tests with a JMeter executor to this JSON array.

–

Tags

Select one or more tags to execute test suites tagged with your selection. Leave empty to execute all the test suites

under the application version.

Example: Type bl to retrieve all test suites tagged with labels beginning with bl, such as blazemeter.sanity.test

Burp Suite Plug-in

Scan your web applications for vulnerabilities from your release pipeline.

Plug-in Version 1.0-2

Burp Suite is a popular and scalable set of tools used for penetration testing of web applications. This plug-in integrates

with Burp Suite Enterprise and supports the following tasks:

•

Create Scan (Burp Suite)

Supported Versions

This plug-in was validated against Burp Suite Enterprise Edition v-2021.6

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-burpsuite-plugin.war https://

cspdl.broadcom.com/shared/static/

logqjel3p6nnqvq9oogb118ubs50h3jo.war?

LCK=ent.box.com

MD5 8d2246fa5aa96b67441211bf6b6348ca

Click Download Button

More Information

Configure a Burp Suite Endpoint

You configure a Burp Suite plug-in endpoint either for the initial setup, or whenever a change to the configuration is

required.

You are familiar with Burp Suite.

You have the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

The manifest for the Burp Suite plug-in is http://<host>:<port>/cdd-burpsuite-plugin/manifest.json .

308

Continuous Delivery Director 8.5

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the Burp Suite plug-in.

4. Configure the following input parameters:

•

Burp Suite Server URL

Specify the URL to access the Burp Suite web server and log in to Burp Suite Enterprise Edition.

•

API Key

Specify a Burp Suite REST API key to initiate scans from your releases and to fail builds if certain issues are

detected.

5. To check the connection to Burp Suite, click Test Connection.

6. Click Add.

Create Scan (Burp Suite)

Scan your web applications automatically for many common vulnerabilities.

One or more Burp Suite endpoints are available.

You can choose scan configurations provided by Burp Suite Enterprise Edition and any custom configurations that your

organization has add to Burp Suite.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

TIP

Values: To define a value, do one of the following actions:

•

To select from a list of possible values, type an at sign "@" in the field

Example: Deploy Tomcat

•

To select from a list of built-in tokens (reusable placeholders that are used to create generic workflows),

type a percent sign "%" in the field

•

Type free text

•

Enter a combination of free text and tokens

Input Parameters

•

Site

Specify the site on which you want to perform the scan.

NOTE

You can only specify a site that is configured in Burp Suite Enterprise.

•

Scan Configuration

Specify one or more comma-separated scan configurations.

NOTE

The scan configurations available in the drop-down list are preconfigured in Burp Suite Enterprise Edition.

•

Severity

(Optional) Specify a severity level for detected issues to fail the scanning task.

NOTE

Issues are classified as High, Medium, Low or Information. These classifications reflect the likely impact

of each issue for your organization.

309

Continuous Delivery Director 8.5

3. Click Create.

Checkmarx Plug-in

Scan your Checkmarx source code for vulnerabilities from your release pipeline.

Plug-in Version 1.0-5

Checkmarx is the leader in application security testing. This plug-in integrates with Checkmarx source code and supports

the following tasks:

•

Create Scan

•

Create Scan using CxFlow

Supported Versions

This plug-in was validated against Checkmarx.

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-checkmarx-plugin-latest.tar.gz

https://cspdl.broadcom.com/shared/static/

tzj6vaz60oko8whf8a8kbg9axlp1z0z2.gz?

LCK=ent.box.com

MD5 9d459c42eb9da00c89b9d7b51c4f1fc9

Click Download Button

More Information

Configure a Checkmarx Endpoint

You configure a Checkmarx plug-in endpoint either for the initial setup, or whenever a change to the configuration is

required.

You are familiar with Checkmarx.

You have the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the Checkmarx plug-in.

4. Configure the following input parameters:

•

URL

Specify the CxSAST URL to log in to Checkmarx.

•

Username

310

Continuous Delivery Director 8.5

Specify the CxSAST username.

•

Password

Specify the CxSAST password.

•

Rally URL

Specify the Rally URL.

•

Rally Token

Specify the Rally token.

•

Git Repository URL

Specify the Git repository URL.

•

Git Token

Specify the Git token.

•

Git Namespace

Specify the Git Namespace name.

•

Git Repo Name

Specify the Git Repo name.

•

Git Branch

Specify the Git branch.

•

Git Application Name

Specify the Git app name.

•

Use Proxy

Specify this option to connect to a remote endpoint through a proxy server.

5. To check the connection to Checkmarx, click Test Connection.

6. Click Add.

Create Scan

Scan your web applications automatically for many common vulnerabilities.

One or more Git endpoints are available.

You can scan the projects source code that your organization has add to Checkmarx.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

Input Parameters

•

Team Name

Specify the team name.

Use % prefix for tokens. You can also use free text alone or together with tokens.

•

Project Name

Specify the project name.

Use % prefix for tokens. You can also use free text alone or together with tokens.

•

Is Incremental

Specify whether the requested scan is incremental or full scan.

•

Is Public

Specify whether the requested scan is public.

•

Force Scan

Specify whether the requested scan is public.

311

Continuous Delivery Director 8.5

3. Click Create.

Create Scan using CxFlow

Scan your web applications automatically for many common vulnerabilities using CxFlow.

One or more Git endpoints are available.

You can scan the projects source code that your organization has add to Checkmarx. You can also configure the Rally

workspace and project to report the code scan results.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following parameters:

Input Parameters

•

Team Name

Specify the team name.

Use % prefix for tokens. You can also use free text alone or together with tokens.

•

Project Name

Specify the project name.

Use % prefix for tokens. You can also use free text alone or together with tokens.

•

Rally Workspace

Specify the Rally workspace name.

Use @ prefix to load an external list of values or use % prefix for tokens. You can also use free text alone or

together with tokens.

•

Rally Project

Specify the Rally project name.

Use @ prefix to load an external list of values or use % prefix for tokens. You can also use free text alone or

together with tokens.

•

Advanced

Specify the additional options on Task Failure.

–

(Default) Wait for user action or run on failure phase if found.

Pauses task and either waits for user action or runs an on-failure phase if found.

–

Automatically Skip Task.

–

Always Wait for User Action

Automatically pauses tasks until user action. Does not run on-failure phase even if found.

•

Ignore Failure When Skipping Task

Specify this option to allow promoting the build to the next phase, regardless of task failure.

CAUTION

This option can compromise build quality.

3. Click Create.

Coverity Plug-in

This plug-in lets you check the health of your application by importing the security items reported by Coverity.

312

Continuous Delivery Director 8.5

Plug-in Version 1.0-5

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-coverity-plugin.war https://

cspdl.broadcom.com/shared/static/

vlnk1mykw7eljr9hbtwcuhjra7l4qdog.war?

LCK=ent.box.com

MD5 59b219779e77558ab600610f7aea54d0

Click Download Button

Configure a Coverity Plug-in Endpoint

Before you begin:

•

You are familiar with Coverity.

•

You have been granted the “Can create endpoints " permission.

•

<host>:<port>/cdd-coverity-plugin/manifest.json .

To register the Coverity plug-in, do the following:

1. From the Administration menu, click Endpoints | Add Endpoint.

2. In the ADD ENDPOINT dialog, select Coverity plug-in.

3. Configure the following endpoint parameters:

- Coverity URL - specifies the Coverity URL

- Coverity Username - specifies the Coverity username

- Coverity User Password - specifies the password or authentication key for the Coverity user

4. Click Add.

Get Security Issues

This plug-in lets you import security issues and to generate security reports for the specified application version.

1. Select Security, then select Adaptive Security Sources.

2. Select the Application and the Application Version.

The New Test Source button is activated.

3. Click New Security Source.

4. Fill in the following fields:

–

Select the Source Name

–

Plug-in - Select Coverity (Get Issues)

–

Endpoint - Select a Coverity endpoint.

–

Input Parameters:

- Project Name - Specify the project name in Coverity

- View Name - Specify the view name in Coverity

- Issue Type - Choose Coverity security item categories. The values are used to filter issues from Coverity.

Possible values are 'Quality', 'Security', and 'Various'

313

Continuous Delivery Director 8.5

- Split security items by issue occurrences - Determines if multiple security items are created for issues with

multiple occurrences.

–

Tags (optional): you can tags the security source for reporting and filtering purposes

–

Send Vulnerability Notifications To: Specify recipient/s for vulnerability notifications

–

Severity Level Notifications: Determine the level of Severity included in the vulnerability notification sent by

Continuous Delivery Director. If left empty, no notifications are sent.

–

First Occurrence: For recurrent security source, the time displays the first event.

–

Chose the repeat pattern to schedule recurring issues retrieval.

5. Click Create.

Cucumber JVM Plug-in

This plug-in lets you easily add Cucumber Java-based features as test suites to your release pipeline.

Plug-in Version 1.4.1-21

This plug-in integrates with Cucumber-JVM, a pure Java implementation of Cucumber. The Cucumber for Java plug-in

is containerized and supports Adaptive Testing functionality. You can import features from Cucumber-JVM to run as test

suites within release pipelines. This plug-in provides you with a Cucumber test automation framework for Java-based Git

and SVN builds that is open-source and application-independent.

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-cucumberjvm-plugin.tar.gz

https://cspdl.broadcom.com/shared/static/

nsdugmft4kj9o5j4nknwdzephr5mslod.gz?

LCK=ent.box.com

MD5

9dd72ff855ad353d5efaa19eba5c2a9a

Click Download Button

Download Docker Image from Customer Support Portal Yes

Download TAR file from Customer Support Portal for customers

who cannot use docker pull

Yes

Change History

The following update was made for plug-in version 1.4.1-21:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following update was made for plug-in version 1.4.1-20:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following update was made for plug-in version 1.4.1-19:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following update was made for plug-in version 1.4.1-18:

314

Continuous Delivery Director 8.5

•

Bugfix: Skipping the test execution for feature with plus(+) sign in their name.

The following update was made for plug-in version 1.4.1-17:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following update was made for plug-in version 1.4.1-16:

•

Added support for multiple glue packages.

The following update was made for plug-in version 1.4.1-15:

•

Added log for the file write operation.

The following update was made for plug-in version 1.4.1-14:

•

Bugfix: Missing Link to Report for skipped test suites.

The following update was made for plug-in version 1.4.1-13:

•

Added support for the log messages.

The following update was made for plug-in version 1.4.1-12:

•

Bugfix: Import fails to retrieve all features.

The following update was made for plug-in version 1.4.1-11:

•

Bugfix: Import fails to retrieve all features defined in the Source Control.

The following update was made for plug-in version 1.4.1-9:

•

Bugfix: Import fails when the feature name contains SPACE characters.

The following update was made for plug-in version 1.4.1-6:

•

You can now view a test execution log that is updated in real-time to see which Cucumber tests are executed at any

given time. The execution log is updated in real-time so if problems occur in a test run, you can examine the log to

determine whether to stop or continue with the test execution.

NOTE

This feature is only available for plug-in version 1.4.1-6 and higher and is not backward-compatible.

The following update was made for plug-in version 1.4.1-5:

•

Bugfix: Links to the error and debug logs are not generated when tests complete.

The following update was made for plug-in version 1.4.1-4:

•

You can now specify system properties when importing test suites. To support this change, a System Properties input

parameter was added to the Get Test Assets task.

The following updates were made for plug-in version 1.4.1-3:

•

You can now specify the location of the settings-security.xml file. This improvement is essential in environments

where users do not have control over the home directory (such as a continuous integration farm, where each

project may have its own settings.xml configuration except for settings-security.xml). To support this change, a

Settings Security File Path input parameter was added to the Get Test Assets task.

•

When a Get Test Assets task fails, the error message now contains a URL linking to the import log file. This

enhancement helps users trace the root cause of a task failure. Previously, the error message did not contain full

information for troubleshooting purposes.

The following update was made for plug-in version 1.4.1-2:

•

Bugfix: When test execution failed for a Cluecumber custom report, the link to the associated report was not

generated.

315

Continuous Delivery Director 8.5

The following update was made for plug-in version 1.4.1-1:

•

Support was added for custom SSL TrustStore files. These files contain only those certificates trusted by the client.

These certificates are CA root certificates, that is, self-signed certificates.

The following update was made for plug-in version 1.4.1:

•

A new execution parameter, Custom Reports, has been added to the Get Test Assets task, with the following

options, Default, Maven Cucumber Reporting, and Cucumber. This field lets you store and present custom

cucumber reports based on the project pom.xml settings.

The following update was made for plug-in version 1.3.2:

•

Support was added for importing Cucumber JVM repositories with multiple projects. To support this enhancement, two

new import parameters have been added to the Get Test Assets task: Settings File Path and Update Snapshots.

The following update was made for plug-in version 1.3.1:

•

Bugfix: A missing Maven POM file error was invoked when trying to import from a subfolder.

The following updates were made for plug-in version 1.3:

•

Two new parameters, Settings File Path, and Update Snapshots were added to the Run Adaptive Testing task.

•

Bugfix: Import test suites failed, because of missing Two new parameters, Settings File Path, and Update Snapshots

were added to the Run Adaptive Testing task.

The following update was made for plug-in version 1.2:

•

A new parameter, Cucumber Tags was added to the Run Adaptive Testing task.

The following update was made for plug-in version 1.1:

•

Support was added for missing values in the 1.x report.

More Information

•

Set Up the Cucumber JVM Plug-in

•

Configure a Cucumber JVM Endpoint

•

Get Test Assets (Cucumber JVM)

Set Up the Cucumber JVM Plug-in

•

You have a working knowledge of Docker.

•

A Linux machine is provisioned with Docker Engine installed and an OS user has been created whose UID/GID are

1010/1010 and a home folder created at /home/cdd/. For more information, see Set Up Containerized Plug-ins.

•

The docker remote API port (4550) is open. For more information, see Set Up Containerized Plug-ins.

•

A Tomcat 8.5 server is installed with the containerized-manager plug-in deployed.

•

The Tomcat server is owned and run by an OS user whose UID/GID are 1010/1010 .

•

You are working with JVM (Java Virtual Machine) 8 or 11.

1. Download and load the Docker image, using one of the following methods:

•

NOTE

Use this option if you are unable to use docker pull

From the command line, enter the wget command listed in the Download Options section in Cucumber for Java

Plug-in. For example:

wget -O cdd-cucumberjvm-plugin-v1.4.1-5b131.tar.gz https://cspdl.broadcom.com/shared/

static/hr9mykdy7wwrg287ns1eumuua6obhikx.gz?LCK=ent.box.com

316

Continuous Delivery Director 8.5

Enter:

docker load -i <the gz file name>

•

Connect to https://support.broadcom.com/enterprise-software/download-center.

Select either Continuous Delivery Director or Continuous Delivery Director SaaS and click the Docker button.

Follow the on-screen instructions to pull the image to your localhost.

2. In the settings.properties file under /home/cdd/.cdd/conf/, add the following lines:

cdd.plugins.containerized.<plugin name>.container.image_name=<repository>:<tag>

cdd.plugins.containerized.cucumberjvm.container.volumes.artifacts.volumes=dependencies:/home/cdd/.m2

IMPORTANT

You must update the following line every time you update this plug-

in:cdd.plugins.containerized.<plugin name>.container.image_name=<repository>:<tag>

cdd.plugins.containerized.cucumberjvm.container.image_name=docker-release-local.artifactory-

lvn.broadcom.net/com/ca/cdd/march2021/plugins/cucumberjvm:115

cdd.plugins.containerized.cucumberjvm.container.volumes.artifacts.volumes=dependencies:/home/cdd/.m2

3. Restart the containerized-manager service.

cd /opt/apache-tomcat-8.5.49/webapps

rm -rf containerized

ls -ltr

4. Register the new plug-in using the following manifest URL: http://<plugin-server>:<port>/

containerized/plugins/cdd-cucumberjvm-plugin/manifest.json.

Configure a Cucumber JVM Endpoint

You configure the Cucumber JVM plug-in endpoint either for the initial setup, or whenever a change to the test build

configuration is required.

You are familiar with Cucumber JVM.

You have the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

The manifest for the Cucumber JVM plug-in is http://<host>:<port>/cdd-cucumberjvm-plugin/

manifest.json .

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the Cucumber JVM plug-in.

4. Configure the following input parameters:

•

Build Tool

Specify the tool used to manage your project builds.

•

Version Control System

Specifies the version control system where your source project resides.

•

Git/SVN Project URL

Specify the URL to access the Git or SVN project repository.

•

Git/SVN Username

317

Continuous Delivery Director 8.5

Specify the user name to access GitHub or SVN

•

Git/SVN Password

Specify the password to access GitHub or SVN

5. To check the connection to Cucumber JVM and to the source control system, click Test Connection.

6. Click Add.

Get Test Assets (Cucumber JVM)

This plug-in lets you import test suites into the Adaptive Testing Catalog.

1. Select Tests, then Adaptive Testing Catalog.

2. Specify the Application/Business Application and the Application Version/Business Application Version.

The menu next to the application/business application name and version is activated.

3. Select Get Test Assets.

4. Fill in the following fields:

NOTE

Use the @ symbol in the following fields to select from a dynamic list of entities associated with the selected

project.

•

Test Source Name

•

Plug-in

Select Cucumber JVM and Import Tests (Cucumber JVM).

•

Endpoint

Select a Cucumber JVM endpoint.

•

Project Base Directory

Specify the relative path to the project base directory. This is the location of the project pom.xml. Default is blank

which indicates that the current directory is the project root folder.

•

Branch

Specify the branch name.

•

Features Folder

Specify the relative path of the folder where the required features are located. Features are the equivalent of test

suites. The specified folder path must be relative to the project base directory.

•

Glue

Specify the glue for the features.

•

Cucumber Tags

(Optional) Specify a list of cucumber tags.

Example:

(@Demo or @Sanity) and not @Ignore

•

Settings File Path

(Optional) Specify an alternate path to the user settings.xml file.

•

Settings Security File Path

(Optional) Specify an alternate path to the settings-security.xml file.

•

Update Snapshots

(Optional) Select this option to force a check for missing releases and updated snapshots on remote repositories.

•

System Properties

(Optional) Specify a Java system property to include information about the current configuration.

318

Continuous Delivery Director 8.5

Example: To configure all security-related debugging options, enter the string: \"-

Djava.security.debug=all\". To enable detailed error and debug logs, add switches such as -X and -e.

•

JVM Parameters

(Optional) Specify space-separated JVM parameters to customize individual instances.

Example: \"-Dtest.HOST=google.com\" - Overrides the IP address or hostname of URL used by the browser

to execute tests. To enable detailed error and debug logs, add switches such as -X and -e.

•

Tags

Select or create one or more tags to label the imported tests.

The test results for the specified build appear on the Adaptive Testing Results page, together with links to the

associated reports in Cucumber JVM.

Cucumber for Ruby Plug-in

This plug-in lets you easily trigger Cucumber acceptance tests automatically from your releases.

Cucumber is a popular tool that developers use for testing software. Cucumber executes test specifications written in a

human-readable language called Gherkin and produces reports indicating whether the software behaves according to the

specification.

The Cucumber plug-in is containerized and supports Adaptive Testing functionality. This plug-in provides you with a

Cucumber test automation framework for Git builds that is open-source and application-independent.

Plug-in Version 1.4-1:

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-cdd-cucumberruby-

plugin-latest.tar.gz https://

cspdl.broadcom.com/shared/static/

xu6202fu099lmq0gyy1lwfeqk1jpu2t7.gz?

LCK=ent.box.com

MD5 55fe53594ce957e165b2cad800863d2f

Click Download Button

Download Docker Image from Customer Support Portal Yes

Download TAR file from Customer Support Portal for customers

who cannot use docker pull

Yes

Prerequisites

•

A Linux machine is provisioned with Docker Engine installed and an OS user has been created whose UID/GID are

1010/1010 and a home folder created at /home/cdd/. For more information, see Set Up Containerized Plug-ins.

•

The docker remote API port (4550) is open. For more information, see Set Up Containerized Plug-ins.

•

A Tomcat 8.5 server is installed with the containerized-manager plug-in deployed.

•

The Tomcat server is owned and run by an OS user whose UID/GID are 1010/1010 .

319

Continuous Delivery Director 8.5

What's New

The following updates were made for plug-in version 1.4:

•

The plug-in name was changed to Cucumber for Ruby. This plug-in supersedes the previous Cucumber plug-in.

•

This plug-in now executes all the test suites that are selected by the Test Advisor in batch mode. Additionally, if the

user decides to run all tests, all test suites are run in batch mode, regardless of whether the test suites are selected by

the Test Advisor.

•

Support for Apache Subversion repositories was added.

Set Up the Cucumber Plug-in

1. Connect to support.broadcom.com with your Broadcom support account and continue to https://

support.broadcom.com/enterprise-software/download-center.

2. Select either CONTINUOUS DELIVERY DIRECTOR or CONTINUOUS DELIVERY DRCTR SAAS and click the

Docker button. Follow the on-screen instructions to pull the image to your localhost.

3. Create the following folder structure under the user /home/cdd/ directory:

mkdir /home/cdd/.cdd

mkdir /home/cdd/.cdd/logs

mkdir /home/cdd/.cdd/conf

mkdir /home/cdd/.cdd/artifacts

mkdir /home/cdd/.cdd/certificates

4. Create a settings.properties file under /home/cdd/.cdd/conf/ and add the following lines:

cdd.plugins.containerized.container_engine.home_folder=/home/cdd/.cdd

cdd.plugins.containerized.container_engine.port=4550

cdd.plugins.containerized.container.volumes.artifacts=/home/cdd/.cdd/artifacts

cdd.plugins.containerized.container.volumes.logs=/home/cdd/.cdd/logs

cdd.plugins.containerized.cucumber.container.image_name=cdd.packages.ca.com/com/ca/cdd/v720/7.2/plugins/

cucumberruby:101

5. Restart the containerized-manager service.

6. Register the new plug-in using the following manifest URL: http://<plugin-server>:<port>/

containerized/plugins/cdd-cucumber-plugin/manifest.json.

Configure the Cucumber Plug-in

You configure the Cucumber plug-in either for the initial setup, or whenever a change to the test build configuration is

required.

Endpoint Parameters

The following parameters are required to create an endpoint:

•

Version Control System

Specify the version control system where your source project resides, either Git or Apache Subversion (SVN).

•

Git/SVN Repository URL

Specify the URL to access the Git or SVN project repository

•

Git/SVN Username

Specify the user name to access GitHub/SVN.

320

Continuous Delivery Director 8.5

NOTE

For GitHub, only required if the Git repository is not a public repository.

•

Git/SVN Password

Specify the password to access GitHub/SVN.

NOTE

For GitHub, only required if the Git repository is not a public repository.

To check the connection to Cucumber and to the version control system, select Test Connection. The Test Connection

action returns the following results:

•

Success

The connection was successful

•

Failure

The connection failed

Tasks

The Cucumber plug-in supports the Run Adaptive Testing task type. You can import test suites from the Adaptive Testing

Catalog through the Get Test Assets command.

For more information, see Setting Up the Test Module

Prerequisites:

•

One or more application versions are specified.

•

One or more Cucumber test suites exist for the application versions specified.

Branch

Specify the branch name.

Root Folder

Specify the relative path to the folder where the required features are located. When left empty, tests are imported from

the root folder.

Tags

Select one or more tags to execute test suites tagged with your selection. Leave empty to execute all the test suites under

the application version.

Example: Type ro to retrieve all test suites tagged with labels beginning with ro, such as robot.sanity.test

Build/Commit id

Specify the commit ID (Git) of the code to test.

TIP

To select from a list of available tokens, enter the percent sign (%) in the task field.

Run a subset of test suites selected by the Test Advisor

Choose this option to run only the test suites that the Test Advisor selects. The test advisor selects test suites that are

likely to fail fast.

Docker Plug-in

This plug-in lets you deploy Docker images to run and to remove containers, and to run commands within containers.

Optionally, for the Run Container task, you can run a readiness probe to notify you when the container is ready to accept

traffic.

321

Continuous Delivery Director 8.5

Plug-in Version 1.3-5

Supported Versions

The Docker plug-in supports the core Docker solution.

For more information, see the Docker documentation at https://docs.docker.com/.

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-docker-plugin.war https://

cspdl.broadcom.com/shared/static/

bmmohlxc3qq6lm4z6q5fs8nf6tjfewz6.war?

LCK=ent.box.com

MD5 443048a09cabf4b18124002d50b6feda

Click Download Button

What's New

The following updates were made for plug-in version 1.3-5:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 1.3-3:

•

Added support to define a schema for the "Check Readiness" option.

The following updates were made for plug-in version 1.3-1:

•

In the Run Container task, only one port is exposed. The expected behavior is that all ports listed in the Ports to

Expose input parameter are exposed.

The following updates were made for plug-in version 1.3:

•

Bugfix: The plug-in should present the build number during deployment immediately on first polling from CDD and not

just when the task completes.

The following updates were made for plug-in version 1.2:

•

A new Remove Image task lets you remove specified images from a container.

The following updates were made for plug-in version 1.1:

•

Support was added for Java 11.

Configuration

Manifest URL

For plug-in registration, use the following Docker manifest URL:

http://<plugin-server>:<port>/cdd-docker-plugin/manifest.json

322

Continuous Delivery Director 8.5

Endpoint Parameters

To create endpoints, provide the following parameters:

•

Docker Engine Host

Specify the Docker Engine hostname

•

Docker Engine Port

Specify the Docker Engine port

•

Registry Host

Specify the path to the Docker registry host

Example: my.registry.address:port/repositoryname

•

Registry User

Specify the username to authenticate to the Docker registry.

•

Registry Password

Specify the password to authenticate to the Docker registry.

To check the connection to Docker and to GitHub, use the endpoint Test Connection option. The Test Connection option

returns the following results:

•

Success

Both connections were successful

•

Failure

One or more connections failed

Tasks

The following task types are available in the Docker plug-in:

Run Container

The Run Container task contains the following fields:

Input Parameters

•

Image Name

Specify the Docker image name.

•

Container Environment Variable

Specify environment variables that are available to processes running inside the container

Example: CDD_DATABASE_NAME=name1,X=2,Y=3

•

Ports to Expose

Specify one or more ports to expose to provide services or to listen on.

Example: 9090:8080,7070:7070

•

Map Volumes

Enter a list of comma-separated key:value pairs.

Values: key = name of the volume on the host machine, and value = the path where the file or directory is mounted

in the container.

Example: myvol7:/root/cdd/home/myvol7/.cdd

•

Container NameSpecify the name of the container to run.

•

Build Number

Specify the build number associated with the Docker image provided.

•

Readiness Relative Path

Specify the relative path to the readiness probe REST call.

Example: GET https://www.cdd.com/cdd/execution/0000/v1/readiness

•

Initial Delay (in Seconds)

Specify the number of seconds after the container starts to run before the readiness probe is initiated.

323

Continuous Delivery Director 8.5

Minimum: 1

•

Probe Frequency

Specify how often (in seconds) to perform the probe.

Default: 10 (seconds)

Minimum: 1

•

Timeout (in Seconds)

Specify the number of seconds to elapse after which the probe times out.

Minimum: 1

•

Maximum Number of Failed Attempts

Specify the maximum number of failed probe attempts allowed before the task is failed.

Minimum: 1

Output Parameters

•

Container ID

Specifies the container ID.

Remove Container

The Remove Container task contains the following fields:

Input Parameters

•

Container ID

Specify the ID of the container to remove.

Run Command in Docker

The Run Command in Docker task contains the following fields:

NOTE

If the run command execution status is 0, the task will be marked as finished, otherwise, the task will be marked

as failed.

Input Parameters

•

Image Name

Specify the Docker image name.

•

Command

Specify a single command or a call for execution file.

Example: ls; /home/{username}/run.sh

•

Arguments

Specify arguments to append to the command.

Example: -a -l ...

Remove Image

The Remove Image task contains the following fields:

Input Parameters

•

Image

Specify the name or the ID of the image to remove.

Example: alpine:latest

324

Continuous Delivery Director 8.5

DX App Experience Analytics Plug-in

This plug-in lets you monitor application usage, user interactions, and performance.

NOTE

Formerly known as CA App Experience Analytics

Plug-in Version 1.1-4

Supported Versions

The DX App Experience Analytics plug-in supports the core DX App Experience Analytics SaaS solution.

For more information, see the DX App Experience Analytics documentation at App Experience Analytics - Getting Started.

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-axa-plugin.war https://

cspdl.broadcom.com/shared/static/

aa78fm4w8bye780u9xkpxxgpqdizmakw.war?

LCK=ent.box.com

MD5 9f929cf6b0efb992cb8cef1070207062

Click Download Button

Change History

The following updates were made for plug-in version 1.1-4:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 1.1-3:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 1.1-2:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 1.1-1:

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 1.1:

•

Support was added for Java 11.

Configuration

325

Continuous Delivery Director 8.5

Manifest URL

For plug-in registration, use the following CA App Experience Analytics manifest URL:

http://<plugin-server>:<port>/cdd-axa-plugin/manifest.json

Endpoint Parameters

The following parameters are required to create an endpoint:

•

URL

Specifies the URL to the DX App Experience Analytics instance

Example: https://axa.ca.com

•

API Key

Specifies the DX App Experience Analytics access token that you obtain as the result of the Authentication API

For more information, see the DX App Experience Analytics REST API documentation.

Example: a3bdf820-1eaf-47f4-acd6-7caca7fe17d2

To check the connection to DX App Experience Analytics, use the endpoint Test Connection option. The Test

Connection option returns the following results:

•

Success

Both connections were successful

•

Failure

One or more connections failed

Tasks

The following task types are available in the DX App Experience Analytics plug-in:

Monitor

Use this task to monitor application performance, usage, and user experience in real time

This task requires the following fields:

TIP

To load a list of external values, enter the commercial at sign @ in the task field. To select from a list of available

tokens, enter the Percent sign (%). You can also use free text alone or together with tokens.

Input Parameters

•

Application

Specifies the name of the application

Value: Application name as registered with DX App Experience Analytics

•

Time Range

Specifies the time range to monitor the application.

Value: Dynamic value. Enter the commercial at sign @ to load the possible dynamic values: last hour, last 12 hours,

last 24 hours, last week

DX App Synthetic Monitor Plug-in

This plug-in lets you control site and application performance monitoring from your release pipeline.

326

Continuous Delivery Director 8.5

Plug-in Version 1.2-17

DX App Synthetic Monitor (formerly CA App Synthetic Monitor) helps you ensure that users can access sites and

applications 24/7, regardless of their location or the device they are using. This tool lets you check site and application

performance and quickly pinpoint problems. Unlike most monitoring tools that depend on actual user transactions, DX App

Synthetic Monitor mimics real user behavior with synthetic transactions. These transactions take place 24 hours a day

through a global network of nearly 100 monitoring stations across six continents.

For more information about DX App Synthetic Monitor, see DX App Synthetic Monitor SaaS documentation.

Download Options

Use one of the following options to download the latest plug-in version:

Method Info

wget wget -O cdd-asm-plugin.war https://

cspdl.broadcom.com/shared/static/

rrl57ag5vizhq7ftprucd69xpnufghud.war?

LCK=ent.box.com

MD5 dc1efadd7e4522557e1d7053cc8e9829

Click Download Button

You can use this plug-in to perform the following tasks:

•

Activate and Deactivate Monitors

•

Activate and Deactivate Monitors by Tags

•

Run Rule Check

•

Run Rule Check by Tags

•

Set and Remove Maintenance Time Window

To connect to a specific instance of DX App Synthetic Monitor, add an endpoint. For more information, see Configure a DX

App Synthetic Monitor Plug-in Endpoint.

Change History

The following updates were made for plug-in version 1.2-17

•

Bugfix: The 'Exceed Max Size' error appears for change monitor state.

The following updates were made for plug-in version 1.2-16

•

Updates to the monitor's attributes. Users can update the monitor with the new application URL.

The following updates were made for plug-in version 1.2-15

•

Bugfix: Activate Monitor by Tag fails due to large response.

The following updates were made for plug-in version 1.2-14

•

Security Enhancements - Updated the 3rd party libraries that are part of the package.

The following updates were made for plug-in version 1.2-13

•

Bugfix: Wrong time in Set Time Window.

•

Bugfix: Change Monitor State for multi Folders fails.

327

Continuous Delivery Director 8.5

The following updates were made for plug-in version 1.2-9

•

Rule check for multiple monitors or by tags.

•

Activate/Deactivate multiple monitors or by tags.

•

Create/remove immediate maintenance window.

The following updates were made for plug-in version 1.2-8

•

Bugfix: Importing a Release DSL using the activate/deactivate task fails due to invalid character.

The following updates were made for plug-in version 1.2-2

•

Bugfix: The plug-in does not handle empty dynamic values as expected

•

Bugfix: Dynamic fields are not working as expected.

The following update was made for plug-in version 1.2-1

•

The default URL In the ASM API URL endpoint parameter was deprecated and was not yet updated with the latest

URL.

The following update was made for plug-in version 1.2

•

A Run Rule Check task was added to enable users to check that the target machine is up and running and available

for use in the release pipeline.

The following update was made for plug-in version 1.1

•

To improve usability, the Activate or Deactivate parameter in the Activate and Deactivate task was changed from a

checkbox to a dropdown with Activate and Deactivate options.

Configure a DX App Synthetic Monitor Plug-in Endpoint

You are familiar with DX App Synthetic Monitor.

You have the Can create endpoints permission.

1. Register the plug-in as described in Manage Plug-ins.

The manifest for the DX App Synthetic Monitor plug-in is http://<host>:<port>/cdd-asm-plugin/

manifest.json .

2. From the Administration menu, click Endpoints > Add Endpoint.

3. In the ADD ENDPOINT dialog, select the DX App Synthetic Monitor plug-in.

4. Configure the following input parameters:

•

ASM API URL

Specify the DX App Synthetic Monitor API URL. Syntax: https://api.asm.saas.broadcom.com

•

Authentication Method

Select a method to authenticate to the DX App Synthetic Monitor API.

Basic

–

Username

Enter the user name to log into DX App Synthetic Monitor.

–

Password

Enter the API password set in the DX App Synthetic Monitor account settings.

NOTE

This is not the password you use to log into DX App Synthetic Monitor.

Bearer

–

Access Token

328

Continuous Delivery Director 8.5

Specify the access token you use to access DX App Synthetic Monitor.

•

Use Proxy

Select this option to connect to a remote endpoint through a proxy server.

–

Proxy Server URL

–

Proxy Server Username

–

Proxy Server Password

5. To check the connection to DX App Synthetic Monitor and to the source control system, click Test Connection.

6. Click Add.

Activate and Deactivate Monitors

This task lets you activate and deactivate monitors from a DX App Synthetic Monitor instance in your release pipeline.

One or more DX App Synthetic Monitor endpoints are available.

DX App Synthetic Monitor offers several types of monitors that you can use to measure page performance. Monitors

also check whether your website is serving or providing content correctly. If performance issues occur, the monitors send

alerts.

You can activate/deactivate more than one monitor in a single task.

You can specify multiple monitors either by selecting dynamic values (@) or by using free text alone or together with

tokens (%) to enter a list of tags separated by commas. While using the dynamic values (@), do not combine with a string

or token (%). The task performs a rule check for the specified monitors every second according to the polling interval time.

The task fails if the defined timeout period for all the monitors does not set the status to 0.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following input parameters:

•

Activate or Deactivate

From the dropdown, select either Activate or Deactivate to activate or deactivate the monitors.

•

Folder Name (Optional)

Specify the name of a folder in which the monitors are located.

•

Monitor Name (Optional)

Specify the name of a monitor to activate/deactivate. If left empty, all the monitors in the selected folder will be

activated/deactivated.

WARNING

If the folder name and monitor name are not specified, all the monitors will be activated or deactivated.

3. Click Create.

Activate and Deactivate Monitors by Tags

This task lets you activate and deactivate monitors from a DX App Synthetic Monitor instance in your release pipeline.

One or more DX App Synthetic Monitor endpoints are available.

You can activate/deactivate more than one monitor using tags. A new task "Activate/Deactivate monitors by Tags" has

been added to support this feature.

You can specify multiple monitors either by selecting dynamic values (@) or by using free text alone or together with

tokens (%) to enter a list of tags separated by commas. While using the dynamic values (@), do not combine with a string

329

Continuous Delivery Director 8.5

or token (%). The task performs a rule check for the specified monitors every second according to the polling interval time.

The task fails if the defined timeout period for all the monitors does not set the status to 0.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following input parameters:

•

Activate or Deactivate

From the dropdown, select either Activate or Deactivate to activate or deactivate the monitors.

•

Folder Name (Optional)

Specify the name of a folder in which the monitors are located.

•

Tags

Specify one or more tag names (separated by comma). The Rule Check will be performed on all the monitors

associated with one of the specified tags. Use % prefix for tokens. You can also use free text alone or together with

tokens.

3. Click Create.

Run Rule Check

Check whether, after a monitor is activated, that the target machine is up and running. This check validates that you can

proceed with a release.

One or more DX App Synthetic Monitor endpoints using basic authentication are available.

NOTE

This task works only with basic authentication; bearer authentication is not available.

This task performs a rule check for the specified monitor every number of seconds per the polling interval time. If the

status is not set to 0 by the defined timeout period, the task fails.

You can perform Rule Check by specifying a tag and not a specific monitor (or list of monitors). You can specify the tag

names and execute the rule check on all the monitors associated with this tag.

Even if you specify a monitor with more than one tag, the Rule Check executes once only.

You can specify more than one tag name using comma-separated. The Rule Check performs on all the monitors

associated with one of the specified tags. Use % prefix for tokens. You can also use free text alone or together with

tokens. There won't be dynamic values for the tags, as ASM does not have an API to get the list of tags.

1. In a release, create an automatic task as described in Create Automatic Tasks.

2. Configure the following input parameters:

•

Monitor Name

Specify the name of a monitor to check (you can enter more than one monitor to check). To select from a list of

available monitors, enter the commercial at symbol (@) in the task field. To use a token, enter a percent '%' sign.

•

Poll Interval

Specify the period of time in seconds after which the status will be checked. Default: 5.

•

Timeout

Specify the timeout in seconds. Default: 180.

3. Click Create.

Run Rule Check by Tags

Check whether, after a monitor is activated, that the target machine is up and running. This check validates that you can

proceed with a release.

One or more DX App Synthetic Monitor endpoints using basic authentication are available.

330