Articles in this section

Use multiple environments with Integration Lifecycle Management (ILM)

Michelle Welch
Updated

Adding multiple environments to an Integration Lifecycle Management (ILM) workflow lets you develop, test, and promote integration changes safely, with each stage of the lifecycle in its own isolated environment. This article is for integration builders who use ILM. It explains why environments improve a lifecycle and walks through a two-environment and a three-environment example. If you use ILM regularly, Celigo recommends creating environments to separate your development, test, and production integrations. For what environments are, see Multiple environments overview.

Why add environments to your lifecycle

Without multiple environments, you build several versions of an integration in the same environment. That works when you have few integrations, but it gets confusing when one environment holds the development, QA, and production versions of the same integration. With multiple environments, each stage of the lifecycle lives in its own environment, so you can keep track of every stage and reduce the risk of pulling changes into your production integration by accident.

Example 1: One lifecycle in two environments

In this example, you create a Development environment, build an integration there, clone it into Production, and pull changes from Development to Production.

  1. Create a Development environment. See Create and manage multiple environments. You now have Production and Development.
  2. In Development, create the integration and its flows.
  3. When the integration is ready, clone it into Production. See Clone an integration. For ILM, you must clone the entire integration, not a single flow.
  4. Pull your changes from Development to Production. When you open the pull, select the source Environment, and then the Integration to pull from.

Example 2: One lifecycle in three environments

In this example, you create Development and QA environments, build an integration in Development, clone it into QA and then into Production, and pull changes from Development to QA and from QA to Production.

  1. Create Development and QA environments. You now have Production, Development, and QA.
  2. In Development, create the integration and its flows.
  3. Clone the integration into QA, and then clone the QA integration into Production. See Clone an integration. The integrations are now chained, so changes move from Development to QA and from QA to Production. You can't pull from Development directly to Production.
  4. Pull your changes from Development to QA, and then from QA to Production.

If you clone from Development directly to Production, you can't add a QA environment between them later — the clones are distinct, so the chained lifecycle can't be created afterward.