The problem with USB sticks
At many sites, edge devices and gateways are still updated by hand: a USB stick, a remote desktop session, a configuration edited in place. It is slow, it is hard to repeat and it leaves no record of who changed what and when. Continuous integration and delivery (CI/CD) practices fix that, provided they are adapted to an environment where a bad release can stop a line.
What to put under version control
- Gateway and broker configuration, including mapping files and certificates’ metadata (never private keys).
- Container definitions and compose or deployment files.
- Scripts used for installation and recovery.
- Firmware images and their checksums for devices you manage.
- Exported PLC projects, with a note on version and date. Vendor project formats often cannot be compared line by line, so a version history is mainly an audit trail and a restore source (see PLC program backup best practices).
Build and test before anything reaches a line
- Build an image or package from a tagged commit, reproducibly.
- Validate configuration automatically against a schema: required fields, units, address ranges, naming rules.
- Unit-test transformations such as scaling and byte-order handling with known values.
- Run an integration test against simulated devices (for example a Modbus or OPC UA simulator) and, where you have one, a bench or staging line.
Release in small, reversible steps
- Sign artifacts so a gateway only accepts packages from your pipeline.
- Roll out in stages: one gateway, then one line, then the site.
- Use health checks (service up, data fresh, queue not growing) and roll back automatically to the previous image if they fail.
- Respect maintenance windows and agree them with the people who own the process.
- Require approval from both IT and process engineering for anything that touches production data paths.
Prefer immutable images and detect drift
Rebuilding a gateway from a known image is more reliable than patching a long-lived one in place. Compare the running configuration with the version in the repository and alert on any difference: unplanned changes are either an emergency fix that must be recorded or a problem to investigate.
What not to automate
Downloading a program into a controller, or any change that alters machine behavior, should stay under manual, authorized change control, with a verified backup and a rollback plan. Automation is for the data path around the controller, not for the control logic itself. Firmware for field devices needs the same caution: see firmware update management for industrial devices.
The audit trail comes free
When every change is a commit and every deployment is a pipeline run, “who changed what and when” is answered by the history, not by memory. That record also supports the change and rollback question in the readiness worksheet.