Hey team! Could we implement a pre-commit or dry-run testing feature before deploying in Node-RED (similar to n8n's test workflow execution)? This would allow us to test our changes safely without disturbing other active users working on different flows or risking overwrite conflicts in a shared environment.
I would be careful comparing apples with oranges: n8n is an agent orchestration platform (if I understand their marketing correctly) and Node-RED is a event driven data orchestration platform. Even if they (and a lot of other visual flow applications) look the same, they actually have different underlying paradigms.
A typical n8n workflow is far more high-level than an Node-RED workflow and therefore tend to contain less moving parts than a typical NR flow.
NR has the idea that if the editor has no warnings (i.e. browser-side validation is ok), then you're good to go and can deploy a flow. If there is a logical error in your flow, that's you bad not Node-REDs. So the time for checking your flows is before deploying your flow.
Also as NR flows have so many moving parts, it's hard to create a simulated environment where everything can be tested. This can, effectively, only be created by the user themselves since they know how their system should work.
The problem there is that you can't save your flow without deploying it. This is the real issue I think. I can tinker around with my flow but I can't save it because saving it will also deploy it. So you might well have to keep your browser open or export all your flows using the export functionality which exports the in-browser flow, not the deployed on server flow.
For me, I worked around this by having a visual versioning system so that I can export flow tabs to git without deploying them. I use an integrated plugin for this purpose and not the export dialog (too many clicks). I use several NR instances, each connected to the same versioning system so that I can import/export flows between them and test them on development systems before deploying production systems.
This facilitates me in setting up development setups to test flows and only deploying to production once everything has been tested. Because the import/export is integrated into my Node-RED installations, I don't have to play around with the inbuilt import/export dialogs, it's all just a couple of clicks in the end.
Agreed.
The "traditional" way for any IT system to handle this is to have a test system. Your live system is often made read-only to prevent any changes. Changes are pushed at an OS level from test (or pre-production) to production.
This also lets you handle security issues such as malicious or unintended changes since you can compare your live system with a secured copy on a regular basis. If there is a difference, you can have a decision point to push the secured, known-good copy flow to production again. This is especially helpful where Node-RED is deployed to edge compute platforms such as customer or site specific IoT controllers where you may not fully control the physical security.
