Fullstaq Ruby is a server-optimized Ruby distribution: 50% less memory, faster, easy to install and security-patch via APT/YUM.

We've reached an important milestone in the Fullstaq Ruby roadmap. Epic 3 introduces a continuous integration and deployment system! This means that from now on, we can release updates much faster, and with fewer defects.

We put the CI/CD system to the test right away, and used it to release Ruby version updates. We now package Ruby 2.7.1, 2.6.6 and 2.5.8.

Additionally, we now support Debian 10 (contributed by Nathan Broadbent).

Want to install or upgrade? Check the installation instructions, or run apt upgrade/yum update.

In this article I'll explain why having a CI/CD system is so important. I'll also give you a sneak peek into what to expect in the near future.

Why CI/CD is a game changer

Maintaining Fullstaq Ruby is a huge undertaking. We package a number of Ruby versions, we support a number of distributions, and we support three different memory allocator flavors. This results in a combinatorial explosion: every Fullstaq Ruby update involves building almost 100 packages! As we support more and more distributions, the number of packages increases exponentially. This is a logistical nightmare for maintainers:

  • Long building times
    Building so many packages takes a long time and requires a lot of computing power.
  • Long testing times
    Testing so many packages takes a long time too. A maintainer is inclined to test a smaller number of configurations in order to get feedback more quickly, but doing so risks missing a defect that would've occurred in a different combination.
  • Forgetting to bump a version number
    It's easy to make a change, but forget to bump a relevant package version number. If this happens, then we would've released updated packages without a version number change, meaning that users' package managers won't actually see any updates. We have a release checklist which documents which version numbers to bump in response to which changes, but relying on a manual check like this is waiting for problems to happen.
  • Forgetting to upload a file
    With so many packages, it's easy to forget to upload some files to the repository server. In fact, this has happened a few times in the past.
  • Forgetting to publish a Docker image
    We use Docker to manage our distribution-specific build environments. If one makes a change in a build environment, then it's easy to forget to build and publish the updated Docker image. This results in problems for another maintainer who's on a different machine, who would wonder why s/he's getting a Docker pull error.
  • Hard to contribute
    All this complexity, and the long testing time, makes it hard for people to contribute a change. It also takes significant effort, for both the contributor and the reviewer, to verify the quality of a contribution.
  • Demotivating
    All of the above results in a psychological barrier. Making any updates becomes an annoying chore, resulting in fewer or slower updates.

Our CI/CD system solves all of the above problems:

  • It builds all possible packages using Github Actions. Github Actions has a lot of computing power, and is capable of building many packages in parallel.
  • It also tests all packages. Unlike testing from local files, the CI/CD system uploads packages to a staging repository server, and tests packages from that repository. Testing from a repository instead of local files is more representative of production conditions, and can catch defects that a local file test would miss.
  • It checks whether all version numbers have been properly bumped. This automates our release checklist.
  • It checks whether any build environment Docker images have been updated, and builds and publishes them if necessary.
  • When building on master, It uploads built packages to the production repository.

Releasing a Fullstaq Ruby update used to require a full day of attention. With this CI/CD system, it has been reduced to a triviality: edit a config file and let the system take care of the rest.

What does the future have in store?

In the short term, Ubuntu 20.04 and RHEL/CentOS 8 support is coming.

The goal of the next major milestone — epic 4 — is to improve the long-term sustainability of the project.

One problem with many open source projects, is that they depend a lot on the original maintainer. If that person or party ceases work, then there is a big chance that the project becomes abandoned. Even though forking is a theoretical possibility, it is far from guaranteed to happen.

We at Fullstaq are open source enthusiasts. We help small and medium businesses with succeeding at cloud native paradigms, and open source stacks are our favorite. Not only do we want to prevent Fullstaq Ruby from suffering the aforementioned fate, we also fully realize how important it is for people to be able to rely on an open source project.

So what is the solution? The answer: encouraging external contributions. By making it as easy as possible for anyone to contribute, we reduce the dependency of the project on any one part. The CI/CD system brings us a long way towards achieving this goal, but we're not there yet. Epic 4 focuses on contributor documentation, processes and organizational aspects.

Want to stay up to date? Follow @honglilai or @fullstaq on Twitter.