TLDR; Bitrise’s caching solution is the most efficient way to increase your build speed and optimize your workflow. Talk to us today.
You’ve been asking for features around caching your CI/CD pipelines to help speed up your builds and generally make developer work easier. These include 1) having explicit and granular control on what to cache, 2) sharing a cache across workflows, branches, and stacks, and 3) automatically invalidating stale files in a cache.
Bitrise’s mission is to help speed up your mobile app development process and build great apps, even faster. And we’re happy to say that we recently made changes to the Bitrise dependency cache offering that will provide you with all this and more.
In this article, we provide a quick run-through of some of our most recent dependency cache updates. Some are new additions to the Bitrise dependency caching solution, whilst others include more major improvements.
CI/CD caching with Bitrise is a series of articles that takes you through all there is to know about caching. Other caching articles in the series currently include What is a cache, and why should you care about caching? and Dependency caching with Bitrise.
Cache rules
Our older cache system relied on the Cache Pull and Push steps.
With our most recent dependency cache update, you have finer controls over setting up Cache rules, which can be configured using our new Save Cache and Restore Cache steps.
Alternatively, if you want to enable caching without any manual setup, you can do so with our new dedicated Cocoapods, SPM, Gradle, and NPM cache Steps.
Cache scope
Older branch-based caching was limiting in terms of the flexibility developers had with the cache scope. When you and another developer, for example, were working on different branches, a cache entry created by branch A was not available in builds running on branch B.
With the latest dependency cache improvements, developers can share a cache across branches. This helps caches remain relevant and fast.
Restoring cache entries
In our previous dependency caching solution, stored cache entries were linked to a specific Git branch. When a build was kicked off, with the cache Pull Step included at the beginning of your workflow, caches automatically got restored leaving you with no say over which cache entry to restore for your build - slowing the build down.
Changing that today, we’re giving you more control over restoring cache entries. You can now fine-tune which cache entry a workflow restores based on custom rules, so your builds always use the most relevant cache — speeding up your build time. You can also define fallback rules to restore partially matching cache entries; when there is no exact match, restoring a partially matching cache still speeds up builds.
Cache performance
Bitrise’s new caching products enhance your build performance in two ways: 1) with a faster, more efficient compression algorithm, and 2) by getting rid of outdated cache files.
Faster cache steps
When it comes to handling large caches, we eliminated bottlenecks and switched to a faster and more efficient compression algorithm, making every cache operation faster.
Being more efficient in choosing what to cache
We've updated our caching logic for all supported platforms, so that the steps only cache the files that are needed, making cache archives smaller. At the same time, we now give developers the chance to fine-tune the caching parameters and choose what to cache and how to discard old cache entries.
Caching then, and caching now
Our recommendation: Instead of storing cache entries per branch, share the cache between branches by setting up cache keys with content checksums (instead of adding the branch name to the key). If you use one of the dedicated steps, this is the behavior that the steps set up for you.
Benchmarking performance compared to the old cache solution
We made some benchmarks on larger open-source app codebases, testing the performance and efficiency of the branch-based and dependency caching systems compared to our old caching solution.
Across a handful of iOS, Android, Flutter, and React Native codebases, we observed the following improvements with the new caching system:
In summary: Changes to Bitrise mobile CI/CD caching
To summarize our latest mobile CI/CD caching improvements:
Talk to us
Use our cache out-of-the-box Steps in your builds today. Register your interest in caching → select Products Features and Plans from the drop-down and put “Caching” in the Further Details box.
You can also visit our dev center to learn more about caching with Bitrise’s dependency caching, branch-based caching, and more.
Happy caching!