Skip to main content

Version Your Integrations

In a perfect world, you wouldn't need to version anything for integrations. Your team would get it right the first time they build an integration and no one would ever change anything. Unfortunately, none of us live in a perfect world. Fortunately, we have a good solution for managing component and integration versions.

We have largely built best-practices for versioning into the platform, to ensure that it is easy for your to determine what versions of components and integrations are available but also to know which ones are currently deployed. In addition, there are some steps you can take to make best use of the versioning functionality and we call those out in the following sections.

How integrations are versioned?​

Integrations can be versioned. When you've created/modified and then tested an integration and you click "Save & Publish," the system increments the version by 1. An original integration will have V1, followed by V2, etc.

Integration designer with integration version

Versioning an integration does not automatically deploy that version to consumers of the integration. Automatic deployment could be very bad, since a change to an integration for one consumer might break something for another. Not all consumers may be on the newest version of your integration; some may be using a legacy version of a third-party service which requires them to stay on their current integration version.

Instead, your integration development team decides who gets which version and when — with no need to rely on dev or DevOps to make the updates. Team members can simply select the desired integration version from the available list in the Config Wizard, enter any needed configuration data and click "Next" or "Finish."

Integration designer with instance version

If something should go wrong when you switch a customer to a new version of the integration, you can easily revert to the prior version of the integration by following a similar process. Simply click "Reconfigure," select the correct version of the integration, and click "Save and Deploy" once again.

What can you do with integration versioning?​

Each time you publish a version, you can include a comment (basically a commit message) summarizing the changes.

Ideally (to make maintenance sane), you'll want to keep consumers on newer versions of integrations. To support that, you can mark any version of an integration as deprecated (using the integrations Version History drawer). Once a version is deprecated, it will still show in the list, but will not be selectable by your team for deployment/activation.

If you know for certain that you want all your consumers to be updated to the current version, you can click "Update all Instances" in the version drawer.

Only one version of a given integration can be made available in the Integrations Hub, but that's not automatically updated (since nothing is automatically updated) when a new version is created. You can have your team deploy a new version of an integration internally for testing, but only allow your consumers to update their instances via the marketplace when that QA is complete.