Xcode Cloud only supports Apple’s platforms. Xcode Cloud vs AppCenter Platform support Some of these features are available on other platforms of course, but since Remotion is a macOS native application the Xcode integration and first class macOS support are key.
Workflows don’t have to be tied to a single branch, you can start one off builds on any branch (looking at you AppCenter…)Ĭan be used for all of our CI needs (YMMV) Super configurable, yet easy to understand, build settings (check out some great examples of the flexibility of Xcode Cloud’s settings in the slides from Pol Piella Abadia’s great NYSwifty presentation) New versions of Xcode and macOS are usually available the same day as they are released (including betas) Integration with Xcode (and feels familiar to someone used to configuring projects in Xcode) MacOS is a first class citizen! (some CI platforms are mobile/web focused, like Bitrise) Some of the reasons we chose Xcode Cloud: We also considered Bitrise, and even almost got that working for our builds. Xcode Cloud wasn’t the first tool we considered migrating to. We first actually started investigating Xcode Cloud for deployment builds, but when I discovered how easy it was to integrate with GitHub I turned that on first, and arguably that has been much more valuable given how easy it was to enable.
#Xcode cloud review manual
That gives us a low cost, high value addition to the manual code review, and it has saved us a considerable amount of time since turning it on. Xcode Cloud in turn is configured to automatically build Remotion in release mode for all new PRs that are going to merge to master.
We have some branch protection rules turned on for the master branch, including "Require status checks to pass before merging”. That is where Xcode Cloud’s integration with GitHub comes in. That means the build will work when you hit Run in Xcode, but fail once you try to build for production. The most common issue we ran into was forgetting to wrap some debug code in an #if DEBUG check, which causes release builds to fail while debug builds succeed. And if we merge broken code then our CD system can’t provide us with builds for us to test. We can discuss logic and argue about style, but only the compiler can tell us if our code is legal. There is one thing that no number of human reviewers are likely to find in a review though, and that is if a given change is actually going to build. (I plan on covering the automatic build process for our internal testing in another post.) We then dogfood what was just merged in internally, allowing us to quickly find issues. We believe that code review is very important to help ensure quality, but we only require one reviewer to approve a PR since there is a point of dimensioning returns when you go past one.
#Xcode cloud review how to
If you’d just like to see a quick tutorial on how to use Xcode Cloud with GitHub to check PRs build before you merge them, skip to the end. In later posts we’ll cover other topics like how we use CD to release 5-30 internal builds for testing each day, how we validate builds before we release them, and what our distribution process looks like. Today we’ll cover how we use Xcode Cloud to help us ensure quality in our PR process, while keeping developer friction to a minimum. But quality and speed are normally thought of as two ends of a spectrum, so how do we do that exactly? What does our process look like that lets us both release fast and maintain quality? At Remotion we aim to release fast as part of our strategy to maintain quality.
0 kommentar(er)
