Best Practices - Subflow versionning between multiple NR instances

General
1

Hi everyone

We are using multiple NR instances and we have designed a few tenth of subflows to manage API calls to our system + other re-usable pieces of flows.

We now have a lot of trouble to manage coherency and versionning of those subflows across the different instances.
For exemple we have a staging/dev instances where we design large flow before moving them to one of the production platform. So when we move that flow, we have to import the flow + all changes we have done to the base subflows.
However sometime we are making small changes directly on a production platform so we should normally send the change back to the staging/dev platform so it can stay the reference.

So there is many ways of breaking the things, loosing changes and reverting improvements.

Because it is subflows that are exported/imported, and not nodes that are installed, I don't see how we could leverage Git for example.

Do you have same similar problems ?
What would be your suggestion for best practices ?

Thanks

2

Hi @Barbudor

I think your answer may lie in the fact, Sublows, can be packaged like any other module.
this would allow everything you need - Including Git and semantic versioning

https://nodered.org/docs/creating-nodes/subflow-modules

1 Like
3

Thanks a lot @marcus-j-davies that looks great and we will investigate this

Does that means that those distributed nodes cannot be edited on the Node-RED where they are deployed but only on the NR where they are designed and package (just like "normal" nodes) ?

Thanks

4

They could be edited anywhere, but the source will be in node_modules just as for other installed nodes.

What is not clear to me, is how one would, on the originating machine, edit the subflow and update the packaged node.

5

Not in the traditional sense.

When they are installed, they will appear in the palette as regular nodes. Users are not able to see or modify the flow inside the subflow

But as @Colin pointed out - like any other Node Installed, they can still be modified if users were that determined, by looking inside the packaged contents.

One thing to note and this might be one for @knolleary

The example given in the docs, states the exported Subflow is structured with the below order.

[
   { "id": "Node 1", ... },
   { "id": "Node 2", ... },
   ...
   { "id": "Node n", ... },
   { "id": "Subflow Definition Node", ... },
   { "id": "Subflow Instance Node", ... }
]

But when I tried this - mine was.

[
   { "id": "Subflow Definition Node", ... },
   { "id": "Node 1", ... },
   { "id": "Node 2", ... },
   { "id": "Node n", ... },
   { "id": "Subflow Instance Node", ... } /* <- this should be removed before publishing */
]

EDIT:
Evan though the docs states this is a manual process, Its JSON, so can likely be automated to a high degree - obtaining the Export JSON will still be required, but you can run that through a flow it's self, to re-structure it with ease.

6

In theory - it would only require to create a new Subflow.json file (via the documented methods), then bump the version in package.json and re-package?

You don't really need to use NPM either, on the basis an agreed "current version number" can be referenced in your org - if any machine is running an old version number - install the latest tgz via the UI.

I could well be over simplifying this of course, I have yet to try this myself :sweat_smile:

7

Thanks
Definitively need to spend time on this

I'm not looking for a protection against determined users :smiley:

However as the production instances are running in AWS ECS container services without any SSH available, it's not immediate (feasible but not immediate)

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.