Free estimate
Menu

Case studies

From “We need builds” to nightly releases on every system

Told only “We need builds,” we specified and built a customer’s entire release system in one month of work: nightly releases on every supported system.

A customer's integration team. As a subcontractor, we specified, built, and run its entire release system.

Nightlyreleases on every supported system, carrying each day's merges
One month of workfrom “We need builds” to the first automated, tested release

Starting point: one request, no written requirements

The customer’s software is a large simulation framework and the customer’s own plugins, libraries, and demos. The request to us was three words: “We need builds.” Nobody wrote requirements. We set them:

  • Releases had to run on every system the customer supports: Windows and Red Hat Enterprise Linux (RHEL).
  • Each release had to bring the framework, plugins, libraries, and demos together.
  • Each new upstream framework version had to reach the customer’s users.
  • Every release had to carry its own test evidence.

Approach: one release system, specified and built in a month

We were told “We need builds” and nothing more. We specified every feature of the release system and built all of it. About a month of full-time effort took the customer from that request to its first automated release, with its test report inside.

  1. Specify the whole release system. A release is built by a pipeline, tested, reproducible, and ready for every supported system.
  2. Build one superbuild for the whole product. The framework, the customer’s plugins and libraries, and its demos build together, so Windows and every RHEL generation build from the same source.
  3. Put the evidence in every release. Tests run before packaging; each release carries its test report and the exact state of every repository in it.
  4. Release every night, everywhere. The pipeline builds a release from everything developers merged that day, so changes reach users the same day. Releases also go to users beyond the customer, including a RHEL 7 HPC cluster and an outside lab.
  5. Make new versions and new systems routine. We upgrade the framework ourselves: swap the version, and the superbuild pulls and builds it. We have done four upgrades. Adding RHEL 9 took about a day, from decision to shipped release.
Your code goes through one release process to Windows, RHEL, Ubuntu, and other current systems, to legacy systems such as RHEL 7, and on disc into SCIFs and classified networks.your codeone release processWindowsRHELUbuntuand othersRHEL 7SCIFs andclassified networkscurrent systemslegacyair-gappedYour code goes through one release process to Windows, RHEL, Ubuntu, and other current systems, to legacy systems such as RHEL 7, and on disc into SCIFs and classified networks.your codeone release processcurrent systemsWindowsRHELUbuntuand otherslegacyRHEL 7air-gappedSCIFs andclassifiednetworks
Fig. 1 One release process for every system your program runs: current, legacy, and air-gapped.

We are now building an auto-updating system that keeps every user on the latest release. The engineering is in One source tree, every operating system: a CMake superbuild.

Results: every change reaches users the same day, everywhere

Every delivery the customer makes goes through the release system we built and run: developers only write features, and it brought new scope and follow-on work.

Engineering write-up: One source tree, every operating system: a CMake superbuild

Delivering into a SCIF: Developers inside a SCIF build releases with no network

Buy from us or team with us: Contracting

Send us the systems your software must run on.

Estimates are free. Send the scope through the contact form; we reply within one business day and send a written quote within five business days.

Get a free estimate