Developing with integration lifecycle management

Develop integrations faster with stable changes

Use cloning to speed up integration creation and change management. You can clone an existing integration to create an exact copy, make changes in the source integration, and systematically pull the changes into the cloned integration, or vice versa. Snapshots are automatically created whenever you merge changes, which helps you return to a previous state if you want to revert your changes.

Integration Lifecycle Management (ILM) works alongside your broader DevOps practice — see DevOps at Celigo — and supports the way integration specialists build and maintain integrations.

Key concepts

• Clone – An exact copy of an integration, including its flows, steps, scripts, and configurations.
• Revision – A version of an integration's configuration that Celigo creates automatically as you make changes.
• Snapshot – A restore point that Celigo creates automatically each time you merge changes, which you can use to revert to a previous state.
• Pull request – The review step you use to merge changes from one integration into another.

Imagine your original integration is running in production. You can create a clone (integration A) (Amazon-NetSuite → Clone of Amazon-NetSuite). In this case, integration A is the clone integration and original is the source. You can keep the two integrations in sync or introduce new changes in the source and then pull the new changes into your clone or vice versa.

You have now recreated several flows, steps, scripts, and configurations. Everything is copied. Now, to introduce a new change, use the source integration, test everything, and merge new changes to integration A using a pull request.

Approach: Original integration → Integration A clone of the original integration. Example: Amazon-NetSuite → Clone of Amazon-NetSuite

You can also create multiple clones of the original integration. This is helpful when you want to create and maintain a large number of integrations based on a common source integration. In this case, you can introduce changes in the source integration and then pull changes into any of the clones.

Tip: Don't forget to repopulate the lookup cache data after reverts.

How ILM supports integration development teams

ILM is designed for how integration teams actually work: in parallel, across multiple environments, with room to test safely and roll back if needed.

Here's what that looks like end to end. You clone a production integration into a development environment and start building. Because each clone is independent, other integration specialists can work on their own clones, or their own flows within a shared clone, without conflicting with your changes.

As you make changes, Celigo creates a revision automatically. You update a flow or API, test it in your development environment, and compare the source and destination versions to confirm exactly what changed before moving forward. When you're ready, you pull and merge the approved changes into the next environment — development to QA, QA to staging, staging to production — promoting the change through each stage in sequence rather than pushing directly to production.

Every merge creates a snapshot, so you always have a revision history to fall back on. If something breaks after a promotion, you can retain and restore a prior revision to roll back the change.

This workflow isn't limited to flows. APIs and Tools — whether built in Tool Builder, embedded in API Builder, or used as a step within a flow — are lifecycle-managed resources too, so you can clone, revise, and promote them the same way.

Because cloning requires Manage access and promotion happens through pull requests rather than direct edits, ILM also helps prevent unauthorized changes from reaching your production integration — nothing gets there without going through review and merge first.

Examples: Managing integrations in non-production environments

Legacy production and sandbox licenses

In legacy Production and Sandbox environments, changes in one environment can affect both environments. This behavior doesn't apply to accounts on the multi-environment license, where each environment maintains its own isolated resources.

Migrations from the legacy Production/Sandbox license to the new multi-environment license are underway. Your account has not migrated to the new multi-environment license if you can toggle between environments.

Below are various examples:

One integration lifecycle in two environments

In this example, you create a development environment, create an integration and flows, clone the integration into Production, and pull changes from development to Production.

1. Create your non-production environment as referenced above. In this example, we've created a Development environment. Now you have your original Production environment and your newly created Development environment for a total of two environments.
2. Create an integration and create your flows in your new, non-production environment. In this example, it's a development integration in the Development environment.
3. After you've developed your integration, you can clone it into your Production environment. Remember, for ILM specifically, you cannot clone a singular flow. You must clone the entire integration.
4. Pull your changes from your Development environment to your Production environment.

One integration lifecycle in three environments

In this example, you're creating a development and QA environment, creating an integration and flows in Development, cloning the integration into QA, cloning the integration from QA to Production, and pulling changes from Development to QA, then Production.

1. Create your non-production environment as referenced above. In this example, we've created a Development and QA environment. Now you have your original Production environment and your newly created Development and QA environments for a total of three environments.
2. Create an integration and create your flows in your new, non-production environment. In this example, it's a development integration in the Development environment.
3. After you've developed your integration, you can clone it into your QA environment. Remember, for ILM specifically, you cannot clone a singular flow. You must clone the entire integration.

4. Then, clone your QA integration into your Production environment. Now you have a daisy-chained integration and can make changes from Development to QA and QA to Production. You cannot pull from Development directly to Production.

   Important: If you clone your integration from Development directly to Production, you won't be able to create the daisy-chained development lifecycle later by adding a second non-production environment. If you clone from Development to Production, you can't add a QA environment and integration later and move changes from Development to QA to Production since the clones will be distinct.

5. Pull your changes from your Development environment to your QA environment.
6. Then, pull from QA to Production.

Develop integrations with no sandbox or a legacy sandbox environment

You can extend the above concepts to manage work across multiple teams, even if you don't have a legacy sandbox or multi-environment license.

Legacy sandbox environment

You can further separate work across different environments and make changes in both the sandbox and production environments. In your sandbox, you can develop your integrations, test any changes, and pull those stable changes into your production integration.

Tip: Use the sandbox environment to create Development tiles and QA tiles and the Production environment to create a Production tile.

No non-production environments

Tip: Provide Manage access only to Developers in Development tiles and Manage access to QA only in QA tiles.

You can separate work into development and QA teams by cloning each integration and granting the Development and QA teams access to the cloned tiles. When development work is complete, the QA team can pull in changes for testing, and once everything is working, the final changes can be pulled into the original integration.

You can also manage development by assigning a clone to each developer for independent development. When a developer completes a task, they can pull the changes into the original integration. Later, other developers can pull from the original integration to incorporate the changes into their own clones.

Related resources

• Pull changes from one integration to another
• Use multiple environments with Integration Lifecycle Management (ILM)
• Create and manage APIs using API builder
• Introduction to Celigo tools