How many clicks does it take you from saving your VI to getting your built project to your customer?

Release Automation Tools - Schematics

For us, it’s a lot. That’s what motivated us to look into automating some of our build steps. Today, our automation chain covers most of the important steps in our release process.

Benefits we (HSE) see in our daily work

Benefits we (HSE) see in our daily workBenefits we (HSE) see in our daily work

* DQMH Validator, VI Analyzer, Unit Tests, Documentation Generation


Available Automation Tools

All our tools are configurable on a per-repository basis

Scroll down for more information on How our Automation Chain works with GitLab and some Additional Documentation.

State Machine Documentation

Our Documentation tool is able to parse our HSE State Machine template to generate graphical (UML-like) diagrams using the PlantUML directly from the LabVIEW block diagram.


Parsing State Machines
Parsing State Machines

Dokuwiki Release Plugin

We created a plugin for our Dokuwiki platform that automatically generates download links for packages created by our Release Automation Tools. You can find an example at our HSE Windows Application Template‘s release page.


Dokuwiki Release Plugin
Dokuwiki Release Plugin

Graphical User Interface

Our stand-alone application allows you to execute the exact same tools that are run on the build servers on your own machine. For those times when you don’t have internet access or when you want to try things offline.


Stand-Alone Tool with Graphical UI

Upcoming Webinars

Join our webinars to learn more about our Release Automation Tools.

Currently we don’t have any dates fixed, but please reach out to us if you’re interested. We’re happy to accommodate a one-on-one meeting or another public webinar. We can also share recordings of past webinars.

  • On-Demand RAT Webinar

    Release Automation Tools – An Introduction

    Introduction into the overall structure and process landscape.
    Live demonstration of triggering the automation.
    Introduction of available RAT steps/scripts.
    Requirements for running RAT on your own infrastructure.


      • On Demand


    This is a virtual event without physical presence. We will use Microsoft Teams to host this meeting. Please send an email if you’re interested in joining us. You can use the button below:

    Email Registration

    ??? ??

Commercial Licenses

RAT Commercial License

Besides running our Release Automation Tools on our own servers, we offer commercial licenses so you can facilitate the same tools in your own infrastructure for your own projects.

The license comes exclusively as part of a consulting project: Collaborating closely with your team, we install and setup our tools in your infrastructure and introduce the necessary processes and methods to fully leverage them.

We’d be happy to discuss all the details in a personal call. Please get in touch with your contact details, and we’ll call you back. You can use the following button:

Request a call-back

How our automation chain works with GitLab

We use Git and GitLab for source code control. Our whole automation is based on GitLab’s CI/CD features and our Git workflow called gitflow.


1. Changes are pushed to Source Control Server

Gitflow dictates the way we create and merge branches in our repos, and when and where we create releases. Hence, it also defines the calling points of our automation.

Whenever a developer pushes back to the master repo (the origin), the GitLab CI/CD automation mechanism is triggered and executes according to its configuration.

Watch a screencast of this at

2. Source Control Server triggers Build Server

The .gitlab-ci.yml configuration file, which is part of the repo and therefore project-specific, defines which actions to take on which event („when to call which scripts“).

In order to execute actions on a build server, the GitLab Runner has to be installed on the build server. It is called from the GitLab CI and executes the actions  defined in the .gitlab-ci.yml file.

On our system, the runner is called whenever a tag is pushed.

Watch a screencast of this at

3. Build Server executes Tools

The runner executes the scripts defined in the .gitlab-ci.yml file: Our Release Automation Tools. These tools are a collection of custom-built LabVIEW VIs that do the actual work: Validating, analyzing, testing, documenting, building, packaging and deploying our LabVIEW projects.

The VIs are built on JKI State Machines for macro functionality, and they are executed by the runner via Wiresmith Technology’s G-CLI tool, which allows to output data to the command line – and feed back to GitLab – while the VI is still running.

Watch a screencast of this at

4. Built files are published

The last step in the build chain is taking the build results and moving them to a networked location (a NAS) that is accessible from the public web.

We use Dokuwiki to serve build results on the web. Our proprietary Dokuwiki plugin queries the GitLab API for the project’s tags. Based on the tag list, it queries the file server for files related to each tag and auto-generates the download links on the release webpage.

Watch a screencast of this at

Additional Material



Given at the VIP Days 2018, the MLUG, DUTLUG and WUELUG user groups and at the European CLA Summit in Krakow in 2019.

Release Automation with LabVIEW
(rev05, PDF, english, 12.7 MB)


NI Online Training Resources

We recorded a video module for NI’s brand-new Continuous Integration learning path. It is called “Continuous Integration Process using GitLab” and explains the basics of GitLab, setting up the system and building pipelines.

Continuous Integration Process using GitLab

In a nutshell: What are Git & GitLab?


In a nutshell: What is Gitflow?


In a nutshell: What is CI / CD?


Why did we build our automation chain?

When we started out with our tools, Joerg was working on his own. He didn’t want to continuously integrate or deploy, he just wanted to automate some recurring processes to save on valuable time and increase the quality of the delivery process. Over time, we migrated into the team work realm and started adding to the automation chain.