Versioning of flows at runtime?

I'm considering use of NR as a graphical programming component inside a larger project, to allow end users to more easily maintain some of their own logic/code/rules.

However, we would need to support versioned flows, where all prior versions were still deployed and accessible. Access to run a versioned flow would be through an http REST/JSON post, with the version of the flow that should be executed included in the payload. We need to be able invoke prior versions against historical data. This would also facilitate testing, since the we could run a new version and compare results against a run of an old version. I could see this also being useful if you were supporting a larger network of IOT devices, where some older ones needed a prior version of a flow.

Ideally, the versioned flows would be stored in a database (ie. MongoDB), and would load at NR startup.

Trying to avoid having to determine and run the version to run manually in a parent flow. We would like to save a new version of a flow to the database, tell the NR server to reload and have all versions in the dbms be loaded dynamically.

I suppose we could dynamically generate a parent "version selector" flow from the database information, building the parent JSON using a code generator.

This node: node-red-contrib-flowman looks like it might help to accomplish a lot of what we're looking for. Can anyone confirm if it works with the latest 1.0 NR version?

Has anyone tried to do something like this? Any existing nodes that might help accomplish this both from a versioning and dbms storage of flow json definitions perspectives?


Have you thought of using the Projects option?

Don't think that Projects will help us. From what I've gleaned of Projects, it's more source code versioning using Git. That isn't what we need/want.

We need runtime versioning of flows, that is, the ability have multiple versions of a flow (different rules) running at the same time.

Manually implementing that, and maintaining a top level "version selector" flow would be a colossal pain.

The flowman node would go a long way to addressing our dynamic runtime versioning requirements, if it still works with the latest NR 1.0 version.

The flowman node hasn't been updated for almost a year, not the sort of thing I would trust for a production environment. I'm sure you will get answers to your problem in due course.

It would be nice if NR had built in/supported nodes for flow addition/deletion equivalent to flowman. :wink:

There are a few issues in how flows share global elements that may be an issue as well. There is another thread that talks about this as well.

I am actually developing my own 'audit' flow process, to keep deployed flows to remote devices consistent with the official version of said flows, I keep in a central repo. My working idea is just track the flow tab name, any version # included in that name, say like "Flow A 1.0" or "Flow B 2.0" for example.

The local audit flow watches the flows*.json file for updates/changes, then does a simple check sum parsing the flows*.json file in the ~/.node-red directory, as an extra check with the tab name and version #.

The local audit flow sends applicable information to a DB, and a 'monitor' auditor flow does the comparison and reporting as applicable.

This idea is not a backup and restore solution, just an audit tool. Of course I could send the flow content to the DB as well, but as I noted, there are issues because such is not a complete backup.