Versioning resources

Avatar
OL Learn Blog Data

At long last, OL Connect allows you to keep track of all the changes you make to your templates and data mapping configurations. You no longer have to save your files under different names each time you implement a change, nor do you need to keep a separate record of your changes to remember who did what, and when.

Git started with versioning!

( Bad pun, I know… )

Starting with OL Connect 2022.1, the Designer and the DataMapper can use Git integration to manage Projects. A Project is essentially a folder that contains a collection of related files. For instance, if you were to implement an invoicing solution based on OL Connect, you might have an Invoice template, a Collection Letter template and a Dashboard template, each of them having an associated data mapping configuration. Those 6 files would constitute a Project.

To start versioning your files, you won’t even need to install Git, one of (if not the) most popular open source version control system (VCS) in the world. All the Git libraries needed already come prepackaged inside OL Connect.

So… head over to the OL Connect Designer and click on the main menu’s Project option, then select New…

From there, you can create a new folder where your resources will be stored. The folder name will actually become the name of the project. Now you can open an existing template or data mapping configuration (or create a new one) and as soon as you save the file in that new folder, it automatically becomes part of the project. Let’s assume we’ve saved our 6 files in the project. We can now take a look at the status of each file in the project by selecting the Project files option from the Project menu.

This opens up a new pane displaying all files in the project.

Committing files

Notice how each file icon is overlayed with a “+” sign. This indicates that these files have been added since you opened the project. The only thing left to do is to commit those files to the project. The act of committing effectively creates a new version for all changed resources in the project. To commit the files, go back to the Project menu and click the “Commit…” option.

Now this is where the power of versioning lies: each time you commit files, you have to provide a comment. This is vitally important, as it will allow you, later, to readily identify each version as you browse through the project history.

That’s it: you’ve created the first version for the files in the Invoicing project. When you look back at the Project Files pane, you’ll notice that the “+” sign has disappeared, meaning that the current files are now in sync with the repository maintained by Git.

If you make any change to any of these files, a “*” marker will reappear, but only for the files that have changed since the last commit. So let’s make a change to the Dashboard.ol-datamapper file and save it. Remember that at this stage, the changes have been saved but they have not yet been committed, so we’ll need to do that. As a commit message, we’ll simply explain what changes were implemented:

Commit title: New Billing Address field
Commit body: Extract the new “Billing Address” field that was added to the data files by IT.

That’s it: a second version of that data mapping configuration has now been committed.

Time travel

We can now take a look at the Project history to navigate through all versions of the project. Click on the Versioning history option in the Project menu to open the Versioning history pane:

But then your IT calls you and says “hold on, we’re having issues adding the Billing Address field into all data files, so don’t extract it until we fix everything on our end!!!“. 

No problem! You simply have to revert your last changes by right-clicking on the previous commit in the Versioning history and selecting the Restore this version option. This immediately restores the previous version. But since it’s a change to your existing file, it means you have to commit it again. And this time, your commit message would be something like “Reverted billing address change until IT fixes issue“.

And when IT finally calls you and says “All fixed, you can now proceed with extracting the billing address field“, do you then have to redo the changes you implemented before in the data mapping config? Nope! You just restore the version that included that change:

So even though you’re moving backward in your history, you don’t have to redo a thing except restore a version that was previously committed. That means you can even start working on upcoming changes and commit them ahead of time because you always have the option of going back to the version that’s currently in production.

Conclusion

Versioning is a game changer for managing OL Connect projects. If you’re familiar with Version Control Systems, you have already realized that there’s a lot more we can do with this feature… and you’re right! This is just stage 1 of the feature, we are already working on implementing additional features that will make their way into the software in upcoming versions.

Tagged in: git, history, Versioning



Leave a Reply

Your email address will not be published. Required fields are marked *

All comments (4)

  • Darren Keenan

    I like it. Is there a way to publish to GitHub in the cloud?

    • Philippe Fontan

      Not yet, this will be available in the second phase of the versioning feature, scheduled for 2022.2. I’ve already seen a preview of it, and it works just great. It will allow you to publish to GitHub, BitBucket or Azure DevOps.

  • Jean-Cédric Hamel

    Re-using your example of Billing addresses in the Invoices, what if I already made the extraction changes, then made some more addition and then, my IT department tells me not to do the extraction of the Billing addresses? Will reverting to a previous version that didn’t have it loose my recent changes done after the Billing addresses extraction?

    • Philippe Fontan

      Yes, if you go back to a previous version, you obviously lose whatever was implemented after that version. However, if you commit (and document) your changes often enough, then it becomes fairly easy to re-do some of the work. This is no different than with source code.

      Also, remember than if you do go back to a previous version, you still have the option of going “forward” once again, because anything you’ve implemented is always recorded somewhere.

      At some point, we plan on introducing branches into the versioning feature. This would allow you to always develop any new feature on a branch, which would then make it easier to prune&graft from the versioning tree. But we’re not there yet.