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:
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.
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.
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.