OIC: Reverse Versioning Integrations

In this article I introduce a versioning strategy where – probably very unlike you are used to - the integration with the smallest version number is the latest and greatest, making it clear to everyone what the state of development is, and preventing OIC from getting polluted with old versions nobody knows what to do with them anymore.

A new integration typically is created on an OIC DEV environment (instance) as version 1.0.0. Then at some point most people create a version 1.0.1, 1.1.0 etc. It is not uncommon to have a version like 3.4.2 before the first one is promoted to the next OIC environment. Very often many previous versions are still there on the DEV environment and never cleaned up.

This often if not always introduces several challenges:

• While the integration is still being worked but the developer cannot be reached, it is unclear what the latest and greatest version is. You should not just assume it is the one with the highest version number, as that might be just some interim version that will get thrown away. Also, different developers may use different versioning practices if at all.

• When the developer is away for long or has left the project, it can be quite a challenge to determine what can be cleaned up without risking losing useful backups.

• Even for the developer it may not be clear what is what anymore, with a high risk of losing work (been there …).

• When source control is used, the repository tends to get polluted with multiple versions of which most are obsolete (instead of keeping on versioning the same).

I have seen customers with over hundreds of integrations on their DEV instance with around a third of them not being activated an some more than 2 years old. Good luck with cleaning that up!

All this can be prevented by practicing a very simple versioning strategy, which I call “reverse versioning”. 

The few, simple steps for using it are the following:

1. Start your first version as 1.0.0,
2. Work on it until you have developed it to some state you don’t want to lose,
3. If you are using a source control system like Git, commit this 1.0.0 version to Git,
4. Delete any existing, older 1.0.1 version (see next step),
5. Create a new version from the current 1.0.0 as 1.0.1,
6. If it is used by other components or people, activate the 1.0.1 version. At this point in time this is the last-known-good version,
7. Now here it comes: return to step 2 by continuing development on the 1.0.0 version (instead of the 1.0.1 or any other next version).

You create the 1.0.1 version for 2 reasons:

• As a convenience so that you can easily revert to the last-known-good version if you want to undo your latest changes.
• To have something activated when the integration is being used.

If step 3 above is applicable to you then you can also retrieve it from Git but restoring a backup from Integration Composer is easier of course. If you don’t have source control in place (poor you!) then you could consider creating a few extra backups like 1.0.2 but be very restrictive with that.

Now what if some next time you are supposed to increase the version number, for example because the previous one is already in production? In that case the version used in step 1 above will be that new version and when you use version control you can delete the previous one from DEV.

All this has the following advantages:

• For every developer it is clear what the status of an integration is:
• If there is a 1.0.1 version next to a 1.0.0 one, then you know it is under development.
• If there is no 1.0.1 version, then the 1.0.0 is the latest and greatest.
• When there is an inactive 1.0.1 version while the 1.0.0 has been activated more than a working day ago, you can safely throw it away. After all, that should only exist when the integration is under development.
• When you use a version control system you only commit the 1.0.0 version, so no redundant versions in there.
• When promoting a new release to the next environment, it is clear which versions to use (the ones with the smallest version number). No need to start asking around.
• It supports a consist way of using semantic versioning (https://semver.org/)
• No surprise for Applications and Systems Administrators regarding unexpected gaps in version numbers.

I have introduced this practice on all my latest projects, and from experience I can tell you reversion versioning it easily picked up by any developer, and once in place I have not had a single problem with people losing code, not knowing what to promote to the next environment, or the OIC instance getting polluted with obsolete versions. Everybody wins!