CI/CD, Signing & Release Interview Questions
BUILD & TOOLING › Delivery
Walk me through the full pipeline you'd consider well designed, from a developer merging a PR to a build showing up on a tester's phone.
What a strong answer covers: A PR triggers CI for lint, unit tests, and a debug build; merging to main triggers a release pipeline that bumps the version code, builds a signed AAB using secrets pulled from a secrets manager rather than committed to the repo, and uploads it via Fastlane's supply action or the Play Publishing API to an internal or closed testing track. A well-designed pipeline also gates promotion between tracks on manual approval or automated signals like crash-free rate, rather than auto-promoting straight to production.
Your CI pipeline is fully green, tests pass, the AAB is correctly signed, but Play's own review flags or rejects the upload anyway. What does that tell you about the limits of CI signal, and how would you catch this earlier?
What a strong answer covers: CI can only verify that code compiles, tests pass, and the artifact is well formed and signed; it can't replicate Play's server-side policy and content review, like permissions justification or target API compliance, so a green pipeline is necessary but not sufficient for a successful release. Catch it earlier by routing through closed or internal testing tracks first, which go through a lighter review, and by watching Play Console's pre-launch report and policy status proactively instead of treating CI green as ship-ready.
Two teams want to auto-deploy straight to the production Play track from CI with no human in the loop. What would make you comfortable approving that, and what safety nets would you insist on first?
What a strong answer covers: Insist on an automatic staged rollout that ramps by percentage gated on real crash-free and ANR-rate thresholds pulled from Play vitals or Crashlytics, auto-halting if a threshold is breached, plus a fast, reliable kill switch such as remote config or feature flags, since Play has no true rollback, only a new higher version code. Also require the release-signed, minified artifact itself to run through the full automated test suite, not just a debug build, because without those nets an unattended broken release has no automatic detection path before it reaches everyone.