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

Release Automation Chain

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 scripts in our release process.

 

Available Build Scripts

 

 

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 youtu.be/ue0NeYNEYf0.


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 youtu.be/1MGP5X-LmYE.


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: Testing, 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 youtu.be/FTYpQNPgwAQ.


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 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 own servers, 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.