Skip to content

GitOps for Automation Engineers

If you have spent any time in DeltaV, RSLogix, PCS 7, or any other traditional DCS, "GitOps" is going to sound like an answer to a question you did not ask. This page explains how Cloud-Native DCS bridges your existing workflow to a modern declarative one. Just as importantly, it separates product concerns from deployment concerns. Knowing that split tells you where to push back if the system does not feel right.

The familiar workflow

A typical DCS engineering workflow looks like this:

  1. Develop in a sandbox — log into a dev or sim instance, build out modules, phases, and recipes through the engineering UI, test against simulated I/O.
  2. Capture the change — export the result as a file (.fhx for DeltaV, an .acd for RSLogix, a project archive for PCS 7).
  3. Apply to production — import the file on the prod engineering workstation. In poorly-run shops, the engineer instead retypes the logic from screenshots or notes, a known source of incidents.
  4. Verify — watch the online displays, confirm the alarms behave, run a batch.

Steps 1 and 4 are WYSIWYG: you see the plant, click on equipment, and the tool reflects what you did. Steps 2 and 3 are where the workflow breaks down. The export-import handoff has no audit trail, no merge semantics, no review gate, and no protection against the retype anti-pattern.

Why "just use Git" is not the answer

If we hand an automation engineer a Git client and a YAML schema and say "this is how you change the plant now," three things go wrong:

  • The mental model collapses. Plants are visual, and YAML is not. A diff that reads holdSeconds: 1800 → 2700 does not say "Mash Hold time changed from 30 to 45 minutes" without translation.
  • Iteration speed in dev disappears. The whole point of the dev sandbox is fast WYSIWYG cycles. A commit-push-PR-merge round-trip for every tweak is the wrong shape for that.
  • Adoption stalls. The engineer goes back to whatever spreadsheet or side-channel kept the old workflow running, and the audit trail you bought GitOps for is now bypassed.

GitOps is the right substrate. It is not the right interface for the audience that is editing recipes day-to-day.

The bridge: the UI is the preferred Git client

Cloud-Native DCS treats the engineering UI as the front door for authoring changes, and Git as the underlying record of truth. The mapping back to the familiar workflow is direct:

Step in the familiar workflow Equivalent in Cloud-Native DCS
Develop in a sandbox Edit through the UI in a dev environment. The UI writes directly to the Kubernetes API. Iteration is fast and WYSIWYG.
Capture the change Click Promote. The UI computes the difference between the dev environment and the prod repository and prepares a change proposal.
Apply to production Review and approve the proposal in the UI itself. Approval merges the change to Git, which Flux reconciles into prod. The retype anti-pattern becomes impossible.
Verify Use the HMI sub-app, exactly as you would use any online display.

The vocabulary you see is Edit, Save, Test, Promote, and Approve. You are never required to type git, open a pull request by hand, or know what a branch is. Underneath, all of the audit, review, and reproducibility properties of GitOps are intact.

The table's Capture and Apply rows, end to end: Promote becomes a real pull request, approval merges it, and the merge is the deployment. The ChangeRequest flips to Reconciled with the commit linked.

Semantic diffs

The Promote preview does not show you raw YAML. It shows you the change in the language you already use (phase hold times, alarm setpoints, equipment requirements, recipe parameter ranges), with the impact called out. This is the piece that earns the bridge: a diff you can review in your domain, with no YAML fluency demanded first.

What the preview compares is the live cluster object against your edit, so it is exactly the change you are signing. The git-pr backend compares a different baseline and its pull request can therefore be wider than the preview. When that backend is the one your proposal will run, the modal says so under the diff. The reasoning is in The PR can be wider than the approval ceremony.

The translation from raw object diff to engineer-language entry is done by a small plugin registry (one renderer per CRD kind), so new resource types can be onboarded without churning load-bearing code. Implementation detail and contract live in Semantic-diff renderer framework.

Always allowed to peek under the hood

Every form has a "View YAML" toggle. Every Promote preview has a "View Git diff" expander. Every approved change links back to the resulting Git commit. None of this is required to use the system, but it is always one click away. If you want to learn the declarative model, the system actively invites it. If you never want to, you do not have to.

Both expanders opened mid-promotion: View resulting CR YAML and View Git diff. The clip continues into a cross-namespace promotion, and the peek-under-the-hood beats are its opening minute.

Authoring against files

The bridge above writes to a cluster as you author and reaches Git only at Promote. Git is the substrate, and the UI is the interface. Some engineers want the inverse for day-to-day work: the editor as the interface, but files in their own Git working tree as the substrate, with no cluster in the loop.

dcs edit ./plant does exactly that. It runs the same visual editors against a directory of CRD YAML files. Save writes the file, and you commit and push with your own Git tooling. It never touches Git itself. The editor therefore stays out of credential, remote, and merge-conflict territory. This is topology F.

Reviewing a file-mode change happens in your own Git tooling, where the diff is raw YAML. To keep the domain-level review you get at Promote, dcs diff old.yaml new.yaml renders the same semantic diff from the command line. It is a convenience. The 21 CFR Part 11 review-of-record (the reviewed-and-signed change) remains the compliance carrier, and it always happens at Promote in a connected environment.

File-first authoring reaches that Promote path without a browser: dcs change-control propose -f <file> --reason <ticket> wraps the edited document into the same ChangeRequest the UI's Promote produces, so a change authored in your editor and committed in your working tree still lands only after an authorised approver signs it in the approval queue. See dcs change-control propose.

This section, filmed: the same working tree edited from the gateway editor, VS Code, and vim. The edit that lands goes through propose → semantic diff → a distinct approver's signature.

Product concerns versus deployment concerns

Cloud-Native DCS is deliberately non-prescriptive about how your organization runs the workflow above. The split is:

The product ships:

  • The CRD ownership taxonomy — which resources are engineering artifacts (plant structure, recipe definitions, alarm setpoints) and which are operational artifacts (batches, alarm acknowledgements, audit records). Only the first class is a candidate for GitOps. The second is always written live by the UI.
  • The ChangeRequest abstraction that wraps the propose-approve-merge round-trip in-cluster, so the UI can show pending changes and signatures without you needing a Git client.
  • Semantic-diff renderers and the e-signature flow.
  • Admission policy primitives — the mechanism for restricting who can write what to which CRDs, opt-in via Helm values.
  • A UI that runs both as an in-cluster pod and as a standalone tool on an engineer's laptop, against the same CRDs.

The deployment configures:

  • The topology — separate clusters for dev and prod, separate namespaces in one cluster, laptop-only-for-dev, or any combination. See UI Deployment Topologies.
  • Whether prod accepts direct UI writes, requires proposals, or is fully read-only.
  • Concurrent-edit handling. The product does not impose pessimistic locking. If your team needs it, layer it as a soft-lock CRD or rely on Git's merge semantics at promote time.
  • Approval routing. Single approver, two-person, departmental — all configurations of the same ChangeRequest flow.
  • Break-glass roles for incident response.
  • Which Git repository "Promote" targets, per Site or per Area.

The line between product and deployment matters because reasonable customers will disagree on every item in the second list. A small specialty pharma running a single line wants something very different from a multi-site contract manufacturer. The product needs to support both without forking.

What this looks like in your day

On most days you will not think about GitOps at all. You will:

  • Open the UI, navigate to the unit you are working on.
  • Edit a phase template's hold time, click Save. (In dev, this applies immediately.)
  • Run a sim batch to confirm the change behaves.
  • Click Promote. Review the semantic diff. Add an electronic signature. Submit.
  • Hand off to QA for approval (in the same UI, no Git client required). Approval merges the change and Flux reconciles prod.
  • Watch the next prod batch confirm the new behavior.
The day-in-the-life loop with two real identities: edit → semantic diff → sign → a real logout/login handover → QA approves in the same UI.

The Git history, the cryptographic signatures, the immutable audit records, and the reproducible reverts all exist whether you look at them or not. They are there for the inspector, the next engineer, and your future self at 3 a.m. when something needs to be rolled back.