One thing worth mentioning in regards to how we do internal builds is that we made the build number an implementation detail. Moreover, we are building features on top of it like the possibility of providing feedback after installing a snapshot build. Basically, you only have to sign in with your Google account and that's it.
#Shipit mobile app wikpedia install
Because we are not using App Center, we made it super easy to install a build. They do it from the UI of Shipit Mobile, but we have plans to support triggering from PRs. Unlike the traditional "nightly builds" that are triggered from the main branch, we allow developers to trigger builds from any commit. Later on, we decided to move away from App Center, and leverage Shipit Mobile for doing internal releases too. For example, we notify a developer when a candidate is ready to be published, or when Apple has finished processing the artifact. Moreover, we could build integrations with Slack. Once the app is released, they mark it as complete on Shipit Mobile and we create and commit and tag it with the version that has been released.īecause we own and design the service, we could design a UI that is friendly for people that are not developers. The developer takes the final steps on the developer portal.When a candidate is built, Shipit Mobile takes care of uploading the assets to App Store Connect and Google Play, as well as the dSYMs and source maps to the error tracking platform (in our case Bugsnag).We subscribe to Buildkite's webhooks to get updates about the status of the build. Builds run as CI pipelines on Buildkite.Shipit Mobile receives webhooks from GitHub and turns them into a build of the app bundle. The process of triggering candidates is as easy as pushing commits to the release branch.A release might require several candidates until there's one that is uploaded to Google Play / App Store Connect.The resulting build from that commit is called "candidate" Shipit Mobile creates a release branch and a commit with the version bump.From the list of commits, they pick the one that they'd like to release.Developers go to their project on the platform.This is the release process that we proposed: We wanted it to be server-side to be able to build integrations with Buildkite, GitHub, Slack, and Google Cloud. The natural technology choice for us was a Rails app. 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. We set out to build an internal solution for coordinating releases. When things failed, they required support from my team, mobile tooling, to unlock their release.
We have several teams doing mobile development, and each had its own release logic, which in some cases was complex and brittle. I work at and a few years ago we decided to move away from CI pipelines as the place to codify the release process.
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.
0 kommentar(er)
