|
Continuous integration is a piece in the software development lifecycle that we've taken for granted. It's that element that ensures our changes do what they are supposed to do and adhere to some conventions. When checks are green and we've got the required reviews, our PRs are ready to merge. One can think of this as a recursive function: push, feedback (CI or human), change, push, feedback... and eventually merge. If you think about it, little has changed or improved in how we do CI. We are still required to push YAML files upstream to get them validated. We can't simulate the execution of the pipelines locally because the pipelines and scheduling logic are proprietary solutions that organizations are not willing to trade off for a better developer experience. In the case of our scripting, we are stuck with Fastlane, even though most people in the ecosystem would prefer to be writing Swift. I was personally excited when Apple acquired BuddyBuild, but the excitement faded when I saw how it materialized as Xcode Cloud. Apple (understandably) uses their control over Xcode to compete with a more tightly integrated solution that still doesn't solve the aforementioned problems. In today's CI, you have weak ownership over your remote automation. It's by design. Some people have accepted that's how things are, and we did too for a long time. But Dagger, created by the founder of Docker, has recognized this issue and has started building a solution. Think of it as a CI engine that's platform agnostic. In other words, you can run your pipelines locally or remotely using the same engine, so no more pushing to see if the YAML is valid or how it behaves. Would the same idea work in the Apple ecosystem? I strongly believe so. The execution would need to be different because Dagger uses Docker, and virtualization of macOS images is costlier (images are more heavyweight), but the idea of decoupling the engine from the platform is something worth exploring. Fastlane is in fact a step in this direction. It simplifies pipelines by moving their logic to scripts, but it's not sufficient. There's still a dependency on certain CI capabilities, like caching, which is usually built into the pipeline, or steps, which are usually provided from a proprietary marketplace. Imagine if caching needs were declared in comments in your scripts (or Fastlane lanes), and steps became Swift Packages that you could depend on. And the installation of tools? That's something Mise is exceptional at. What would that all mean? That pipelines can be reduced to mise install && mise run x, you become the owner of your automation, have the freedom to port it to the platform that aligns best with your needs, and you have a better experience debugging it. I don't know about you, but this is a future I feel like enabling.
|
