Group/Team development workflow

#1

Hi guys,

I'm looking into using Node-RED in a team development environment and was curious if anyone had a workflow for this already? I'm currently using version control for most of the basic stuff and I have flowfilepretty, project options enabled.

Is there any good way to share subflows between a team? I'm aware that you can import and export subflows, but it can be tedious for every person on a team to constantly get a new subflow file and import it every time someone adds/fixes something on it.

Any group development experiences/advice/workflows would be great.
Thank you.

0 Likes

#2

Node red isn't great for multi user teams tbh. You are probably going to need to have a production environment and then each dev having their own environment. Deployments will likely be copied and pasted flows. You could share snippets/flows in a repo though to make it easier to share to each dev.

0 Likes

#3

yeah I figured as much. I'll probably be doing something along the lines of that. Hopefully I can figure out more ways to make it work.
Thanks for your response.

0 Likes

#4

That isn't entirely unreasonable. Why would you want people modifying your production environment directly?

That really isn't a good idea. If you are using projects with version control, then deployments can be automated from git and you should not copy and paste into production.

Probably the main piece we're missing is an easy way to sharing flows between developers - including subflows. This is why an overhaul of the library is on the roadmap.

Any feedback you have about what sort of workflows you'd like to see in this area is invaluable to us. We need that feedback to make sure we focus on the right things.

Nick

0 Likes

#5

We've been using Node-RED in a multi-user setup for a while now.
In our latest projects, we've been (sadly) avoiding subflows because they are hard to maintain between different flows, eager to see the revamp ! Same would go for function nodes.
The way we work now is to have a set of common code as a module that we require in global context.
We've also been avoiding projects because we rely heavily on settings.js to do various pre-launch tasks. The project usually has a main settings.js file that controls which flow to load and modifies settings/env vars dynamically according to which host runs the project. I've been using the projects feature home for my small flows but can't seem to make it scale well to larger projects yet.

0 Likes

#6

Sorry for the late reply.

You're right, a way to share sub flows across multiple projects would be great, so that multiple projects can reference the same instance of a subflow. Then if someone wants to fix a bug on a subflow, they can easily update it and everyone's projects that are dependent on that subflow will use the updated instance.

git automated deployments also make sense as you never want to be editing your production environment.

An easy way to unit test subflows and flows would be great but I would need to think about this more for a better solution.

You could then probably set up a simple development pipeline using teamcity and some deployment software to automate building, unit testing and deployment.

0 Likes

#7

On the flip side if someone introduces a bug in he subflow everyone would now be effected by my it...

1 Like

#8

We have started to kick around ideas on how unit tests can be integrated into a flow. Very early days, but hopefully more on this later this year.

Yup - for example https://medium.com/@knolleary/creating-a-node-red-deployment-pipeline-to-ibm-cloud-9a8e9d5113de

0 Likes

#9

I'd like to see an intermediate solution that stores the one big flows_xxx.json file as a directory of files, one for each editor "tab"/flow (and one for each subflow). Since our team has decided to restrict our work to individual tabs, this would perhaps allow some automation around sharing and backing up our individual parts of the flow. Coupled with a git repo, this would also allow us to more easily know when changes happened to certain flows (which are pretty closely related to our customer delivered features).

I can imagine that having a directory tree structure to hold the flows would overlap quite a bit with the library implementation. We are very interested in how we can better manage the library file structure (renaming dirs/files, moving parts around, deleting unused files, etc).

1 Like

#10

I meant in that we should take the approach that node red is more like vscode/an editor than it is a repository in itself. Sure you can all work on the same server but merging all the time could potentially come with pitfalls!

Agreed, I've not really had much chance to build a pipeline for nr to be honest, a bit of short comment by myself tbh.

0 Likes

#11

Although early days for us with NR in a multi-developer environment, at first blush the idea idea of being able to manage separate flow tabs as separate files, including sub-flows in one or more directories also appeals. So + 1

0 Likes