Industrial DevOps in Action: Bringing Ignition and Beckhoff into One Deployment Workflow

As industrial automation systems become larger and more software-driven, controls teams need better ways to manage changes, test code, and deploy updates. At the 2026 Ignition Community Conference, DMC and Beckhoff demonstrated how modern software development practices can be applied across both SCADA applications and real-time PLC control.

The solution showcase, “Industrial DevOps: Ignition Meets TwinCAT Automation Software,” walked through Git-based source control, continuous integration and continuous delivery (CI/CD), automated PLC testing, and coordinated deployment across Ignition and Beckhoff TwinCAT.

Rather than treating PLC and SCADA development as separate activities, we showed how both can bring both into a single, controlled, visible, and repeatable engineering process.

Why Industrial DevOps Requires a Different Approach

Source control, automated testing, and deployment pipelines are standard practices in conventional software development. Industrial automation has adopted them more gradually, and for good reason. In large part, because controls software operates in the physical world.

A code change can move machinery, affect production, and introduce safety implications. As a result, controls teams need to be selective about which software development trends to adopt and consider what consequences these approaches can have on physical processes.

However, that doesn’t mean industrial projects should continue to rely on manually named backup files, undocumented online changes, and production systems as the only source of truth. With the right platforms and safeguards, automation teams can adopt proven software practices while maintaining the controls, approvals, and testing required for an industrial environment.

Ignition and Beckhoff TwinCAT are particularly well suited to this approach because operators can manage project resources as files and review them through standard software-development tools.

Making Git the Source of Truth

In traditional automation workflows, version control may consist of files with names such as “PumpStation_Final,” PumpStation_Final_1,” or “PumpStation_Final_Updated.” When these files are stored across different locations, it can become difficult to determine which version is the most current and running in production.

A DevOps workflow provides more structure, making the Git repository the central source of truth. Changes to both TwinCAT application and Ignition project can be commmitted to the repository, creating a shared history of PLC and SCADA development.

Because the underlying project resources are text-based, engineers can use standard Git tools to review changes and see exactly what was added, removed, or modified. This makes changes easier to track and review across both the PLC and SCADA portions of the system, in addition to several other practical advantages:

• Engineers can review the specific content of a proposed change.
• Technical leads can approve changes before deployment.
• Teams can see when and why a resource was modified.
• Multiple developers can collaborate without replacing one another’s work.
• Previous versions remain available when troubleshooting or rolling back a release.
• New features can be developed in a feature branch rather than directly in the main branch

Automating the Beckhoff Build and Test Process

To take these concepts a step further, after committing, reviewing, and merging changes, teams can implement CI/CD to kick off different pipelines. As an example, in our presentation at ICC, we demoed using Jenkins (though you can use other tools such as GitHub Actions, Azure DevOps, or GitLab runners). After the code was merged, Jenkins detected the updated source and initiated the Beckhoff build-and-test pipeline.

The pipeline used Beckhoff’s TwinCAT Automation Interface, an API that allows teams to programmatically perform tasks that would otherwise require a developer to open the engineering environment and work through the user interface. In the demonstration, the pipeline opened the project, built the PLC application, activated the test project, ran automated tests, and produced the files needed for deployment.

The PLC project was structured to support simulation and testing. We decoupled physical I/O from the application’s programmatic I/O, allowing a separate simulation PLC to stimulate inputs and outputs without requiring the production equipment.

The application also separated reusable logic into a library project. We structured device interfaces, rotation logic, and other code modules so that the system’s behavior could be evaluated with mock objects and automated unit tests.

Jenkins then displayed the test results. If a test that previously passed began failing after a change, the pipeline could identify it as a regression before the code reached production.

This does not eliminate the need for physical testing, commissioning, or engineering judgment. It adds another verification layer so that common problems can be detected earlier and more consistently.

Deploying the PLC Application

After the automated build and tests completed successfully, a separate Jenkins job deployed the most recent successful build to the target Beckhoff controller.

The deployment transferred the generated runtime files and restarted the controller so the updated configuration would take effect. Because TwinCAT runtimes are represented as files, the same general strategy can support scenarios involving multiple controllers or fleets of similar machines.

Deploying the Ignition Application

The Ignition portion of the process followed the same core philosophy.

Once the repository contained the approved PLC and SCADA changes, the Ignition pipeline transferred the updated project files to the production Gateway. The pipeline then triggered a Gateway scan so Ignition would recognize and load the updated resources.

The deployment included several configurable safeguards:

• An initialization step prepared the deployment.
• A dry run identified which files would be transferred.
• A human approval step required someone to authorize the production deployment.
• An optional setting allowed Ignition to be stopped and restarted when necessary.
• A Gateway scan loaded the updated project resources.
• Basic verification confirmed Ignition was running and the required ports were available.

The human approval step was intentional. The goal was not to let every committed change deploy automatically to a live industrial system. Instead, automation handled the repetitive and error-prone steps while an authorized person retained control over when production was updated.

After the pipeline completed, the production Ignition application reflected the new three-pump configuration.

DMC’s Experience Across Ignition and Beckhoff

Working across Ignition and Beckhoff TwinCAT requires understanding how development workflows differ between the SCADA and PLC layers. DMC has worked on hundreds of projects with each platform and is both an Ignition Premier Integrator and Beckhoff Platinum Solution Partner.

That experience helped shape the approach used in this demonstration. Instead of treating Ignition and TwinCAT development as separate processes, we focused on the practices they can share, including source control, automated testing, change review, and coordinated deployment.

Building a More Maintainable Automation System

The most important takeaway from the showcase was not a specific PowerShell script or Jenkins configuration. It was the shift toward treating an industrial automation application as a managed software product. In the demonstrated workflow:

1. Engineers developed against separate virtual and development environments.
2. PLC and Ignition changes were committed to Git.
3. Feature branches isolated work in progress.
4. Merge requests enabled review and approval.
5. Jenkins built the Beckhoff application.
6. Automated tests checked for regressions.
7. Approved build artifacts were deployed to the controller.
8. Ignition files were transferred to the production Gateway.
9. A human approval step controlled the production release.
10. Verification confirmed that the updated application was running.

The individual steps were intentionally straightforward. Much of the process consisted of running scripts and moving files. The value came from making those activities consistent, reviewable, and repeatable.

The Future of Industrial Software Delivery

Automation projects will continue to require careful commissioning, process knowledge, and respect for operational and safety risks. Industrial DevOps does not replace those responsibilities.

What it can replace are uncontrolled files, unclear version histories, inconsistent manual deployments, and changes that are difficult to review or reproduce.

Ignition and Beckhoff provide the flexibility needed to bring modern development practices into the industrial environment. DMC provides the controls, SCADA, software, and deployment expertise required to turn those capabilities into a practical workflow tailored to each customer’s operations and support model.

Whether an organization is developing a new automation platform, modernizing a legacy system, or looking for better control over multi-site deployments, DMC can help build an Ignition and Beckhoff architecture that is scalable, testable, and maintainable throughout the system lifecycle.