Fully reproducible builds with Jidometa

Throughout the transition from Jidoteki SaaS -> Jidoteki Managed -> Jidoteki Self-Hosted, we’ve always provided the ability to generate identical builds on the fly.

In this post, we’ll look at what it means to have a fully reproducible build, and our process for achieving that.

The goal

We believe the concept of software EOL (end-of-life) can be completely avoided. As long as a virtual appliance can be updated, there is no reason for customers to worry about being left behind.

A sane update process

With the Jidoteki update process, we can generate update packages which can be applied to any version of any appliance. As long as the build’s original sources, artifacts, and dependencies are available, we can produce a new update to apply to that build. Being able to reproduce a specific build, at any point in time, also makes it easy to create one-off updates.

With Jidometa - our on-premises virtual appliance for building virtual appliances - we’re able to keep track of every build detail, and avoid situations where a customer can’t be updated. We use Ansible to quickly provision an appliance, and those changes are tracked using Git, so each build is attached to one git commit ref.

In fact, even if all the sources, artifacts and dependencies are lost, we could still technically update an appliance, by manually extracting the files from the OVA and generating an update from that (our intervention would be required, but it’s entirely possible!).

image

Jidometa build artifacts © Unscramble / Jidoteki 2016

An example situation is where our customers are only testing their changes against the latest appliance version (ex: v4.0), but suddenly hear about a user still using v1.0. Do you tell them to trash their appliance, lose their data, and start from scratch? No. You smile, rebuild v1.0 to test locally, and create a one-off update for that version.

Branching, bundling, and remerging updates

When one-off updates are created, this is known as branching, and it can become quite tedious to keep track of multiple branches. Since we use Semver for versioning appliances, we can create update packages which bundle multiple file versions, and can be applied to different versions of an appliance. Doing that allows us to remerge everyone back onto the exact same version.

image

Fully reproducible builds

If it weren’t for the ability to fully reproduce a build from scratch, developers would be tempted to give up on older versions, or stop supporting them entirely. We can avoid that excuse, as well as enable a much better customer experience.

With a reproducible build, debugging becomes simpler, and the old “I can’t reproduce that” goes out the window, since you can now replicate a customer’s exact setup, and even import their data (assuming the issue isn’t outside the appliance: ex, a networking or hypervisor issue).

We provide all the tools and advice for doing this with Jidometa. If you plan to deploy your software as a virtual machine (virtual appliance), and want some expert advice and tools for quickly creating and updating reproducible builds, then contact us and we’ll help you move forward.