Developing with integration lifecycle management

Develop integrations faster with stable changes

Use cloning to speed up the process of creating integrations and managing changes. You can clone an existing integration to create an exact copy, make changes in the source integrations, and systematically pull the new 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.

Tip: To use ILM, you need to clone an entire integration, which requires ‘Manage’ access to the integration. Ideally, you should create integrations with ‘Administer’ access and invite users to the integration based on access level (Manage or Monitor). Then, users with Manage access can create clones.

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.

Sandbox and production integrations

If you have access to the sandbox environment, create an integration in the sandbox first. Then, create a clone in the production environment. When you introduce new changes, make them in the sandbox integration and, once everything is working as expected, pull the newly tested changes into the production integration.

Approach: Original integration (sandbox environment) → Integration A, a clone of the original integration (production environment)
Example: Amazon-NetSuite (sandbox environment) → Clone of Amazon-NetSuite (production environment)

Develop integrations collaboratively

You can extend the above concepts to manage work across multiple teams and environments.

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

You can separate work according to your development and test teams. Simply create clones of each integration and provide access to the cloned tiles based on dev and test teams. When development work is finished, changes can be pulled in for testing by the QA team and, when everything is working, final changes can be pulled into the original integration.

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

You can further separate work across different environments and make changes in both 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 Dev tiles and QA tiles and the Production environment to create Prod tile.