How many clicks does it take you from saving your VI to getting your built project to your customer?
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
* DQMH Validator, VI Analyzer, Unit Tests, Documentation Generation
Available Automation Tools
All our tools are configurable on a per-repository basis
INITIALISE
Prepares external dependencies for the build:
- Clear temp folders and object caches
- Apply .vipc files if necessary
- [Optional] Clone additional repositories
VALIDATE
Executes the DQMH Headless Validator:
- Parses a project for DQMH Modules and validates them
- Stores the results as artifacts
- [Optional] Sends results via email
ANALYSE
Executes a per-repository set of VI Analyzer tests:
- Uses a repository-specific VIAn configuration file
- Analyzes all files or only changes since last release
- Stores the results as HTML and Code Climate JSON in artifacts
- [Optional] Sends results via email
TEST
Executes a per-repository set of unit tests:
- Runs a repository-specific Wrapper VI for unit tests
- Implement your own wrapper!
- Stores the results as artifacts
- [Optional] Sends results via email
DOCUMENT
Generates documentation from source code:
- Prints VI descriptions and connector pane images
- Prints UML-like Diagrams of callers/callees
- Parses state machines and draws state diagrams
- Generates HTML and PDF output
- Facilitates Wovalab’s AntiDoc Toolkit
BUILD
Executes the project’s build specification:
- Executes all types of build specifications
- Supports NI Packages and SystemLink Deployment
- Reads version and commit info from Git
- Creates changelog / release note files
- [Optional] Writes version info to VIs
VIPM
Creates a VI Package from a .vipb:
- Create VI Packages using VIPM API
- Optionally, build from source distribution
- Update package release notes and version information
- NOTE: Requires a VIPM Pro license
FPGA
— COMING SOON —
- Compile FPGA bitfiles
- Compile locally or on Compile Farm
- Analyse FPGA code
- Document FPGA code
PACKAGE
Packages build results and optional template files:
- Copies build results to temporary location
- [Optional] Copies template files to temporary location
- Creates a ZIP archive from the temporary location’s contents
- Uses project and version info for archive file names
DEPLOY
Deploys the built package to a shared location:
- Reads the target directory from configuration
- Copies packagr result files to the target directory
- Copies also documentr results and .vipc files
- Target directory structure is built using project and version names
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.
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.
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.
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.When
-
- On Demand
Where
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:
??? ??
-
Commercial Licenses
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:
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: 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 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.
Additional Material
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)
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.
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.
