You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/blog/2026/05/git-snapshot-for-iiot-flows.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ tags:
9
9
cta:
10
10
type: contact
11
11
title: Your MOC process deserves better than a description
12
-
description: See exactly what changed — node by node, line by line — before anything reaches production. Reach out to learn how FlowFuse fits your team.
12
+
description: See exactly what changed, node by node, line by line, before anything reaches production. Reach out to learn how FlowFuse fits your team.
13
13
---
14
14
15
15
Approving a logic change you cannot fully see is not MOC. It is a signature on a description.
@@ -22,21 +22,21 @@ Here is the problem that creates, and how FlowFuse snapshot comparison solves it
22
22
23
23
[Management of Change](https://www.advancedtech.com/blog/what-is-moc-in-manufacturing/) requires that every change to control logic or operating procedures is reviewed, approved, and documented before it reaches production. The intent is sound: catch problems before they cause incidents.
24
24
25
-
In practice, the reviewer sees a ticket. "Updated OEE calculation." "Modified threshold on line 4 flow." A threshold changed from 80 to 8. A retry block deleted. Nobody reviewing a ticket sees any of that — they read it, they sign it, and the change goes out.
25
+
In practice, the reviewer sees a ticket. "Updated OEE calculation." "Modified threshold on line 4 flow." A threshold changed from 80 to 8. A retry block deleted. Nobody reviewing a ticket sees any of that. They read it, they sign it, and the change goes out.
26
26
27
27
That is not a process failure. It is a tooling failure. Until recently, there was no practical way for a reviewer to see the exact lines of function code that changed, or which environment variable was modified, or which nodes were added or removed. So teams worked around it with descriptions, and hoped the descriptions were accurate.
28
28
29
29
That is where incidents trace back to.
30
30
31
31
## What Snapshot Comparison Shows
32
32
33
-
A [snapshot](https://flowfuse.com/docs/user/snapshots/) in FlowFuse captures the complete state of a Node-RED instance at a point in time: every node, function block, configuration value, and environment variable. Comparing two snapshots produces a diff of everything that shifted between them.
33
+
A [snapshot](https://flowfuse.com/docs/user/snapshots/) in FlowFuse captures the complete state of a deployed instance at a point in time: every node, function block, configuration value, and environment variable. Comparing two snapshots produces a diff of everything that shifted between them.
34
34
35
35
The engineer makes their changes and creates a named snapshot. That snapshot becomes the artifact attached to the MOC request.
36
36
37
37
The reviewer compares it against the snapshot currently running in production. What they see is not a description of the change. It is the change.
38
38
39
-

39
+

40
40
41
41
For configuration changes, the view shifts to a side-by-side property comparison.
42
42
@@ -54,6 +54,6 @@ When the reviewer has worked through the diff, they approve the named snapshot.
54
54
55
55
In FlowFuse, the reviewed artifact and the deployed artifact are the same thing. For audits, incident investigations, and regulatory compliance, that traceability is what MOC was always meant to produce.
56
56
57
-
For teams on Team or Enterprise plans, FlowFuse also creates auto snapshots on every deploy — a passive safety net that captures the exact state running on each instance or device, even when a named snapshot was not part of the workflow. Up to ten auto snapshots are retained automatically, giving teams a recoverable history without any extra steps.
57
+
For teams on Team or Enterprise plans, FlowFuse also creates auto snapshots on every deploy, a passive safety net that captures the exact state running on each instance or device, even when a named snapshot was not part of the workflow. Up to ten auto snapshots are retained automatically, giving teams a recoverable history without any extra steps.
58
58
59
59
For teams managing logic across many devices, the same approved snapshot can be pushed to an entire fleet without re-entry. For teams that need a full version history, rollback capability, or deployment traceability, the [full snapshot documentation](https://flowfuse.com/docs/user/snapshots/) covers every available action.
0 commit comments