Imagine that you have a critical business process running in production. A team member introduces new changes that break the integration. Is there a way to go back to a stable state? Is there a better way to test and roll out new changes? And is there a better way to organize integration development across teams and environments?
Use Integration Lifecycle Management (ILM) to manage the lifecycle of your custom integrations from development to test to production. If you introduce new changes in one integration, you can review the changes, control how you roll them out to their clones, and go back to any previous stable state if you run into issues.
Tip
ILM can be used for any custom integration that you create or any template that you install.
You can set up your ILM workflows in many ways based on your internal processes or change management process. The ILM feature is accessible under the Revisions tab in a custom integration tile. The feature is available at the integration level for all the objects within the integration.
You have detailed audit logs in integrator.io. You can identify who made changes to an integration, when changes were made, and what those changes were. You can identify the same for integration life cycle management activities.
An easy way to implement new ILM practices is by creating backups before making changes. You can use this to roll back to an earlier stable state if you run into integration issues.
Use snapshots to backup your integrations. Create a snapshot when:
-
Making major (or minor) changes to your integration
-
Handing off your integration to a new user
-
Your developer or other technical resource is going to edit your integration
You can also use the revisions API endpoint to automate the backup process or set up a flow to create snapshots once a week or at any desired frequency.
Tip
Snapshots are created automatically whenever you create a pull to merge new changes or revert your revision to an earlier version.
Lookup caches are supported in Integration Lifecycle Management (ILM). All references and mappings are tracked during operations like pull, merge, snapshot, and revert.
ILM operations never include the data stored in your lookup caches. For best results, when you perform an ILM operation that introduces a new lookup cache to an integration (like a pull or revert), manually validate the associated lookup cache in your remote integration before running any flows.
When you clone an integration tile that already includes a lookup cache, you can choose to include the lookup cache entries in the cloned integration, provided:
-
The overall size is under 5 MB
-
The Include data when Lookup Cache is cloned or downloaded box is checked.
In this case, the cloned integration will contain lookup cache(s), with or without data, depending on the option you selected. Subsequent pulls and merges with changes to your lookup cache mappings (excluding lookup cache data) will be fully tracked.
Note
On reverting to older snapshots: If you create a snapshot with a lookup cache, delete the lookup cache, and then revert to the snapshot, the cache data is not included. Instead, an empty lookup cache is generated, and you must repopulate or re-upload the data.
Lookup caches added to a source integration after the integration is cloned are considered new resources. When you next pull and merge the integrations, a corresponding, empty lookup cache is created in the cloned integration. Only the cache mappings are transferred, not the data. You must repopulate the lookup cache data after revisions (like pulls, merges, or reverts). ILM only manages your lookup cache's mappings and transformations, not the data.