Adding multiple environments to an Integration Lifecycle Management (ILM) workflow lets you develop, test, and promote integration changes quickly and safely, with each stage of the lifecycle in its own isolated environment. This article explains why environments improve an ILM lifecycle and walks through two- and three-environment examples. If you use ILM regularly, Celigo recommends creating environments to separate your development, test, and production integrations.
Without multiple environments, you'd build several integrations in the same environment. That works when you don't have many, but it gets confusing when one environment holds multiple versions of the same integration — development, QA, and so on. With multiple environments, you can separate each stage of your lifecycle into its own environment, keep track of every stage, and reduce the risk of accidentally pulling changes into your production integration.
Example 1: One lifecycle in two environments
In this example, you create a Development environment, build an integration and flows there, clone the integration into Production, and pull changes from Development to Production.
- Create your new environment (see Create and manage multiple environments). In this example, it's a Development environment, so you now have your Production environment and a Development environment.
- Create an integration and create your flows in your Development environment.
- After you've developed the integration, clone it into your Production environment (see Clone an integration). For ILM, you can't clone a single — you must clone the entire integration.
- 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 and flows in Development, clone into QA, clone from QA into Production, and pull changes from Development to QA and then QA to Production.
- Create your new environments (see Create and manage multiple environments). In this example, you create Development and QA, so you now have Production, Development, and QA.
- Create an integration and create your flows in your Development environment.
- Clone the integration into your QA environment, then clone your QA integration into Production (see Clone an integration). You now have a daisy-chained integration and can move changes from Development to QA and from QA to Production. You can't pull from Development directly to Production.
If you clone your integration from Development directly to Production, you can't create the daisy-chained lifecycle later by adding a second new environment. Once you clone from Development to Production, you can't add a QA environment in between, because the clones will be distinct. - Pull your changes from Development to QA, then pull from QA to Production.
Flows and Integration Lifecycle Management (ILM)
What happens to flows that are running when migration starts?
Before migration begins, the system checks for in-progress flows. If any are found, you're notified and can cancel the or wait for it to finish before proceeding.
Are my flows automatically re-enabled after migration?
Flows are disabled after migration. As part of post-migration setup, you can enable all flows that were enabled before migration, or enable them individually. Flow schedules are preserved.
If I use Enable all, does it enable every flow?
No. Enable all re-enables only the flows that were active in your legacy Sandbox before migration. Flows that were already disabled remain disabled.
Can I still use ILM after migration?
Yes. ILM works the same way after migration. You can continue to sync changes between related integrations and revert to previous revisions.