Veröffentlicht am 16. Januar 2025
In den letzten 10 Jahren haben wir bei HeapStack in unseren App-Projekten, egal ob in-house oder in Kundenprojekten, stets folgendes Prinzip erfolgreich angewendet:
Git ist die Basis. Neue Features, Bugfixes oder Änderungen werden in kurzlebigen Branches entwickelt und via Pull-Request einem Review unterzogen, bevor das Ergebnis in den aktuellen Versions-Branch wandert. Für so ein Review ist es neben anderen Dingen wichtig zu wissen, dass (Unit-)Tests durchlaufen und dass Änderungen, die häufig mit Anpassungen in UI und UX daherkommen, auf verschiedenen physischen Geräten und nicht nur in Simulatoren oder Emulatoren funktionieren. Daher bauen und deployen wir prinzipiell nach jedem Code-Push ausgehend von Git unsere Apps (und lassen die automatisierten Tests laufen). Klassisches CI/CD, so weit.
Allerdings nützt es insbesondere für iOS-Apps nichts, wenn die Build-Artefakte in Form von .ipa-Dateien irgendwo landen, wo man sie sich manuell herunterladen kann, denn installieren kann man so eine bloße Datei nach ihrem Download nicht. Was nicht nur für Entwickler:innen nervig ist, sondern auch für fachliche Teammitglieder, die die Apps vor Releases häufig auf Kundenseite testen.
Offenbar sind wir mit der Vorgehensweise nicht alleine auf der Welt. Denn vor vielen Jahren gab es eine deutsche Firma, die ein Produkt namens HockeyApp gebaut hat, was später von Microsoft gekauft wurde und die Basis für Microsoft AppCenter geworden ist. Leider wird AppCenter nach längerer Ankündigung zum 31. März 2025 abgeschaltet.
AppCenter konnte noch mehr, etwa in Sachen Builds und Testautomatisierung. All das lässt sich relativ einfach anderweitig lösen, etwa über eigene Build-Maschinen, die man hinter GitHub Actions klemmt.
Keine Alternative ist jedoch die interne Distribution via Google Play und erst recht nicht über Apple TestFlight. Denn TestFlight erfordert stets einen offiziellen Review-Prozess mit dem Risiko der Ablehnung oder mindestens der Verzögerung. Es ist gut, um neue Versionen einer App semi-öffentlich zu testen, bspw. mit einer Gruppe von ausgewählten Kunden. Aber es ist relativ unbrauchbar, um frei von allen Zwängen täglich dutzende neue Builds mit verschiedensten Änderungen zu deployen.
Ich habe hierfür letztes Jahr in einem Kundenprojekt binnen weniger Tage eine schnelle Lösung zusammengehackt, die seitdem zuverlässig ihren Dienst tut. Seitdem kamen einige Leute auf mich zu und fragten, ob sie das nicht auch haben könnten. Bisher nicht, aber – wenn das hier aufgeht – bald :-).
AppDeploy wird ein kleines Side-Projekt von mir. Das Ziel ist es, in den nächsten Wochen eine funktionsfähige Lösung zum internen Deployment von iOS- und Android-Apps zu bauen, welche in einen beliebigen CI/CD-Prozess eingebunden und dafür genutzt werden kann, die Builds intern bereitzustellen.
Ich werde die Entwicklung hier Schritt für Schritt dokumentieren, also "build in public" betreiben. Die Anfänge werden sicherlich eher technisch, und hinten raus wird es dann vermutlich mehr um Marketing und andere Themen gehen. Darüber hinaus habe ich keine Ahnung, wo das enden wird ...