What to Fix First in Your Android CI Pipeline Before the Next Build Breaks

You push a commit. Slack pings: Build failed. Again. The Android CI pipeline—once a source of confidence—now feels like a leaky boat. You patch one hole, another springs. Before you know it, you're spending more time fighting the pipeline than shipping features. But here's the thing: not every fire needs the same extinguisher. You have to decide what to fix first, or the next build break might be the one that derails a release.

This article is for Android team leads and senior engineers who own the CI pipeline but don't have unlimited bandwidth. We'll walk through the decision framework, compare options, and give you a sequence that reduces pain without over-engineering. No vendor pitches, no fluff—just practical trade-offs.

Who Decides and By When?

The person holding the trigger

Most Android teams I work with assume the CI fix is someone else's problem. The lead engineer says platform should handle it. Platform says it blocks feature work. Meanwhile, every third build red-lights at the same Gradle configuration step — and nobody owns the fix. The truth: the decision lands on whoever wakes up at 2 AM to a failed Play Console submission. That might be you. It might be the senior engineer who hasn't touched CI since the repo migrated to version catalogs. Quick reality check — if you can't name the single person who can green-light a pipeline overhaul today, you don't have ownership. You have a hot potato.

Common trigger — silence before the seam blows out

Nobody decides to fix CI during a calm Tuesday. The trigger is almost always a missed sprint deadline or a production incident. I once watched a team lose two full days because their lint step silently skipped Kotlin source sets — no alerts, no log. The release candidate compiled fine locally. On CI it shipped a broken feature flag. That silence is dangerous. The second trigger: a new team member spends three hours wrestling with a local vs. remote environment mismatch. That day, the cost of ignoring the pipeline becomes visible in hours, not abstractions.

'We treated CI like a black box until the black box ate our release date.'

— Android lead at a mid-size fintech, after a six-hour rollback

Time pressure — how soon before the next release?

The calendar is your real constraint. If your next build window is three weeks out, you have room for a staged migration — maybe swap the Gradle wrapper first, then parallelize tests. If the release is tomorrow morning? Wrong order. You staunch the bleeding: disable the flaky check, freeze the Docker image, and schedule the real fix for the next sprint. That hurts. But pretending you have six weeks when you have six hours is worse. One rule of thumb I stole from operations engineers: if the fix takes longer than the gap between now and the next release candidate, you don't fix it yet — you contain it. The decision deadline moves from "who" to "when." Miss that window and the pipeline decays another cycle. Most teams lose three to four weeks per quarter on unowned CI rot. That's not a cloud cost problem. That's a decision vacuum.

Three Approaches to Fixing Your Android CI

Band-aid: quick wins like increasing timeout or disabling flaky tests

You know that sinking feeling when the build fails at 11:57 PM and your Android engineer is already asleep. The fastest path to green is tempting: bump the Gradle daemon timeout, retry the flaky Espresso test twice, maybe disable that one Compose test that hasn't passed in three weeks. I have seen teams cut their failure rate by 40% in two afternoons doing exactly this. The catch is—you haven't fixed anything. You just swept the broken glass under the rug. That flaky test will re-emerge during a release candidate, and the timeout bump masks a memory leak that grows every sprint. Quick wins seduce you. They let you ship today. But next month? Same CI fire drill, different test name.

The real trade-off: velocity now versus debt later. Band-aids work when your pipeline is on fire and your CTO needs a demo by Friday. They fail when you treat them as permanent. One team I worked with disabled seventeen tests over six months. No one documented why. Every new developer assumed those tests were irrelevant. The seam blew out during a major SDK upgrade—forty minutes of red builds before someone realized the disabled tests had covered the payment flow. That hurts.

Incremental overhaul: fix one stage per sprint

Most teams skip this approach because it requires discipline, not crisis management. You pick a single bottleneck—say, the lint step that takes eight minutes or the unit test suite that has cached itself into irrelevance—and you fix only that for the sprint. Wrong order? Start with the stage that fails most often, not the stage that runs slowest. A seven-minute lint warning costs you nothing if it never fails. A two-minute unit test that flakes 30% of the time destroys developer trust.

What usually breaks first is the dependency cache invalidation. You push a library update, the cache misses, and suddenly the full compilation clocks in at eighteen minutes instead of four. The incremental fix: store the lockfile hash as a cache key and invalidate stale entries weekly. That sounds trivial—and it's—but I have consulted on three Android CI pipelines where nobody had configured cache cleanup at all. The Gradle cache was consuming 12 GB of server disk, and builds were timing out because cleanup scripts never ran. One sprint, one stage. Result: CI reliability went from 68% to 89% in six weeks.

The pitfall here is scope creep. You fix the lint stage, but someone notices the emulator startup is slow, and suddenly you're rewriting the whole Docker image mid-sprint. Stick to one. If you can't name the single stage you will stabilize this sprint, you're already off track.

Full rewrite: start from scratch with modern tooling

Sometimes your CI pipeline is so rotten that band-aids fall off and incremental fixes feel like rearranging deck chairs on a sinking Gradle daemon. I saw a shop where the CI configuration file had 1,400 lines of shell script, four different SDK versions installed, and a homegrown test orchestrator that predated AndroidX Test. The build broke twice a week for reasons nobody could reproduce locally. They rewrote from scratch using GitHub Actions + Gradle Build Cache + a minimal Docker image that pulled only the SDK components actually needed. Build time dropped from 22 minutes to 9. Failures dropped by two-thirds. Sounded like a miracle—until the next sprint, when they realized they had lost all their flaky-test documentation and the new pipeline had no rollback strategy for the cache keys.

A full rewrite buys you a clean slate and forces you to adopt current practices—composite builds, configuration cache, non-blocking lint. But it costs you three to five sprints of CI instability while you re-learn every edge case the old pipeline had already solved. That said, if your pipeline is leaking memory or failing silently due to zombie Gradle processes, the rewrite is cheaper than debugging a decade of accumulated hacks. One rhetorical question: when was the last time you could run a fresh clone and get a green build in under twelve minutes? If you can't answer that, the rewrite option deserves a serious look.

'We spent two sprints rewriting the CI. The first green build felt like a trophy. Then we discovered we had no way to run the old integration tests on the new emulator image.'

— Android lead at a mid-size fintech, after a rewrite that recovered six months later

How to Compare the Options

Impact on developer velocity

Most teams skip this step. They look at CI speed alone—build time in minutes—and declare a winner. Wrong order. A pipeline that finishes two minutes faster but forces every developer to rebase three times a day isn't an improvement—it's a tax. I have watched teams adopt aggressive incremental compilation only to discover that their clean builds (still needed for release branches) now take longer because the caching layer adds overhead for uncached keys. The real question: does this change get a feature branch merged before lunch, or does it turn the afternoon into a game of 'wait for green then pray'? That sounds fine until your senior dev abandons the pipeline entirely and runs tests locally on her machine—defeating the whole point.

Measure the time between 'git push' and a reliable pass/fail signal for the average commit, not the fastest one. The catch is that velocity also includes the cognitive load of interpreting failures—a pipeline that spits out a cryptic Gradle daemon crash versus one that surfaces 'test X failed because mock Y returned null' changes how fast a human can pivot.

Maintenance burden over time

Approach A (the maximalist rewrite with containerized stages and a custom DSL) looks glorious on day one. By month four it's a skeleton you're afraid to touch. I have seen this pattern three times in production Android repos: a build engineer builds a beautiful machine, then leaves the company, and no one else understands why the base image pins Java 11 for one module but Java 17 for another. The maintenance burden hides in the seams—the stuff you don't touch every sprint. Configuration drift. Unused Docker layers. Deprecated lint rules that still run and fail every PR but nobody dares remove because 'it passed before.'

Pitfall: teams choose the option that required the least initial setup (running everything on a single GitHub Actions runner with no caching) and call it 'lean.' That works until the concurrent job limit hits during a release crunch and you're manually cancelling lint runs to free slots. The better framework: ask yourself what this pipeline looks like after three personnel changes and no documentation. Does it degrade gracefully, or does it need a specialist to breathe life back into it?

'Your CI is not a monument. It's a utility that should survive whoever configured it last.'

— overheard at a Droidcon build-tools roundtable, paraphrased from a CI engineer who had just migrated a team off a custom Jenkins pipeline that outlasted three DevOps leads

Risk of introducing new failures

Here the trade-off gets personal. The fastest fix to a flaky integration test is often 'skip it in CI and run it manually.' That fix trades a known failure for a forgotten one. A more dangerous pattern: you parallelize your instrumented test suite across four shards but don't account for device-level state collisions—now you've got a 15% flake rate that wasn't there before. Quick reality check—your Android CI has a fragility budget. If you spend it all on architectural changes (like migrating from Gradle Managed Devices to a custom emulator farm), you have zero room left when Google drops an AGP update that breaks your build caching.

That said, the risk of not changing anything is also a bet: the pipeline that works today will silently rot as dependencies age. What usually breaks first is the lint baseline file—nobody updates it for six months, then an upgrade forces 400 new warnings to be addressed in one commit. I advise teams to score each option on a simple three-point scale: 'reversible in one PR,' 'reversible in one day,' or 'requires a full rollback sprint.' If the pipeline change lands in the third bucket, you had better be sure the velocity gain is worth the potential fire drill. One rhetorical question to hold in your head: Would I still argue for this choice if the internet goes down at 4 PM on a Friday?

Trade-Offs at a Glance

Speed vs. stability

Pick one to prioritize first—you can't optimize both simultaneously on the first pass. Speed comes from caching, parallel Gradle modules, and trimming test scopes; stability comes from deterministic tooling, locked dependency versions, and retry-free acceptance scenarios. The catch is that aggressive caching (say, offline=true on every run) hides flaky dependencies until a dev pulls a stale artifact three days later. I have seen teams cut build time by 40% only to spend the next sprint unearthing corrupted Gradle caches. That hurts. The real trade-off: do you want a build that finishes fast but might silently skip a test, or a build that takes nine minutes but never lies about the result?

Your CI vendor often nudges you toward speed—faster pipelines mean cheaper compute bills. But engineers trust green builds that actually verify code. A six-minute false-positive green build erodes trust faster than a twelve-minute honest red one. We fixed this by adding a nightly "full build" that cleared all caches and ran everything from scratch; everyday PRs got the accelerated, cached path. That hybrid approach respected both needs without forcing a permanent choice.

Short-term cost vs. long-term savings

Every approach demands up-front time: rewriting Gradle configurations, containerizing the SDK environment, or migrating to Bazel. Most teams skip the cost estimate—they estimate the migration effort but ignore the six months of "fixing CI every Thursday." Wrong order. The cheapest option on paper (tweak scripts, hope for the best) usually inflates to three times the original allocation because each patch introduces a fresh breakage pattern.

Quick reality check—maintaining a fragile pipeline costs roughly 1.5 hours per developer per week in "why did this fail?" time. For a team of eight, that's a full developer-month lost every quarter. Spending two sprints to hardening the pipeline feels painful during planning, but the arithmetic flips after month four. The opposite trap? Over-engineering from day one. I have seen a startup pour three months into a Bazel migration for a single-module app. They lost velocity, lost a feature release, and never recovered the sunk cost.

• Cheap fix now: builds green quickly, but breaks recur weekly
• Reasonable investment: two sprints of cleanup, then stable for a year
• Gold-plated pipeline: impressive dashboards, same flaky tests underneath

Team morale vs. technical debt

Nothing kills a Friday afternoon like a CI amber alert triggered by a test that never passed consistently. The immediate fix—add it to the exempt list—takes ten seconds. The right fix—rewrite the test, stabilize the underlying API—can take two days. Teams choose the ten-second patch. Repeated. That debt compounds silently. Six months later you have 47 exempted tests, zero confidence in the pipeline, and every dev mentally runs "the real tests" on their local machine before pushing. That's the morale drain: when CI becomes the thing you bypass, not the thing that protects you.

"A CI pipeline that nobody trusts is worse than no CI at all—it wastes time without providing safety."

— internal postmortem from a team that deleted their entire test suite after a false-positive ship, only to regret it two releases later

The opposite extreme—strict policy, zero exemptions, every test must pass—creates its own resentment. Developers stare at a red build for a week because one integration test depends on a third-party mock that rotates tokens every Tuesday. That breeds cynicism. The middle path? Establish a "quarantine" workflow: flaky tests get moved to a separate CI job that runs overnight, issues a weekly report, but never blocks shipping. Engineers feel heard; the pipeline stays honest. That balance keeps the team's collective sanity intact while paying down the debt in measured chunks.

Choose your trade-off consciously. Speed now costs trust later; cheap fixes inflate to full-time maintenance; rigid rules kill motivation. The next chapter walks through an implementation path that dodges all three ditches—starting with the single change that gave us back two hours per developer per week.

Implementation Path After You Choose

Start with source control hygiene — no YAML fixes bad code

Most teams I’ve worked with fire up Jenkins before they’ve locked down the repo. Wrong order. You can tune Gradle until your laptop fans scream, but if engineers push directly to main or merge half-baked branches, your pipeline stays a firefighting simulator. Fix the gates first. Enforce branch protection rules: require pull requests, ban force-pushes, add a status check that blocks merges unless tests pass. Pair that with a pre-push Git hook that runs lint and a fast unit-test subset. The hook catches the dumb stuff — imports that won‘t resolve, rogue Log.v calls — in under two seconds. That alone cuts red builds by roughly a third, based on what I’ve seen across three mid-size Android shops. The catch? Hooks are local and bypassable. So you also need server-side rules that reject commits without proper signing or commit-message formats. Spend two days here, save the team twelve hours of CI triage per sprint.

One concrete example: a team I consulted had a monorepo with five Android modules. Developers kept breaking detekt configs because they edited .yml files directly on the CI machine — no lint stage, no commit hook. We added a pre-commit hook that runs ktlint --format and another that validates build.gradle.kts formatting. Within a week, pull-request build failures dropped 40%. That sounds good, but it revealed a harder problem: their test suite was a mess.

Stabilize tests first — then optimize build speed

What usually breaks first in an Android CI is a flaky test. Not the build cache, not the artifact storage — a Espresso test that flakes every third run because the emulator boots slowly. Most teams react by adding retries. That’s a bandage. Do quarantine first. Pull the flaky tests into a separate Gradle source set or mark them with @Flaky (there’s a JUnit extension for that). Run them in a separate pipeline stage — slower, but they won’t gate your main branch. Meanwhile, add retry logic only for network-dependent tests that genuinely can't be deterministic. The pitfall: teams keep adding retries instead of fixing the root cause. I’ve seen a project with maxRetries = 3 on ninety percent of tests — that just masks entropy. Instead, enforce a 5% flakiness budget: if a test fails more than once in ten runs, it goes into quarantine until someone rewrites it. The build time drops because you’re not re-running flaky garbage three times per push.

Quick reality check — fixing flakiness is tedious. It’s not glamorous. But it’s the single highest-leverage move for pipeline reliability. A stable test suite lets you eventually parallelize without false alarms. Without that foundation, parallel execution just amplifies noise.

Optimize builds — but only after test hygiene is solid

Once tests are reliable, turn to Gradle caching and parallelization. This is where many Android teams start — and they burn out. Why? Because optimizing a pipeline that breaks often makes no sense. You waste time debugging in-flight failures instead of enjoying the speed gains. The sequence: enable build-cache and configuration-cache (experimental, but stable enough on Gradle 8.4+). Then split your build into two Gradle commands: assembleDebug for lint and compilation, then a separate testDebugUnitTest command. Run both in parallel on different executors. That alone cuts wall-clock time by 30-40%. One trade-off you’ll face: parallel stages increase runner cost if you’re on a metered CI service. We fixed this by using a single large runner for the assemble step and two smaller runners for test shards. Not perfectly parallel, but cost-aware.

Then modularize your pipeline YAML. A monolithic 400-line configuration file is a ticking bomb. Split it into reusable fragments: one for lint, one for unit tests, one for instrumentation tests, one for publishing. GitLab CI includes or GitHub Actions composite actions work well here. The benefit? When a developer adds a new module, they don’t edit the main pipeline — they drop a small YAML snippet into that module’s folder. That hurts less when the build breaks.

Modularize the pipeline — avoid the monolith trap

Your CI configuration is code. Treat it like code: small files, clear responsibilities, no copy-paste. I’ve inherited a single .gitlab-ci.yml with 700 lines that set environment variables in fourteen different places. Changing one broke three unrelated stages. The fix: extract each stage into a separate file, then include them with local references. Use YAML anchors sparingly — they make debugging a nightmare. Instead, use a template engine like ytt or simple shell scripts that generate parts of the pipeline. The goal is that a new team member can read a single stage file in under two minutes.

Rhetorical question: How often do you refactor your pipeline? If the answer is “never,” you’ve already chosen a path — and it’s the wrong one. Pipeline drift is real: dependencies upgrade, tools deprecate, build flavors proliferate. Schedule a 30-minute review every sprint to check for dead jobs, unused artifacts, or cached dependencies that outlived their purpose.

End with a concrete next step

Stop reading. Open your CI dashboard. Pick the one stage that fails most often — likely a unit test or emulator boot. Apply the quarantine step: mark it @Flaky, move it to a slower stage, and set a budget for its cleanup. That one change will improve developer morale more than any Gradle optimization. Do it before the next build breaks.

Risks of Choosing Wrong or Delaying

Technical debt snowball effect

You skip one dependency update today because “it’s just a minor version bump.” Next month, that library jumps three major versions—breaking API changes, deprecated methods, and a migration guide that now reads like a novella. I have watched teams spend two entire sprints untangling a mess that started as a single afternoon’s chore. The Android Gradle Plugin is especially unforgiving: delay the AGP upgrade through two release cycles and suddenly your build scripts refuse to parse, your CI agents can’t find the SDK, and every developer workstation behaves differently. That’s not technical debt—that’s a fire that burns from both ends. The fix? Run your updates early, even if it means a red build for an hour. The alternative is a multi-week archaeology project nobody volunteered for.

Developer burnout and attrition

The build breaks at 4:47 PM on a Friday. Again. The junior dev who pushed the change didn’t run tests locally—too slow, they said—and now the whole pipeline is red for the fourth time this week. Morale dips. Then it dips lower. I have seen a perfectly good engineer quit because their CI pipeline felt like a hostile co-worker: unpredictable, loud, and never accountable. What usually breaks first is not a test but the team’s patience. The catch is obvious—when every merge becomes a gamble, people stop taking risks. They stop refactoring. They stop upgrading. They stop caring. That hurts more than any broken build. You lose the people who could have fixed the pipeline in the first place.

Missed release deadlines

You planned a Monday release. By Wednesday, the CI pipeline still can't produce a signed APK that passes Play Integrity checks. A wrong choice earlier—say, pinning a build-tools version that expired last quarter—now costs real calendar days.

‘We lost 72 hours because nobody wanted to touch the Docker image. The fix took fourteen minutes.’

— Lead Android engineer, after a delayed feature launch, told over Slack

Most teams skip the cost of rework when they estimate velocity. They assume CI will “just work.” It won’t. Every hour your developers spend wrestling a misconfigured pipeline is an hour they're not shipping features, fixing bugs, or sleeping. Miss one release date and you scramble. Miss two and your product manager starts asking hard questions about the team’s competence. The pipeline isn’t infrastructure—it’s your delivery promise. Broken promises stack up.

Security vulnerabilities from skipping updates

You postponed the ProGuard rule update because the build failed once. Now a transitive dependency with a known CVE sits in your artifact. Quick reality check: Play Console will flag it, and reviewers might hold your release. Worse—a malicious actor finds the gap before your team does. That pipeline delay just became a security incident. Wrong order. Not yet. That hurts. The trade-off here is brutal: a fifteen-minute fix today versus a breach notification tomorrow. I have seen teams choose the latter not out of laziness but because nobody had clear ownership over CI health. Don’t let “somebody else will handle it” become your attack surface.

Mini-FAQ: Common CI Pipeline Questions

Should we run lint on every commit?

Yes — but with a catch: don't let lint failures block the entire pipeline in the first ten minutes of a project. I have seen teams turn on every lint rule, hit 400 warnings on push, then immediately disable the check and never re-enable it. That hurts more than not running lint at all. Instead, start with two or three high-signal rules — UnusedResources, ObsoleteSdkVersion, WrongConstant — and treat lint as an advisory gate that hardens over time. The worst outcome? A developer waits 12 minutes for a build, only to have it killed because a variable name is three characters too short. Set severity thresholds per rule; common pitfall here is treating all warnings as equal. They're not.

Run lint on every commit? Absolutely. Block every commit on lint? Only after you've tuned the noise floor for two weeks. Otherwise you train your team to hate the tool.

How many parallel jobs is enough?

Start with three: one for unit tests, one for lint + static analysis, one for instrumentation tests. That sounds obvious — what usually breaks first is over-parallelization. I watched a team spin up eight parallel Gradle daemons on a 4-core runner; the CI agent spent more time context-switching than compiling. The build time actually increased by 23%. Your mileage varies, but the empirical rule I use: number of parallel jobs ≤ (available vCPUs − 1). Leave one core for the OS and the CI agent itself. Most teams skip this. They see "parallel" in the docs and assume more is faster. Wrong order.

The tricky bit is resource contention. If your module graph has deep dependencies — app → feature → core → library — parallel jobs idle waiting on the leaf module. Quick reality check: run gradle build --scan and look at the "Parallel execution" section. If you see more than 15% idle time per worker, you're over-provisioned. Drop to two parallel jobs and measure again. Three is often the sweet spot for mid-size Android projects; five is rarely worth the cost unless your CI plan charges per minute of wall-clock time and you have a monorepo with 30+ modules.

What about using Gradle build cache?

Use it. But configure it wrong and you will cache yourself into a corner. I have seen a project where the build cache was pointed at a shared network drive with 200ms latency — each cache hit took longer than a clean compile. The fix was a local .gradle/build-cache on the CI runner, plus a remote cache (like a self-hosted S3 bucket or BuildCache node) for cross-branch reuse. The remote cache cuts your full build from 14 minutes to 4 minutes once cache warming kicks in. However — and this is the pitfall — if you cache androidTest outputs with stale test resources, you get green builds that fail on device. We fixed this by separating test cache keys from compile cache keys. One team I consulted had a single cache configuration for everything; their instrumentation tests passed on CI but crashed on QA's phone for three sprints before anyone noticed.

That said, the remote cache is worth the setup pain only if your team runs more than 20 builds per week. Below that? Local cache alone saves enough.

When to consider a dedicated CI team?

When your pipeline becomes a part-time job for three engineers. Concrete threshold: if someone spends more than 8 hours per week firefighting build failures, tuning Gradle flags, or debugging agent flakiness, you need a dedicated role. I saw a 12-person Android team where two senior devs were effectively CI janitors — they shipped zero features for two months. The moment they hired a build engineer, feature velocity doubled. But don't overcorrect. A dedicated CI team for a 5-person startup is premature; you fix more by slashing unnecessary jobs and consolidating to one CI provider.

'We spent 11 months accumulating CI debt. Then we hired one person who rewrote the pipeline in three weeks. The rest of us had forgotten what a green build felt like.'

— Lead Android engineer, mid-size fintech app, 2023

The honest signal is morale. When developers stop pushing because "CI will probably fail anyway," you have a people problem masquerading as a tooling problem. A dedicated person can fix the tooling; the culture fix is on you.

Next step: audit your last 30 CI runs. Count failures by category — test flakiness, cache misses, agent timeouts. If one category eats 40% of red builds, fix that first. Don't hire a team to manage a mess you haven't diagnosed.

Final Recommendation Without Hype

Fix flaky tests first

When a build breaks, your first instinct might be to grab the lowest-hanging fruit—a faster emulator, more RAM, a parallel execution flag. I have seen teams burn two sprints optimizing Gradle daemon settings while their test suite flips green or red at random. That's not CI, that's a slot machine. Flaky tests erode trust faster than any speed bottleneck. A team that can't trust its own test results stops running them. They merge blind, push broken code, and then the real debugging begins at 11 PM on a Friday. So before you touch a single cache layer or Docker image, audit your flaky tests. Tag them, quarantine them, fix them or delete them.

Then address build speed

Once your pipeline returns stable signals—green means green—you can look at the clock. Slow builds cost focus, especially when a developer sits idle for twelve minutes waiting on a lint check. But here is the pitfall: optimizing build speed often introduces complexity. Multi-module Gradle configurations, remote build caches, incremental compilation flags—each comes with its own failure modes. We fixed this by measuring first. Three days of raw timing data told us that our AGP upgrade was pointless; the real bottleneck was a single resource merging task. Speed matters—but not if you break reliability to get there.

Automate only what the team can maintain

The seduction of automation is real. You see a CI marketplace full of plugins for lint, security scanning, screenshot diffing, performance regression checks—and suddenly your pipeline has thirty stages and nobody knows why step fourteen exists. Most teams skip this: they automate everything in a weekend, then spend every Tuesday untangling failures from tools nobody on the team understands. A wise habit—automate one thing, then live with it for two weeks before adding the next. If you're not reading the failure logs, you have over-automated.

“The best CI pipeline is the one your team actually watches. Not the one that runs silently and breaks at 3 AM.”

— paraphrase of a senior engineer who had one too many midnight Slack alerts

Revisit decisions quarterly

Android tooling changes fast—Gradle, Kotlin, AGP, even the CI platform itself. A decision that made sense in January might be dead weight by April. I have watched teams lock their CI configuration into a script that nobody dares touch, and then three months later they're running a deprecated NDK version because upgrading would require rewriting the pipeline. That hurts. Mark a calendar reminder every quarter: one afternoon, open the pipeline config, question every step. Is this still needed? Does it still pass? Can a human explain what it does? If the answer to any is no, cut it. Your next build will thank you.