Replies: 3 comments 2 replies
-
I think Strava's mobile release process is a well oiled machine at this point. We've been doing it this way for years. I'll talk through a couple different classes of builds (from the iOS context, but Android is on the same schedule).
Alpha (employees): Automated build runs at 2 AM PT every day (including weekends), this can be kicked off by any employee manually (mostly done by mobile engineers and rarely) through a Slack command that talks to our in-house build orchestrator/scheduler. This will create a new build on a macOS host, uploaded the dSYMs to our crash tracker, and push the build to an S3 bucket using Adhoc (employees): These are essentially the same as alpha except they're delivered via a separate S3 bucket and triggered manually by engineers when they want coworkers to test things. Largely this is done for pre-merge checks of designs or similar functionality. The engineer will have a URL available to send to anyone that's provisioned for the alpha builds that they can use to install this on their device(s). Beta (external user, press, and manual testing services): We utilize an "early" TestFlight submission to increase TestFlight beta approval speed when it's the real deal. We update it majorly once a week with a smaller update on Thursday for things like translations. This is also the build our external testing services runs so it's important that this is treated as a release-candidate. Similarly to the alpha, this build and submission to iTunes Connect is all scheduled and requires little hands-on maintenance from the person that's in charge of the release for the week. This build is shipped to all our external beta users through TestFlight. We utilize Zendesk and the rarely-checked-build-in-TestFlight-feedback to gather real world user feedback on the build.
Release (all users):
|
Beta Was this translation helpful? Give feedback.
-
hey @pepibumur , there is a lot of nice info about Shipit mobile, but as far as I can see it is not open-sourced, are there any plans to open source it? I believe that it is built on top of the shipit-core that you have in OSS? How much is on top of the core to make it work for the mobile use case? Would you recommend somebody to build it |
Beta Was this translation helpful? Give feedback.
-
Hi 👋, in @allegro we decided to take a weekly release train approach when submitting an app to the App Store. Release Train is technique for coordinating releases across multiple teams. All releases happen on a fixed and reliable schedule regardless of whether all expected features are ready (the train doesn't wait for you — if you miss it you wait for the next one). Each release is supervised by a tester who performs manually critical test scenarios and a release manager, who is responsible for monitoring mobile app quality and communicating problems to our iOS community on Slack. Our release process is divided into two GitHub Workflows. The first one -
While app awaits review, we perform "stability tests". They cover critical paths, like buying items with a wide range of payment methods. After critical paths tester also performs smoke tests. If everything works fine, app waits for the Apple team’s positive review and is released on Monday. When the review is completed, release manager starts a second workflow
After this stage, release manager starts the process of monitoring app stability using crash monitoring tools. For internal builds, we provide for our developers/testers, one of the three options:
|
Beta Was this translation helpful? Give feedback.
-
Hi there!
I haven't seen any discussion around this topic so I thought it'd be a good idea to start one to see what other companies are doing.
I work at @Shopify, and a few years ago we decided to move away from CI pipelines as the place to codify the release process. We have several teams doing mobile development, and each had its own release logic, which in some cases was complex and brittle. When things failed, they required support from my team, mobile tooling, to unlock their release.
We set out to build an internal solution for coordinating releases. We called it Shipit Mobile. The goal was to standardize the process across all the projects and own as much as possible from it to make sure that we can optimize it and improve it without much work on the product team's side. The natural technology choice for us was a Rails app. We wanted it to be server-side to be able to build integrations with Buildkite, GitHub, Slack, and Google Cloud.
This is the release process that we proposed:
Because we own and design the service, we could design a UI that is friendly for people that are not developers. Moreover, we could build integrations with Slack. For example, we notify a developer when a candidate is ready to be published, or when Apple has finished processing the artifact.
Later on, we decided to move away from App Center, and leverage Shipit Mobile for doing internal releases too. We called them snapshot builds. Unlike the traditional "nightly builds" that are triggered from the main branch, we allow developers to trigger builds from any commit. They do it from the UI of Shipit Mobile, but we have plans to support triggering from PRs. Because we are not using App Center, we made it super easy to install a build. Basically, you only have to sign in with your Google account and that's it. Moreover, we are building features on top of it like the possibility of providing feedback after installing a snapshot build.
One thing worth mentioning in regards to how we do internal builds is that we made the build number an implementation detail. We noticed that using the build number to refer to a build adds unnecessary friction:
Instead, when Shipit Mobile builds those builds, we pass contextual information such as the commit, branch, PR, author... That way you can easily know what you have on your phone.
In hindsight, building this service was a great idea because we have several teams doing app development, but it's a fairly large undertaking if you are a small company.
How are you doing store and internal releases?
Beta Was this translation helpful? Give feedback.
All reactions