Table of Contents

DevTools

CI/CD is hard — especially for PLCs. Manual builds in the IDE don't scale. There's no standard toolchain like in classic software, builds are hard to reproduce, and "works on my machine" turns into production risk. Teams need automated builds, tests, and docs without running their own Jenkins farms or fighting TwinCAT's tooling.

Zeugwerk DevTools is a TwinCAT product-delivery toolchain. It orchestrates the full path from source to shippable artifacts: resolve dependencies, compile headlessly, discover and run tests, generate API documentation, and produce type-safe bindings for C# or C++. Everything is driven by Twinpack and a shared .Zeugwerk/config.json — the same configuration works in the cloud, on your own build server, or in a hybrid setup.

Use zkbuild-action and zkdoc-action on GitHub, GitLab, or Bitbucket (free tier for public repos). License zkmake, zkdoc, and zkbindings for on-premises and private use.

How it fits together

The workflow contract is Twinpack + config.json. The build tools execute it; the other tools consume the same project layout.

flowchart LR
  TP[Twinpack + config.json] --> B[zkbuild / zkmake]
  B --> T[Test discovery + execution]
  B --> A[.library artifacts]
  TP --> D[zkdoc]
  TP --> K[zkbindings]
  D --> H[Published API docs]
  K --> C[C# / C++ bindings]
Stage What happens Tools
Dependencies Declare packages, references, patches, and versions in config.json. Twinpack resolves feeds (Zeugwerk, Beckhoff, private NuGet/Twinpack). Twinpack, config.json reference
Build Restore packages, apply patches, compile via headless TcXaeShell. Optional static analysis and variant/platform matrix. zkbuild-action (cloud) · zkmake (on-premises)
Test Discover tests (embedded FBs, tests/ folder, or in-solution UnitTestApplication), deploy to a TwinCAT target, collect JUnit/xUnit results. Unit tests reference · same build tools
Document Parse Structured Text comments and publish API reference (DocFX / GitHub Pages). zkdoc-action · zkdoc
Integrate Generate type-safe C# or C++ bindings from PLC types for external applications. zkbindings-action

This is orchestration, not a single compile command. zkmake build and zkbuild-action run the full build-and-test pipeline in one step; individual commands (configure, update, set-version, …) let you compose the same steps in larger release pipelines.

Tools at a glance

Tool Role in the pipeline Cloud (GitHub / GitLab / Bitbucket) On-premises
Twinpack Package management and config.json authoring IDE extension + CLI IDE extension + CLI
zkbuild / zkmake Build orchestration: packages → compile → test → artifacts zkbuild-action — free for public repos (30 builds/month) zkmake — Windows CLI, requires TwinCAT XAE + license
zkdoc Documentation generation from PLC source. Comment syntax. zkdoc-action — free for public repos (30 builds/month) zkdoc — cross-platform .NET CLI, requires license
zkbindings Type-safe C# / C++ bindings for external apps zkbindings-action — free for public repos Licensed/on-prem — contact us

Free tiers for public repos (e.g. 30 builds/month). For private repos, higher volume, or on-premises licensing, see pricing or contact us.

Unit tests

Build tools support three test layouts (see Unit tests reference):

  • Embedded (Option A): test function blocks in the library PLC implementing ZCore.IUnittest or Testbench.IUnittest; DevTools generates the harness.
  • tests/ folder (Option B): standalone test project under tests/ with its own tests/.Zeugwerk/config.json.
  • In-solution (Option C): a UnitTestApplication PLC in the main config.json (native TcUnit in the same .sln).

Results are written as standard JUnit/xUnit XML for Jenkins, Azure DevOps, GitHub Actions, and similar. For embedded tests, use --test-framework on zkmake build.

Cloud vs. on-premises

Most DevTools come in two forms: a hosted action (GitHub / GitLab / Bitbucket) or a licensed CLI for your own agents. Both use the same .Zeugwerk/config.json, so you can mix cloud and on-prem in one project — e.g. cloud builds on PRs, on-premises builds for release artifacts.

When you use the framework to implement your own applications and libraries, we recommend following Coding Guidelines (naming, structure, style) and IDE settings (TwinCAT options) so your code stays consistent with the framework and works well with our tooling and CI.