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.
Available Automation Tools
All our tools are configurable on a per-repository basis
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
- PDT 7 – 8am
- CDT 9 – 10am
- BST 3 – 4pm
- CEST 4 – 5pm
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.