Skip to content

2024

  • in engflow
  • 7 min read

EngFlow 2024 Year End Wrap

As we look forward to 2025, we are grateful to our employees, customers, and the broader build community for the continued investment in achieving our mission of making developers productive and happy to keep Engineers in Flow.

Holiday baking

In 2024 EngFlow continued our multi-year track record of exponential growth. This year we onboarded some of the most complex and advanced engineering organizations across autonomous driving, e-commerce, SaaS, finance, and chip manufacturing, resulting in significant developer velocity and cloud cost savings for these teams.

EngFlow has become more than a platform provider - we are elevating the developer experience practice for our customers, continuously pushing the cost and performance innovation, passing the savings directly to our customers. We are connecting engineers working on similar technologies to share best practices and talent across the Bazel, Buck2, Chromium, AOSP, and CMake ecosystems. While doing that, we're enriching our customers with music and are making the planet a greener place (read more about this below)!

How to Evaluate Remote Caching and Execution

Between roughly 2006 to 2008, Google developed remote caching and execution technologies to scale its massive monorepo based software development operation. This platform included Forge, the remote caching and execution platform, and Blaze, a tool for building large multilanguage software projects, eventually open sourced as Bazel. The advantages of this original platform were so obvious that it literally sold itself, and ultimately inspired the EngFlow platform.

Today, EngFlow is one of several competing remote caching and execution products now available in the commercial space. This post describes how we continuously benchmark our own product against different configurations to ensure that we offer the best possible value. We hope that sharing our methodology might help you evaluate whether remote caching or execution is right for your organization.

Build Meetup in Tokyo — Recap

Co-hosted by EngFlow and Google, the build community in Tokyo came together for an afternoon of tech talks and a happy hour filled with beverages and good vibes.

The event went straight into talks, starting with introductory words from our Google host, Philipp and EngFlow Developer Support Engineer Kip. The talks that followed spanned build systems and build issues:

Following the talks, we headed out to a nearby bar for some canapés and drinks, meeting fellow build engineers and enthusiasts from around the region.

Migrating to Bazel Modules (a.k.a. Bzlmod) - Repo Names, Macros, and Variables

The previous two posts in this series showed how to use runfiles mechanisms and rules_pkg mechanisms to avoid dealing with canonical repository names under Bzlmod. However, one special case remains: when you need to depend on the name of a repository directory, either at build time or runtime. This post explains how to access canonical repository names in a portable way to solve such problems. We'll use a macro when we can, and a custom Make Variable when we can't, including when dealing with alias targets.

CMake & Bazel Meetup in Munich - Recap

Fire up your time machine and set it to July 18, 2024, because we're taking a trip back to the CMake & Bazel Meetup in Munich. Let's set the scene: EngFlow and Apex.AI have joined forces to host a day filled with insightful talks and networking opportunities at Apex.AI's office in Munich.

CMake & Bazel Meetup - Jul 2024 - Munich

The CMake & Bazel Meetup in Munich

There was no shortage of great talks and knowledge, including: - Welcome and Introduction by Dhruv Chad, Apex.AI - Deploying With Bazel on Yocto-based System by Evgeny Petrov, Quello - Automatically Translating Our Bazel Codebase to CMake by Nico Morin, Apex.AI - CMake CPS: What It Is and Why It Matters by Damien Buhl, Tipi - One TOML File to Rule Them All: Official Rules for Multi-Version Multi-Target Python Setup by Michael Krasnyk, Ruumi - Until Next Time

Migrating to Bazel Modules (a.k.a. Bzlmod) - Repo Names and rules_pkg

The previous post in our Bzlmod migration series demonstrated how to make runfiles paths portable to a Bzlmod world. Another common source of Bzlmod file path breakages are misconfigured rules from rules_pkg, which contains rules for building archives from build outputs and/or external repositories. This post will explain key details of some of these rules, so you can stop "holding it wrong" and easily migrate archive targets to Bzlmod.

Sydney: Around the World with Bazel in Watercolors

This article is part of the series "Around the World with Bazel in Watercolors".

As the images hint, I was mostly inspired by the rich Tasmanian landscape, which is where we went on a family vacation. I did, however, sandwich that week between working for a week in Sydney and a week in San Francisco. In Sydney I couldn’t pass on an opportunity to meet with our customers while visiting family, and to gather local engineers passionate about Bazel (all 10 of them! 😃) from Canva, Splunk, Snap, MongoDB, and more for a Bazel meetup.

Sydney Watercolors

Migrating to Bazel Modules (a.k.a. Bzlmod) - Repo Names and Runfiles

The first post in our Bzlmod migration series explained many of the problems that may arise when migrating your project. These next three posts will explore various solutions to problems arising from changes in how Bazel handles repository names under Bzlmod, beginning with runfiles paths. After applying the techniques in this post, your project should be well insulated from runfiles path related breakages, now and well into the future.