Node-RED / Team collaboration / GIT / Code repository

[Mattias Marder]

Hello,

What is the best practice for using a code repository with multiple team members working on the same Node-RED project.

What files do you commit?
Do you export nodes?
How do you manage different projects?

Our code contributions consists of both flows, subflows and nodes.


Thanks,
Mattias

[Julian Knight]

If you need multiple Node-Red projects from the same computer, the easiest way is to avoid the default installation method and use "embedded" mode installation. This follows the standard pattern for node.js and NR simply becomes another module to be installed.

Then you can follow your usual node.js development practices. Commit the package.json & the startup js file. In the startup you will have the NR config (unless you offload it to an included file) and you should change the default user folder from ~/.nodered to something more useful, I generally use ./.nodered (so under the project folder).

Obviously you need to also commit your flows file as a minimum but note that it may well contain private data so be careful if committing to a public repository like GitHub. Also commit the configuration nodes file if you want all members of the team to share one set.

When working in embedded mode, you actually have two ways of installing other nodes. You can add them to the main project package.json or you can npm init in the user folder and install modules there. I generally use the former as I think it is simpler.

Unfortunately, I don;t think there is an easy way to merge flows changes from multiple people. Although the flows file is JSON, it changes even for tiny things such as moving a node slightly. So it isn't easy to have multiple devs working on a single set of flows.

Exporting of nodes is generally done manually from the admin UI, not sure if there is an API method. It would certainly be nice if there were an easier and automatable way of exporting/importing a selection of nodes. You could save exported nodes to a JSON file as they are always valid JSON (I think).

[Nicholas O'Leary]

Mattias,

To version control your flow file, the best thing to do is enable the 'flowFilePretty' option in your settings file - that will cause node-red to save the flow as formatted json, rather than squashed onto a single line. That makes it somewhat more git-friendly.

But this is a whole area we know we need to improve - and something I want to look at in the near future. Things such as:

 - version control built into the editor

 - enabling multiple people to edit the same running instance at the same time

 - improved import/export of flows and a shared library

 - ... and others that don't spring to mind right now

Any thoughts and feedback you have based on your experiences would be welcome.

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

[Dave C-J]

Julian,

the easiest way to install multiple Node-RED instances to play with is to use Nat's template project - https://github.com/natcl/node-red-project-template - but that is not the same thing at all as multiple people collaborating on a single project.

[Julian Knight]

Hmm, interesting. I hadn't seen that.

However I'm not sure I would entirely agree that it is the easiest way. I'd have to think about it a bit more but the advantage of doing it the embedded way is that you end up with an installation that is systemd/npm/git (ish)/node.js friendly with no workarounds needed. 

Nat's method is certainly clever but it spawns a sub-process - not only might that be using additional resources in a more complex setup, I'm not certain whether you might not be able to end up with spawned processes that are not correctly terminated. (sorry lots of negatives in that sentence!)

Actually, you don't need Nat's method for a template project - I will try to publish an alternative when I get a chance. I should have done that before really so thanks to you and Nat for prompting me.

Great thing about node.js - many ways to achieve things. Bad thing about node.js - many ways to achieve things! ;-}

[Nathanaël Lécaudé]

Just to clarify,

I don't usually use the start.js / npm start method to run instances in production.  I mostly use this when I'm developping new nodes/flows and I need to work on multiple projects on the same machine at the same time. (which happens quite often these days)

When I go in production I usually use pm2 to load node-red, which gets me thinking I could also put the pm2.json file I use in the template too.  The embeded appoach is interesting too, I used it in the electron-node-red example: https://github.com/natcl/electron-node-red

[Julian Knight]

Thanks Nat. I was going to put something about keeping things running in the doc but decided it was probably too long already. Might be worth me creating some WIKI pages. Or maybe something on the flows site.

I seem to have had lots of problems with pm2 - mainly performance related - on both Windows and Linux. So I tend to use systemd on Linux at least for live instances. If I were allowing remote access to NR, I would front with an NGINX proxy running Passenger Phusion to keep things secure, efficient and running. I don't run any live instances on Windows so it isn't a problem, I just let things crash! If needed, I think there are some tools to run node.js apps as a Windows service.

[Dave C-J]

The other nice thing about Nat's template is that you just edit the package.json and add a flows.json and away you go... AND you can also do the same with his electron template... and the Node-RED bluemix starter template.. which is nice and consistent .

[Julian Knight]

Can you not do that with both Nick's and my suggestions too?

Made me think though that I should include the ./.nodered folder and a blank ./,nodered/flows.json file in the template?

[Nathanaël Lécaudé]

I'm not sure what happens when it's running embeded, but with the template I did, Node-RED will create the flows file the first time you run it so it might not be necessary to include a blank file.

[Julian Knight]

Yes, that happens with all installs. It would, however, be marginally easier for someone to distribute a working NR project if the template included at least the user folder so that the flows and config json files could be dropped straight in without having to worry whether the folder existed. Just a minor thing really.

[Nathanaël Lécaudé]

In my version the root is actually the user folder, I wanted it to be a single folder solution for quick tests, but one could specify a separate user folder easily.

--

http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---

You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/_i3a20yLeHg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

[Julian Knight]

OK, I take that back, I've just looked at the flows and config files. The latter in particular is quite platform specific. I guess it updates itself but it doesn't appear sensible to include either file. I'm going to include the user folder though so that it is easy to drop in an existing flows file without having to worry about the folder.

[Julian Knight]

OK, thanks for clarifying, makes sense.