Flare.build joins the Mobile Native Foundation
Flare is very excited to announce our support for the Mobile Native Foundation:
a place to collaborate on open source projects and discuss wide ranging topics in order to improve processes and technologies for large-scale Android and iOS applications.
We look forward to collaborating with the community on many projects related to our core vision of decreasing friction and boosting productivity for teams creating applications at scale. In particular we aim to contribute some of our solutions around scalable remote builds as well as collaborate with key community members on a standardized mechanism for sharing and visualizing build & test metrics with an emphasis on large-scale mobile teams.
We discuss the Mobile Native Foundation with Keith Smiley on our recent episode of The Bazel Show, be sure to check it out for additional insight as well as an inside look into some of the issues around building iOS applications at scale using Bazel.
More exciting announcements coming soon!
Flare.build: more than a Bazel company
As our earliest customers know, Flare was the first-ever company started with the explicit goal of offering Bazel SaaS products and services in 2019, and since then, we’ve been thrilled to watch the community grow as more and more awesome companies have adopted the tool - the bet paid off! However one thing has become increasingly clear: onboarding to Bazel is still a huge challenge and a multi-year endeavor at scale in most cases, and it is often the case that specific teams lag behind the rest of the organization in adoption (oftentimes mobile teams, and for very understandable reasons). As an answer to this, we’ve begun the work of integrating additional build and test tools into our platform as part of our effort to meet customers where they are instead of only upon successful completion of a migration effort, immediately unlocking much of the same value we provide to customers already building and testing with Bazel. (This is actually not a new development; since early 2020, we’ve also provided the fastest and the only commercially available build cache solution available for Buck, a build tool inspired by Bazel).
A huge added benefit of adopting our standard tooling across teams and disparate build systems is the gathering and retaining the metrics driving DevX KPIs during or even absent a build tooling migration, something that can be challenging. By adopting flare.build before a full build system migration, it’s possible to easily retain continuity in this critical data, as well as minimize disruption to the developer experience.
In 2021, we’ve doubled-down on broadening our support with a series of integrations and acquisitions that expand our offerings far beyond Bazel and even into other stages of the software development lifecycle than the development phase (details coming soon). This month, we’ve taken the next step towards supporting our customers using other build & test tooling with our announcement of Gradle support, with many more integrations to be announced in the coming weeks.
We’ve been hard at work at tons of powerful new features for Flare.build v2, and will be sharing the full details on the new product soon.
Flare.build Gradle Integration - now in alpha
As part of our team’s obsession with enabling happy development teams wherever they are, we’ve recently expanded our blazing-fast, CDN-backed remote build cache (originally targeting Bazel and any Remote-API compliant build system) to support the caching of cacheable tasks from Gradle builds! This is in addition to our existing support for Buck, a similar build system to Bazel, which we completed in 2019.
With our new Gradle plugin (currently available by request only) engineering teams can simplify their build infrastructure by utilizing any existing Bazel remote cache implementation as a build cache for their Gradle projects as well. This enables our customers to take advantage of the high-performance distributed cache solution we’ve created to speed up not just their Bazel and Buck builds, but their Gradle builds as well. Additionally, this allows us to create a unified view of build and test results organization-wide to further empower DevX leaders to monitor the developer experience across teams instead of siloed by platform or build tooling!
Benchmarks are coming soon and we’ll update this post when we’ve had more time to do a detailed comparison - speed matters.
We hope to open-source this plugin in the future, but in the meantime, reach out to info@flare.build for access!
Flare.build ❤️ Gradle!
Engineering in the time of COVID-19: Doing more with less
As a result of the impact global pandemic, the majority of organizations both small and large alike have frozen hiring and in some cases been forced to reduce headcount, making it all the more critical to ensure maximal engineering productivity.
In the past we’ve viewed the enhanced developer productivity offered by advanced build tooling such as Bazel as a mere competitive advantage, but now in some cases it is truly a matter of survival as almost every company in every industry has to do more with less.
Doing More With Less
As evidenced in a variety of case studies and talks by members of the Bazel community, for projects & teams of sufficient scale, the correct usage of Bazel or similar tooling in conjunction with value-adding products & services such as those we offer can dramatically reduce the overall spend on CI/CD compute & engineering talent by very large margins. Here’s how:
Individual developers local build times are greatly improved by Bazel’s caching mechanism, right out of the box—only the necessary files will be rebuilt on each build & only affected unit tests will be invoked
A centralized, shared build artifact cache allows clean, stateless CI workers to avoid a large amount of duplicate work without any worker-level caching
The shared cache also enables the reuse of previously built artifacts by all subsequent builds, whether CI builds or builds on developer machines—artifacts are simply fetched from the cache instead of being compiled
In some cases, remote execution can enable even further reductions in build times. This is a zero-sum gain in terms of compute costs (less total time at the expense of more CPU cores utilized), but still can enable shorter feedback loops in PR premerge checks etc, thus increasing productivity slightly
Taken together, the above items enable a highly efficient software development environment in which CI/CD costs can be minimized and developer productivity maximized, allowing an organization to ship more product with less budget.
The importance of a performant, scalable, highly-available shared cache cannot be overstated here—it’s truly the backbone of any healthy Bazel deployment. To that end, we’ve launched the world’s fastest remote cache as a fully-managed SaaS, and are accepting beta signups now. If you’re interested, let us know.
Should my organization adopt Bazel?
In order to realize the benefits of adopting an advanced build tool such as Bazel, at least 2 of the following should be true of your team:
build/test times are noticeably slow in CI and on developer machines (>10min)
Over 100k LoC
20+ engineers
Polyglot organization with many languages (and thus many build tools to manage)
Monorepo (or monorepo aspirations)
Other advanced build requirements (trusted build pipelines, etc)
How do I get started?
Migrating large amounts of code to build with Bazel can be a daunting task, but it is often well worth the investment if many of the above statements are true of your team or project. Here’s some resources to help you get started:
The official docs have a getting started section for newcomers.
Check out this post by Alex Eagle about things your programs shouldn’t do
Join the Bazel Community Slack
Get in touch with us and other community experts for additional support, training, and expert level consulting services
Flare is transitioning out of stealth...
Inbound inquiries have gotten to a point where we’re barely stealth any more and so we’ve made the decision to begin the transition out of stealth by activating our blog and introducing ourselves.
As (quietly) announced at Bazelcon 2019, Flare is the world’s first Bazel-focused product and services company. We’ve made a name for ourselves by assisting enterprises and high-growth, high-value startups migrate their build & test systems into Bazel, interacting with almost every major language and ruleset along the way, but we didn’t stop there - we also have launched a product line: flare.build.
Our founding team consists primarily of the Bazel group formerly at scal.io (one of the Bazel community experts) with the addition of key members of the wider Bazel community who share our vision.
Inbound inquiries have gotten to a point where we’re barely stealth any more and so we’ve made the decision to begin the transition out of stealth by activating our blog and introducing ourselves.
Items still not public:
Our branding is still in development and as such, everything you see here is a placeholder
Our products: nothing to announce publicly yet; we’re still gathering feedback from private alphas
Our roster: for privacy reasons, we’re not ready to list all of our involved members yet
To inquire about enterprise Bazel support, custom build rule implementation, or migrating to Bazel from legacy build tools, please reach out to info@flare.build.
More news to follow.