From LabVIEW code to a controlled release

Check early and prepare releases progressively

Continuous integration automates checks after code changes. Continuous delivery extends that work to preparing and distributing a version. The team decides which steps run automatically and which decisions remain with people.

In one of our GitHub workflows, a feature branch runs tests. The development branch adds executable and package builds without publishing them. Release and hotfix branches then prepare distribution. This helps catch build problems before release day.

Steps that understand LabVIEW

The pipeline file coordinates the work; custom steps perform operations specific to the LabVIEW project. We have developed commands to apply a VIPM configuration, compile VIs, run tests, check code, and produce deliverables.

Depending on the project, these operations run through reusable GitHub workflows or GitLab jobs using g-cli. Parameters specify the LabVIEW version, project, dependency configuration, and build specifications.

• Prepare dependencies using a VIPC configuration.
• Run unit tests and retain their results.
• Perform the checks appropriate to the project: compilation, VI documentation checks, DQMH validation, or VI Analyzer.
• Build an executable or VIP package and organize its publication.

Bring CI/CD into everyday work with Fork

Server automation is only part of the solution if preparing a release remains hard to follow. In some implementations, custom commands in the Fork Git client open dedicated LabVIEW tools.

One interface helps configure GitLab project variables from LabVIEW, VIPC, VIPB, and VI Analyzer files. Another presents the current version, the version to release, and a changelog to review. The developer confirms that dependencies have been updated and can postpone the push to finish preparing the release.

A monitor then displays pipeline stages, their status, and their duration, with access to details in GitLab. The team can see what is waiting, running, or finished while staying close to its development work.

Make results useful to the team

In the GitLab example, unit test results are retained in JUnit format. VI Analyzer steps produce a code quality report. This feedback helps identify what needs attention before proceeding.

Checks do not necessarily serve the same purpose: some must block delivery, while others highlight improvements to address. We define these rules with your team, along with manual triggers, permitted versions, and publication conditions.

Connect the build to distribution

The implementations shown cover building and publishing packages to a VIPM repository, as well as delivering executables through BLT for LabVIEW. In the documented workflow, a beta version is tested before being manually promoted to a public release.

Dependency preparation, version numbers, release notes, and the source commit are part of the process. A step that remains manual, such as creating the first installer in one project, can stay explicit rather than disappear behind a green pipeline status.

Start with a repeatable workflow

We start with your existing procedure: what gets tested and compiled, the tools installed on the server, and how users receive a version. We select an initial project and automate a workflow that the team can understand and maintain.

LabVIEW versions, dependencies, licenses, access rights, and build server constraints are part of the configuration. We also check failure paths and diagnosis so the team knows what to do when a step fails.