Documentation

Appearance

Production rollout ​

Production rollout turns a successful agent install on one device into a repeatable operating process for every unit that ships. The device count is less important than the handoffs: manufacturing, network approval, ownership, support, security, and decommissioning must all agree on what makes a unit supportable.

Stage 1: Prove the production image ​

Test representative hardware and the same operating-system image intended for shipment:

  • install the current supported agent
  • verify organisation, device class, architecture, and first connection
  • test the outbound route under realistic site restrictions
  • inspect the agent's effective Linux identity, groups, ACLs, and sudoers
  • test Remote Shell, Wormhole, file retrieval, logs, and monitors that support will use
  • exercise agent upgrade, recovery, and uninstall procedures

One successful connection is not a production qualification. Repeat the test after image, service, permission, and network-policy changes.

Stage 2: Define identity and context ​

Decide before factory scale:

  • which organisation and device class receive each product line
  • which physical asset identifier links manufacturing to the Dataplicity record
  • when customer, site, environment, and rollout context are applied
  • which fields are dedicated records and which are operational tags
  • who owns provisioning keys and their rotation
  • what happens when a unit is reassigned, replaced, returned, or decommissioned

Use One device record from factory to field ticket as the continuity model.

Stage 3: Pilot the handoffs ​

A pilot should test more than connectivity:

  1. Provision through the controlled manufacturing or image-build process.
  2. Confirm the intended organisation, class, and device identity.
  3. Apply approved customer, site, and operational context.
  4. Verify that support can find the unit from a realistic customer report.
  5. Trigger a known signal and follow the incident method.
  6. Run a reversible action under production permissions.
  7. Verify recovery independently.
  8. Review supported product history and identify any required external evidence.

Include support, operations, security, and the network owner in the pilot. A process that only the embedded engineer can complete is not yet a support process.

Stage 4: Scale repeatably ​

For production:

  • include the agent through a controlled image or provisioning process
  • protect provisioning material from source control, logs, and customer-readable images
  • automate only the metadata that has an authoritative source
  • validate first connection and ownership context before releasing inventory
  • monitor for devices that never check in or lose expected context
  • preview every class, tag, or network selector before a fleet action
  • document escalation, customer communication, and evidence retention

Do not use an arbitrary device-count threshold as the definition of production. Production begins when a remote unit can affect a customer, site, or business process and must be operated predictably.

Release gate ​

Treat a unit as supportable inventory only when:

  • identity, organisation, class, and asset mapping are confirmed
  • customer and site context is complete where those modules are enabled
  • outbound destinations have been approved for the deployment network
  • the intended support team can find the unit
  • access follows individual accounts and least privilege
  • evidence and independent recovery checks are available
  • reassignment and decommissioning procedures are defined