Skip to main content
A 30-day trial of Aspect Enterprise answers one question: are your builds faster? Your existing build and tests run on the deployment’s remote execution fleet and remote cache, on the same commits as your current CI, without blocking anyone, and you compare the two. Aspect stands up the deployment, sized from a first estimate, sets up worker pools for your toolchains and gets your build running on them. Talk to us to start one, and agree at the start what result counts as a success.

​
What to measure

​
Setting up the comparison

1

Take a baseline

Record the metrics above on your current CI over a week of ordinary traffic, before you change anything.
2

Add a trial job to your current CI

A job next to your current ones runs the same build and test steps against the deployment, through its external endpoint, with an API token Aspect issues. Mark it so a failure can’t block a merge. has the steps.
3

Turn on remote execution

Register the exec platform Aspect gives you for each worker pool, and add --config=aspect-exec to the trial job’s bazel calls. Your current CI and every developer’s build are unchanged. See Targeting remote execution worker pools.
4

Measure the same things on both sides

Run on pull requests, on main, or both. Pull requests give you the numbers developers feel; main gives you a steady stream of comparable builds.
To measure CI runners as well, run the trial job on a in the deployment, in the same VPC as the cache and the fleet. Developers can try it from their laptops with .

​
Comparing fairly

  • Same commits. The trial job runs on the commits your current CI already builds, so both sides see the same changes.
  • Separate the cache from remote execution. If your current CI has no remote cache, run the trial job with and without --config=aspect-exec too, so you see what each adds.
  • Count the network path. A trial job on your current CI reaches the deployment over the internet through the external endpoint. Runners inside the deployment’s VPC don’t pay that latency, so the trial job is a conservative measure of them.
  • Warm against warm. The first builds on a new deployment are cold by definition. Compare after the cache has seen a few days of traffic.
  • Tune before you judge. Worker pool sizes, scaling limits and Bazel’s own parallelism change the numbers. Work through Parallelize remote execution and Optimizing your Bazel build, and for runners Optimizing CI runners, before you take the final measurement.
  • Count what ran locally. Tests kept off remote execution, such as those tagged no-remote-exec because they reach a service only your CI can, still run on the job’s machine. Say how many there are.
For a published example of this kind of measurement, with the infrastructure configuration and public CI runs, see the AOSP build benchmark.