Rate this feature
Included in the May 2022 release Integration Lifecycle Management features help you build and manage integrations by supporting snapshots, pulling changes, and reverting changes.
- Examples - Approaches for setup
- Revisioning an integration
|Clone||A clone is an identical copy of an integration that you can modify independent of the original integration.|
|Conflict||Conflicts are competing changes between your current integration and the remote integration.|
|Current||A current integration is an integration that you work on and into which you pull changes from a remote integration.|
|Merge||When you merge integrations, you accept changes and update resources from the remote integration to your current integration. Merge is a part of a pull.|
|Original||An original/source integration is an integration from which you create a copy or a clone.|
|pageGenerators (PG or Exports)||Exports are called pageGenerators (PG) in the JSON structure of your integration flow.|
|Pull||When you pull from a remote integration, you compare the fetched data and merge changes into your current integration.|
|pageProcessors (PP or Imports)||Imports and Lookups are called pageProcessors (PP) in the JSON structure of your integration flow.|
|Remote||A remote integration is an integration from which you’re pulling changes.|
|Resource||A resource is any import, export, flow, script, or another part of an integration.|
|Restore||If you restore your integration, you’re recovering a previous revision and rolling back to it.|
|Revert||A revert undoes changes and allows you to roll back to a previous revision. You can roll back to any previous pull, snapshot, or revert revision.|
|Revision||A revision can be any of the following types: snapshot, pull, or revert.|
|Sandbox||A sandbox environment is available for testing. If your integrator.io doesn’t include a sandbox, you can test in your existing environment or contact Celigo to learn more about adding a sandbox.|
|Snapshots||A snapshot is a copy of an integration state that you create at any point to use as a backup when required.|
|Source||A source/original integration is an integration from which you create a copy or a clone.|
Integration lifecycle management provides the following benefits:
- It helps you to build and test your integrations in a continuous improvement cycle.
- It helps you adhere to good practices of monitoring and managing changes while building your integrations collaboratively.
- It supports a quick and flexible approach to building integrations. You can clone an integration any number of times in the production or sandbox environment, give any number of individual users access to any of the clones, make and test changes, then pull changes in any of the clones into the production integration.
- It reduces the risks associated with making changes to mission-critical integrations. integrator.io implicitly maintains revisions, and you can always revert to a previous revision at any time.
You can consider these guidelines when planning your integration lifecycle management.
- Build or update an integration, preferably in a sandbox environment.
- Create a clone to build and test changes to an integration. For example, before you build a new feature or enhancement, create a clone in the sandbox environment. If you don’t require or have a sandbox environment in integrator.io, create a clone in the production environment. Note that when developing large features that have different teams using different development/testing clones, it’s good to establish guidelines for merging and pulling changes so that teams work well together.
- Create snapshots as a backup. For example, when you have to fix a critical bug within a short time, you might want to build and test the fix on the integration in the production environment itself. In such a case, snapshots are extremely useful as a backup to quickly revert to a stable state if you run into an issue.
- Create a clear access policy for effective collaboration. To understand access and permissions, see Manage account and integration permissions.
Here are some examples of approaches and workflows to set up and manage your integration lifecycle management.
Note: There are no predefined integration lifecycle workflows, and these examples are merely for guidance. You have to create an integration lifecycle routine based on your company's system development process requirements.
You can use the Revisions tab to monitor and manage changes that anyone in your team makes to an integration over time (based on the access and permissions in an account or integration).
integrator.io creates a revision when you perform a pull, revert, or snapshot operation in an integration. Every revision is associated with a unique identifier (ID).
Important: You can only perform one revision at a time (a snapshot, a pull, or a revert).
You can spontaneously create a snapshot as a backup when you’re working on changes. This backup is especially useful when you are working on an integration in your production environment. Integrator.io creates a "snapshot" revision when you click the Create snapshot button.
If you run into an error or other issue, you can revert to a snapshot revision and return to a stable state.
You can clone an integration, make changes, and then create a pull after successfully building and testing changes. When you pull changes, integrator.io creates a “pull” revision. There are four statuses for a pull: In progress, failed, canceled, or completed.
integrator.io automatically saves the integration state before any change is made and after all changes are merged and your pull is completed. You can revert to either of these integration states within a completed pull revision.
integrator.io automatically creates a snapshot of the integration before any changes are made and after changes are merged and your pull is completed. You can use these snapshots to roll back to a previous integration.
If you have any conflicts, see Review and resolve conflicts.
When you run into issues and want to undo changes, you can roll back to a previous revision of a pull, snapshot, or revert. This is called a “revert” revision. There are four statuses for a revert: In progress, failed, canceled, or completed.
integrator.io automatically saves the integration state before any change is undone or reversed and after all changes are undone or reversed and your revert is completed. You can always roll back to either of these integration states within a completed revert revision.
The Revisions list displays the history of every revision made in an integration because of a snapshot, pull, or revert. You can view details and perform actions on a revision based on the options available when you click the Actions overflow (...) menu of a revision.
The revision list or revision history provides the following information:
|Column||What it shows…|
|Description||The description you provide for a revision when you create a snapshot, pull, or revert like the reason or summary of changes in a revision.|
|Date created||Time at which you create a snapshot, pull, or revert. The time is shown based on your date settings in the following format: DD-MM-YYYY hh:mm:ss|
|Type||Type of revision:
Canceled: You can cancel an In-progress pull or revert revision during the Merge step.
|User||Name of the user who performs the revision.|
|Actions||Actions you can perform on a revision:
In the case of a pull or revert:
You can filter revisions based on user, date created, status, and type. To filter revisions:
- On the Home page, click the integration.
- On the integration page that opens, click the Revisions tab.
- Select a value in the filter fields, such as date created, type, status, or user. You can select a value in any field or all the fields to filter the integrations.
You can view the changes made at the resource level for a pull or revert in the audit logs. You can also filter the audit logs to view changes based on resource, user, and source. To view the audit logs:
- On the Home page, click the integration to open it.
- On the integration page, click the Audit logs tab. You can view the changes or revision details at the resource level.