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

Quite a lot, probably. 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:

Release Automation Chain

 


  • Developer

  • GitLab Repository

  • Build Server

  • Network Share

  • Dokuwiki Platform

  • Enduser

 

 

How our automation chain works:

1. Push changes to source code control

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. Scroll down if you’re not familiar with any of these terms.

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.

Watch a screencast of this at youtu.be/ue0NeYNEYf0.


2. Source code control triggers build server

Whenever a developer pushes a tag to the master repo (the origin), the GitLab CI/CD automation is triggered.

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

Watch a screencast of this at youtu.be/1MGP5X-LmYE.


3. Build server executes LabVIEW VIs

Gitlab’s built-in CI allows to trigger runners based on your git actions (eg pushing a tag).

The runner is a small application that is installed on the build server. It connects to the GitLab origin and executes the actions defined in the gitlab-ci.yml file.

The LabVIEW VIs implement the actual test, build, package and deploy functions. The VIs are based on the JKI State Machine, and they are executed by the runner via Wiresmith Technology’s G-CLI tool.

Watch a screencast of this at youtu.be/FTYpQNPgwAQ.

Available Build Steps (LabVIEW VIs):

Test: Execute a per-repository set of VI Analyzer tests. Failed tests can optionally break the build. Results are sent via email.

Build: Read version information from git. Create readme files, update the VIs’ documentation field and/or the main VI’s block diagram with the version number etc. Execute the build specification.

Package: Build results and optional template files are bundled together and packaged as a zip archive. For reuse libraries, this approach allows to install the libraries parallel in multiple locations.

Deploy: Copy the package to the file server where it can be accessed from the internet via a auto-generated Dokuwiki release page.

Build Server Scripts


4. Built files are published on the web

We use Dokuwiki to serve build results automatically. 

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 (relation defined by file structure).

The list of releases (=tags) and downloads (=files) is then auto-generated per project (=repository).

Watch a screencast of this at youtu.be/POB25NRlxD4.

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

 

Are you interested?

Please download the presentations to learn more about our setup. Contact us directly if you want our help building a similar system, or if you’re interested in using our Release Automation tools on your server, or if you just want to chat about automation and CI/CD.

 

Presentation

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)

 

Poster

Created for the poster competition at the European CLA Summit in Krakow in 2019.

GitLab and Release Automation
(rev04, PDF, english, 2.4 MB)

 

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.