TechPrufer
Get started
Slack
Slack logoSlack · Feature trail

Build System Performance

5 posts · Jan 2018 – Nov 2025

What this trail covers

This thread tracks the evolution of Slack's build system performance. Initial posts detailed the problem of slow builds (60 minutes) for Quip and Slack Canvas backends. This post details the foundational work to improve build performance by applying principles of caching and parallelization, similar to application code optimization. It introduces the use of Bazel and the necessary engineering work to ensure build units are idempotent, hermetic, and granular, leading to a significant reduction in build times. This post details the automation of a large-scale migration from Enzyme to React Testing Library (RTL) using a hybrid approach combining Abstract Syntax Tree (AST) transformations and Large Language Models (LLMs), achieving an 80% conversion success rate. It also covers the open-sourcing of the conversion tool.

All Slack trails
  1. Build better software to build software betterThis post details the engineering work required to make Quip and Slack Canvas backend builds idempotent, hermetic, and granular, enabling effective caching and parallelization with Bazel. It explains how to apply principles of caching and parallelization, similar to application code optimization, to build systems. The post highlights the challenges of deeply intertwined backend and build code, large build execution units, and cycles in the dependency graph that previously prevented Bazel from delivering speed boosts. It also discusses the importance of defining inputs and outputs for build targets and the benefits of Bazel's automatic caching and distribution capabilities when these principles are applied.
  2. Optimizing Our E2E PipelineThis post details the optimization of Slack's E2E testing pipeline by implementing conditional frontend builds using `git diff` to detect changes and reusing prebuilt assets served via an internal CDN. This reduced frontend build frequency by 60% and average build time from ~5 minutes to ~2 minutes, saving thousands of hours and terabytes of storage monthly. It also led to more reliable E2E results and the rediscovery of legacy code.
  3. Balancing Old Tricks with New Feats: AI-Powered Conversion From Enzyme to React Testing Library at SlackThis post details the automation of a large-scale migration from Enzyme to React Testing Library (RTL) using a hybrid approach combining Abstract Syntax Tree (AST) transformations and Large Language Models (LLMs), achieving an 80% conversion success rate. It covers the analysis of AST transformations, the exploration of LLM capabilities, and the final hybrid approach that integrates DOM tree collection and LLM control with AST. The post also announces the open-sourcing of the conversion tool.
  4. Mobile Developer Experience at SlackThis post details the efforts of the Mobile Developer Experience Team (DevXp) to improve the mobile engineering experience at Slack. It focuses on addressing developer pain points related to CI test job duration and test-related failures. For iOS, it describes the integration of Bluepill to shard tests in parallel, reducing execution time to 20 minutes, and the subsequent migration to Bazel with bazel-diff to achieve an average TTM of 9 minutes. For Android, it covers the development of the Fuel test sharder and the adoption of Flank, reducing TTM to under 20 minutes. The post also details the migration from Calabash to Espresso for Android testing, which reduced testing time from ~350 mins to ~60 mins, and the implementation of a system to auto-detect and suppress flaky tests, reducing test failure rates from 57% to 4%.
  5. BuildRock: A Build Platform at SlackThis post introduces 'BuildRock', a new build platform at Slack designed to address technical debt and scale issues with the existing Jenkins-based system. It details the migration to a stateless, immutable CI service running on Kubernetes, leveraging ephemeral and static agents. The post also covers the integration of SecOps into the build pipeline through vulnerability scanning, IAM, and RBAC policies. It highlights a shift-left approach with testing in blanket test clusters and pre-staging areas. Standardization is achieved through the Jenkins Configuration-as-Code (casc) plugin and centralized plugin management. State management uses EFS with automated backups and rollback. GitOps principles are enforced for infrastructure operations, with Jinja2 used for templating. Metrics, logging, and tracing are enabled using Prometheus, ELK, and Honeycomb. Service owners have control over build and deploy actions. The post also discusses a distributed ownership model where service teams manage their own systems on the platform.
  7. Keep webpack Fast: A Field Guide for Better Build PerformanceThis post details techniques for optimizing webpack build performance, including measuring build times using Node.js inspector and custom plugins, parallelizing work with tools like parallel-webpack and happypack, reducing workload by simplifying minification (disabling compression except for React DevTools compatibility), sharing code with CommonsChunkPlugin, skipping parsing for non-importing files, using exclusions for loaders, employing the DLLPlugin for vendor libraries, and stabilizing module IDs with records. These techniques collectively reduced build times by a factor of 10.