The Continuous Delivery Machine Part 2: Build Environment

Build Environment

As the backbone of Continuous Delivery, the process for releasing/deploying software MUST be repeatable and reliable. This means that your build environment must be stable from one build to the next. In Part 1 of this series, I discussed the build engine as a core component of the machine. However, after you’ve successfully built one project, you’ll want to build another. Also, when word gets out that you’ve established a build server, others in your team or organization will want to have their projects built as well. With a growing number of projects being built, how do you keep your build environment clean so that’s always repeatable?

One obvious answer is to launch another build server but it’s really not feasible (or smart) to spin up a server for every project. If your projects are anything like mine, there will be dependencies involved and in order to have a successful build, a proper build environment needs to be established.

VIPM Environment

In VIPM, there’s a feature called VI Package Configurations (VIPC). In short, VIPC files allow you configure the state of packages within VIPM. If your project is referencing package dependencies in VIPM, you can control which packages are installed at a certain version. Creating VIPC files requires VIPM Pro but if you’re going to automate package building, you probably have already purchased a license since it’s required for automation (VIPM API).

There are two key VIs in the VIPM API:

Test VIPC Apply Needed_vipm_api.vi
Apply VIPC File_vipm_api.vi

Using these in a VI, you can determine if the current packages installed in VIPM need to be updated. If so, then apply the update.

If we take the code from Part 1 and create a VIPC file that has the same filename as the LabVIEW project with the extension name changed to .vipc, we have:

Similarly, if we have a VIPC file that is the same filename as the VIPB spec file with the extension changed to .vipc, we have:

Jenkins Build Environment

Depending on what you’re building, you’ll need to configure the Jenkins build environment in addition to the VIPM environment. You may need to inject environment variables, inject password values, or execute an initialization script before or after a SCM checkout. The build number that’s used in the build code is an example of injecting a Jenkins build variable into the environment. For complete details on what can be injected, see the EnvInject Plugin.