Skip to main content
Feedback

Deployment

Deployment is the means by which you prepare your processes and deployable components to run and operate in a test or production environment.

Boomi Deployment is similar to traditional software development concepts of building and releasing a product. The deployment functionality performs several important functions:

  • Controls the deployment of specific versions to different runtime environments as part of the development life cycle (for example, “stage” vs. “production”).

  • Manages versioning of processes and other deployable components.

  • Isolates the version of processes running in runtime environments from ongoing changes made on the Build page.

  • Provides full audit history for versioning and deployments.

After you configure and test processes and components on the Build page, the next step is to deploy them to one or more environments. Deployed processes can accommodate full production-scale data volumes, batch processes can be scheduled for automated execution, and listener processes such as API Services and event-driven connectors are activated to receive incoming requests.

Deployable components

In addition to processes, the following types of components can also be packaged and deployed independently:

  • API Proxy
  • API Service
  • Certificate (public X.509)
  • Custom Library
  • Flow Service
  • Process Route
  • Processing Group

Though an independent component may have been included in the configuration of a process or another component, they are stand-alone and are not included during the packaging stage of deployment. Due to this, they must be packaged and deployed independently, providing you more granular control over deployment versioning.

How deployment works

There are two steps to deployment:

  1. Create and manage point-in-time versions of processes or other deployable components. These are called Packaged Components.

  2. Assign those specific versions to one or more environments to be available to run. This is called a Deployment.

The creation of a packaged component is a “snapshot” of the current revision of a process and all its included components (such as maps, profiles, connections, etc.). This packaged component version is isolated from future changes on the Build page, so ongoing configuration changes to the process or other component do not affect it. That version can then move through a development life cycle, such as promoting from a “test” environment to a “production” environment.

note

After you create a packaged component in preparation for deployment, you can share that same packaged process component in the Process Library or add it to an integration pack. You can also add packaged API Service components to an integration pack.

The Deploy menu provides access to the following deployment tools:

  • The Packaged Components option lets you create and manage packaged components for the processes and components that you build.

  • The Deployments option lets you monitor existing deployments and create new deployments.

Deployment workflow

The workflow for deploying a process or component to an environment involves building the component, creating a packaged component, and then deploying the packaged component.

The basic steps to successfully deploying a process or component are as follows:

  1. A developer builds a process or deployable component on the Build page.

  2. A developer or administrator creates a version of the component by creating a "packaged component" from the Build page or the Packaged Component page.

  3. An administrator deploys the packaged component to one or more environments from the Packaged Component page or the Deployments page.

After a packaged component is deployed, you can use the Deployments page to manage your active deployments.

The following illustration shows the basic steps for building and deploying.

Build components along with package components and deploy packages.

An example of a typical deployment workflow

In this scenario, there are two environments, “Test” and “Production”. A typical workflow might be as follows:

  1. A process and related components are created and configured in the Build tab.
  2. Test Mode is used to verify the process is working.
  3. A packaged component, “v1”, is created for the process.
  4. The packaged component “v1” is deployed to the Test environment.
  5. The process is tested more fully in the Test environment with a larger set of data, and an issue found with the field mapping rules.
  6. The map component is modified and retested in the Build tab.
  7. A new packaged component, “v2”, is created for the same process.
  8. The packaged component “v2” is deployed to the Test environment and retested. No issues are found this time.
  9. The same packaged component “v2” is deployed to the Production environment.
  10. Future development continues in the Build tab, but does not affect the packaged component “v2” running in the Production environment.

When you deploy a new version of a process to an environment, the new version replaces the previous version currently running on the associated runtimes. Any in-progress executions will complete with the previous version but future executions will use the new version.

On this Page