Create applications and processes

5 minute readReferenceAutomation

Advanced model-based deployment in CloudBees CD/RO separate the what, where, and how of release orchestration. This allows you to target different endpoints, like Google GCP or Amazon AWS, without changing the process or the payload. CloudBees CD/RO provides:

  • Different deployment and rollback strategies out of the box, like blue/green, canary, or component vs. whole.

  • The flexibility to schedule deployments based on resource availability or block-out dates.

  • Fine-grained visibility into exactly what is deployed in each environment—​from application version down to artifact version. It also helps in troubleshooting, auditing, and planning.

CloudBees CD/RO Level 1: Deployment Automation

Active subscribers and partners have access to our self-paced training curriculum. This level 1 course teaches the deployment capabilities in CloudBees CD/RO, using a combination of curriculum and hands-on lab exercises. Courses are grouped into learning paths. Register for an applicable learning path based on your role.

Advanced model-based deployment drives application and deployment master component reuse to foster standardized, auditable practices and repeatable enterprise-wide deployment processes. Deployments in previous stages will be repeated exactly in production.

CloudBees CD/RO supports the creation, versioning, deployment, required middleware, and infrastructure details for a complete release package. You can model and version traditional application tiers, microservice applications, and environments to orchestrate the software release flow and also to standardize and automate the deployment of application tiers or microservices between environments.

CloudBees CD/RO makes deployments manageable, reproducible, and reduces errors by modeling traditional and microservices-based applications, their deployment environments, and automating their deployment workflow. The model can be broken into these parts:

  • What: Files or microservices being deployed.

  • Where: Environments where application or microservices are deployed.

  • How: Processes that orchestrate deploying application tiers or microservices to the environment.

Process concepts

At the application (parent) level, you author application processes. When deploying an application, the application process that you select is executed to orchestrate operations against the application. An application process step can be defined as a call to a CloudBees CD/RO plugin, procedure, or component process as well as a direct command, script, a manual task, or a utility function (a higher-order operation than a plugin).

At the component level, processes are used to define the automation steps to perform on the artifact defined in the component details. These processes can be used to deploy, undeploy, or do any other action. Each master component can have one or more component processes, and each process can have specific automation steps. These steps can describe how to perform specific tasks such as publish or retrieve an artifact, stop a server process, copy files, restart the server, and so on. A master component must have at least one component process. You can parameterize the master component processes so that certain behaviors can be achieved when master components are used in an application definition. For example, you can have port number as a component process parameter for a master component, and have different values for the port number in different application models where this master component is used.


Applications are modeled by providing information about their components and defining the processes that orchestrate the deployment of those components. CloudBees CD/RO supports both microservice applications and traditional applications with tiers.

Microservice applications

The diagram below depicts a microservice application.

In a microservice application, you can:

  • Deploy a microservice, using Helm charts, to Kubernetes clusters in different cloud providers.

  • Manage environment inventory visibility for microservice deployments to Kubernetes clusters.

  • Capture service definitions via Helm chart or YAML files.

    • Reference a helm chart via URL.

    • Reference a packaged Helm chart.

    • Ability to provide override values to Helm chart.

  • Deploy a microservice to a pre-provisioned Kubernetes cluster.

    • Support deployment strategies.

    • Support rollback of deployed resources.

  • Collect microservice deployment details and update inventory in CloudBees CD/RO:

    • The deployed container identity: name, URL and version.

    • Helm chart version.

  • Define process steps based on commands or scripts using the CloudBees CD/RO DSL, CloudBees CD/RO REST API, CloudBees CD/RO Perl API, or Groovy. See CloudBees CD/RO Perl API command overview for the commands and code samples.

Traditional applications

The diagram below depicts a three-tiered traditional application with web, application and database server (DB server) tiers.

In a traditional application, you can:

  • Define process steps based on commands or scripts using the CloudBees CD/RO DSL, CloudBees CD/RO REST API, CloudBees CD/RO Perl API, or Groovy API. Refer to CloudBees CD/RO Perl API command overview for the commands and code samples.

  • Create a library of standardized reusable components to promote best practices across the enterprise and speed up application authoring with master components. See Master Components for more information.

  • Save snapshots of the application throughout the software release process. A snapshot is an immutable version of an application with specific artifact versions that can be used to optimize and troubleshoot the application. Refer Capture snapshots for more information.

  • Track changes for non-runtime objects such as projects, applications, environments, processes, components, artifacts, resources, and properties in the change history. Refer to Change Tracking for more information.

Application tiers

An application tier is a logical grouping of components, component processes, and application processes:

  • A component is based on an artifact and contains a reference to that artifact. This can be through the file system or an artifact repository.

  • A component process is a set of actions to be taken on a specific component when the application is deployed. The set of steps in a process can be defined as:

    • Direct commands.

    • Calls to CloudBees CD/RO plugins, procedures, or utility functions.

    • Component operations based on the component definition.

    • Manual steps.

  • An application process is at the application (parent) level and orchestrate operations against the application. The steps in an application process can be defined as:

    • Calls to component processes.

    • Direct commands.

    • Calls to a CloudBees CD/RO plugin, procedure, or utility function.

    • Manual steps.

    • A rollback step to roll back to a previous state or to a specific snapshot.

Properties and parameters

Properties and parameters allow the same application to be deployed to many environments in a repeatable, reliable, and scalable way. They are used extensively throughout CloudBees CD/RO and can be dynamically passed to all operations, including application deployments.

  • Properties provide a flexible and powerful mechanism to manage data during all operations. They can be attached to any CloudBees CD/RO object, such as applications, processes, tiers, components, and credentials. Refer to Properties for more information.

  • Parameters provide a way to get input from users at runtime to deploy the application to a variety of environments. Parameters can be attached to processes, process steps, components in the application. Refer to Define parameters for more information.

Refer to Deployment examples for examples of how to author and deploy an application in the UI.