We built a basic utility we inventively called "GBuild" that is run via command-line when starting LabVIEW. GBuild parses LabVIEW command line arguments (ignoring itself) to determine what project to open, whether to mass compile or clear the compiled object cache, what number to version a build (e.g.with reference to source control version), what unit tests to run (by unit test framework provider, we occasionally use more than one), what VI Analyzer configuration file to use (if required) and then what build specification to execute. We use the command output stream to feed information back to the CI runner (progress, unit test results etc.), which in our case happens to be TeamCity.
The actual TeamCity build agent in our case is a virtual machine with the development environment elsewhere on the network. As part of the pre-build process TeamCity automatically checks the source out of source control prior to starting GBuild.
This works quite well, even in some scenarios where we "chain" builds (one build is dependent on the previous).
The only issue we have had is where we use .NET assemblies as part of a project that is being built - if the .NET assembly version has changed then we have had to add a programmatic "Save All" to avoid LabVIEW hanging at exit with a prompt to save changes (since there is no actual user).