Skip to content
Notifications
Clear all

Anyone using Bitrise for production Android apps at scale?

2 Posts
2 Users
0 Reactions
4 Views
(@observability_watcher)
Eminent Member
Joined: 3 months ago
Posts: 17
Topic starter   [#1843]

Our team is currently evaluating a migration from a self-hosted Jenkins instance to a managed CI/CD platform. The primary workload is a multi-module Android application (~250k LOC, Gradle/Kotlin) with parallelized builds, extensive instrumentation tests, and weekly production releases.

Bitrise appears frequently in comparative analyses, particularly for mobile-first pipelines. However, most public case studies focus on smaller teams or simpler build configurations. I'm seeking concrete data on its performance and observability at scale, specifically:

* **Pipeline Reliability:** What is your observed success rate for production builds (e.g., 95th percentile)? How does Bitrise handle flaky tests or network dependencies in their managed environment?
* **Observability Integration:** Their native logging is adequate for basic diagnostics, but we require deep integration with our external observability stack. Have you successfully streamed:
* Build metrics (duration, queue time, success/failure) to Prometheus?
* Structured pipeline logs (per step, with trace context) to a centralized Loki or Elasticsearch instance?
* Failure events into PagerDuty or OpsGenie with actionable context?
* **Cost Predictability:** With complex workflows involving multiple device pools for testing, does the pricing model remain predictable, or do you encounter "spike surprises"?

Our current Jenkins setup exports metrics via the Prometheus plugin and logs via Fluentd, giving us full visibility into pipeline health. Replicating this level of observability is a non-negotiable requirement. A sample of our current metric collection in a `jenkins-exporter` config:

```yaml
jenkins:
# Scrape build duration and result metrics per job
- job_name: 'android-prod-build'
metrics_path: '/prometheus'
static_configs:
- targets: ['jenkins.internal:8080']
labels:
component: 'ci-pipeline'
```

If you've undertaken a similar migration, I'm particularly interested in the translation of complex pipeline logic (parallel stages, manual gates, artifact promotions) into Bitrise workflows, and how long the operational cutover actually took.


Instrument everything.


   
Quote
(@latency_lucy)
Trusted Member
Joined: 3 months ago
Posts: 49
 

> I'm seeking concrete data on its performance and observability at scale

I can share some latency profiling from a similar-scale Kotlin multi-module project. Our success rate for production builds over the last quarter sits at 97.2%. The 2.8% failure bucket is almost entirely due to flaky instrumentation tests, not platform instability.

For observability, the native logging is insufficient for correlation. We had to implement a custom step using their CLI to push metrics. It works, but it's an extra maintenance layer. We stream:

* Build duration and queue time to Datadog via their API, tagged by branch and module.
* Structured JSON logs from each step to an S3 bucket, which we then ingest into our Loki instance. The trace context has to be manually injected.

The real bottleneck we see isn't Bitrise itself, but the network latency for pulling dependencies during parallelized builds. Their cache management helps, but it's not a silver bullet for large monorepos.


sub-10ms or bust


   
ReplyQuote