概要
公開日: 2026-07-23
翻訳生成に失敗したため、原文をそのまま保存しています。
原文
This is a guest post from David Davidov - a Founding Engineer at Posh - the social marketplace for real-world experiences that helps organizers create, scale, and monetize communities through events.  … After wrestling with lengthy app review cycles and time-sensitive manual releases, our team at Posh invested in rebuilding our mobile CI/CD pipelines to eliminate as much manual work as possible. For context, our app serves millions of users across iOS and Android, so delivering releases to the app stores safely, reliably, and on schedule has always been a top priority for us. That investment paid off, and the improved release velocity helped support our growth to charting the #1 app in the Entertainment category on the App Store. Posh competing with the big dawgs Discovering our pain-points Since I kicked off development for our mobile app over 2 years ago, I've always disliked the manual process of releasing via the stores. Our team knew about Expo Updates but before fingerprinting and EAS Workflows' pre-packaged jobs the process of automating OTA updates always felt a little janky with too much room for error. Some of the pain-points we faced in the last two years were: - No insight as to when a task on Linear was released to a certain app version. - Having to create a weekly rotating Release Train manager who was responsible for releasing that week's set of changes ← Our biggest bottleneck - Automatically integrating E2E tests into our release process - Having to kick off builds and submissions using unstable GitHub Actions that required lots of maintenance - Understanding whether an engineer's PR introduced new native changes All of these pain-points made developing on mobile feel like a chore rather than a creative, fast-moving experience. After revisiting Expo's advancements around fingerprinting, workflows, and OTA updates, I decided to redesign our release system from the ground up, automating as much of the process as possible while still preserving manual approval points where they mattered most. This automation helped us go from weekly manual releases to nearly monthly store releases and multiple OTA updates a week! What we wanted to solve for - An easier way of installing and testing new changes introduced in a PR while understanding if a PR introduced new native changes - A system that doesn't over-trigger EAS builds, only fire them when we're ready to start testing - Gracefully introduce OTA updates with an opportunity for them to be testable in a staging environment, changes merged to master should not be automatically deployed to production! - Reduce the need to create new version branches, introduce them when native changes get introduced to master - Automate away the hassle of notifying our team when new versions have been released to production & what changes those versions include I'll dive into how we managed to set ourselves up to spend less time releasing to production so you don't have to. Pre-requisites - I would recommend watching this video from Beto on splitting up your app environments, this will be needed for configuring specific update channels/app environments. You should be able to install development, preview/staging, and production builds on one device by the end of that tutorial. This also makes testing your app much easier since you can hop between the builds easier. - Configure Expo Updates with Expo Fingerprints on your project. Automation 1: Setting up PR previews This is not mandatory for the CI/CD workflow but it will help your team review changes faster, especially if you're into agentic workflows. After reading this article I was inspired to create an EAS workflow that comments on PRs with a QR code that installs the newly introduced changes on the development app. I won't go too deep on the code for this but I changed a few things on this workflow: - We don't build the app if a fingerprint was not found (cannot OTA to development). I felt like this would blow our credit usage a bit