Continuous Deployment in der mobilen App-Entwicklung

Der Einsatz von Continuous Integration (CI) und Continuous Delivery (CD) ist in den letzten Jahren zu einem selbstverständlichen Bestandteil der Entwicklung webbasierter Anwendungen geworden. Unternehmen können bei Bedarf mehrmals täglich neue App-Versionen oder Bugfixes in die Produktivumgebung einspielen. Mithilfe von Web-Deployment-Tools und einer soliden Deployment-Infrastruktur lässt sich dieser Vorgang inzwischen wesentlich einfacher und zuverlässiger gestalten. Aber gilt das auch für Native Apps? Ist es angesichts der Review-Prozesse einiger App Stores überhaupt möglich, Apps rechtzeitig zu veröffentlichen?

Beide Fragen lassen sich mit Ja beantworten. Im folgenden Artikel gehe ich näher auf die Optionen ein, die sich bei nativen Apps bieten.

In die mobile Infrastruktur investieren

Continuous Integration und Continuous Delivery sind nicht umsonst – weder für Web-Applikationen noch für native Apps. Unternehmen müssen Zeit und Geld in ihre mobile Infrastruktur investieren, um „on demand“ neue Versionen ihrer nativen Apps bereitstellen zu können. Dank der heute verfügbaren Software und Tools ist das recht einfach zu realisieren.

Eine schlanke und leistungsstarke Basis für die Infrastruktur kann beispielsweise durch Open-Source-Software wie Jenkins (als Continuous-Integration-System) und fastlane (als Build-and-Sign-Software) geschaffen werden. Anschließend kann über einen Dienst wie Testflight, AppCenter oder Firebase problemlos ein Kanal zur App-Verteilung eingerichtet werden, um während der Entwicklungs- und Testphase mit Geräten zu testen.

In Automatisierung investieren

Testautomatisierung ist eng mit Continuous Integration und Continuous Delivery verbunden. Wenn eine Build-Pipeline vorhanden ist, besteht der nächste logische Schritt darin, Zeit und Geld in den Aufbau einer Testautomatisierungs-Pipeline zu investieren.

Durch die automatisierten Prüfungen erhält das Team schnelleres Feedback zu Änderungen der Codebasis auf den verschiedenen Ebenen der mobilen App-Architektur. Darüber hinaus kann ein Team neue App-Versionen schnell internen oder externen Tester zur Verfügung stellen und weniger Aufwand für manuelle Tests betreiben.

Je nach mobiler Anwendung können Teams die automatisierten Prüfungen auf verschiedenen Ebenen implementieren. Dabei kann es sich um Unit-Tests, Integrationstests, API-Tests und End-to-End-UI-Tests handeln. Jedes Team muss die richtige Mischung von Tests finden, um eine schnellere Entwicklung zu unterstützen und neue Anwendungsversionen mit mehr Sicherheit zu veröffentlichen.

Bereitstellungsoptionen von App Stores

Sobald die Infrastruktur samt Testautomatisierung steht, muss das Entwicklungsteam sich mit den unterschiedlichen Bereitstellungsoptionen der App Stores von Apple und Google vertraut machen – denn Unterschiede gibt es einige.

Der größte Unterschied betrifft den App-Review-Prozess. Während im Apple App Store jede App vom Apple Review Team genehmigt werden muss, kann eine App im Google Play Store sofort hochgeladen werden und die produktive App innerhalb weniger Stunden ersetzen.

Als nächstes ist zu überlegen, wie native Apps für reale Benutzer oder Tester verfügbar gemacht werden sollen. In beiden App Stores besteht die Möglichkeit einer gestaffelten Veröffentlichung (iOS, Android). Dabei wird die neueste App-Version schrittweise für Teile der Nutzer freigegeben. Auf diese Weise kann das Entwicklungsteam den Release-Fortschritt auf mögliche Probleme überwachen und die Verteilung im Bedarfsfall stoppen. Der Google Play Store bietet darüber hinaus auch Alpha- und Beta-Releaseoptionen.

Die verfügbaren Release- und Testoptionen zu kennen ist entscheidend, um die richtige Art der Bereitstellung wählen zu können. Mit Blick auf die existierenden mobilen Entwicklungs- und Release-Tools und die Bereitstellungsoptionen der App Stores bieten sich zwei Möglichkeiten:

Internes Continuous Deployment

In diesem Fall wird die Bereitstellungssoftware so konfiguriert, dass alle Mitglieder des Teams oder Unternehmens sofort über die neuesten App-Versionen informiert werden, wenn die Tests bestanden wurden und ein neuer App-Build durch die Distributionssoftware bereitgestellt wird. Je nach Unternehmensgröße wird die App von Hunderten oder Tausenden von Kollegen genutzt, die Rückmeldung zum aktuellen Zustand der App geben können und sollen. Dies ist ohne Beteiligung von Apple und Google möglich, so dass das Entwicklungsteam die volle Kontrolle behält.

Externes Continuous Deployment

Mit dieser Option kann dein Team entweder seine eigene Infrastruktur zur Verteilung nutzen oder jene von Apple und Google erweitern. Im ersten Fall müssen entweder die Kunden zur Verteilung des neuen App-Builds in das eigene Verteilsystem eingeladen werden, was sich durch Software wie Testflight, AppCenter oder Firebase vereinfachen lässt, oder man greift auf eine Community von Crowdtestern zurück, deren Endgeräte der Verteilerliste hinzugefügt werden können. Das ist die optimale Methode, da man die Software realen Kunden und Testern zur Verfügung stellen kann, ohne den Zulassungsprozess des App Stores durchlaufen zu müssen.

Für Android-Apps kann die Infrastruktur des Google Play Stores genutzt werden, die sowohl Alpha- als auch Beta-Testkanäle bietet. Über den Alpha-Kanal ist eine Verteilung an bis zu 100 interne oder externe Kunden oder Tester basierend auf deren E-Mail-Adresse möglich. Beim Beta-Kanal gibt es kein Limit bezüglich der Anzahl der Tester. Man kann wählen, ob der Zugang öffentlich ist oder nur auf Einladung erfolgen soll. Sowohl Alpha- als auch Beta-Kanal können für das Continuous Deployment konfiguriert werden. Bei iOS-Apps besteht keine Möglichkeit zur Erstellung von Alpha- oder Beta-Releases. Apple bietet die Option einer gestaffelten Einführung. Dabei werden Updates für iOS-Apps den Kunden schrittweise bereitgestellt und Feedback sowie Informationen zur Nutzung eingeholt.

Ist das externe Deployment und Kundenfeedback zufriedenstellend, kann das mobile Entwicklungsteam das App-Update bei den App Stores einreichen. Das Team kann dann entscheiden, ob eine gestaffelte Einführung stattfinden soll oder nicht.

Welche Art der Bereitstellung ist für dein Unternehmen geeignet?

Das Continuous Deployment von mobilen Apps gibt es nicht zum Nulltarif. Eine allgemeingültige Lösung existiert nicht, denn eine CI/CD-Pipeline inklusive Testautomatisierung ist immer etwas Unternehmensspezifisches und der Aufbau erfordert Zeit und Geld.

Zunächst sollte man prüfen, ob die für die Einführung eines Continuous-Deployment-Prozesses erforderlichen Skills und technischen Möglichkeiten im Team vorhanden sind.

Wenn sowohl das Wissen als auch das technische Umfeld für CI/CD verfügbar sind, muss gemeinsam mit dem Team entschieden werden, welcher der genannten Ansätze am besten passt.

Um die richtige Bereitstellungsmethode zu finden, sollte man sich die folgenden Fragen stellen:

1. Sind die zum Aufbau einer Deployment-Pipeline erforderlichen Fähigkeiten im Unternehmen vorhanden?
2. Gibt es eine bestehende Deployment-Infrastruktur, die weiterverwendet werden kann?
3. Können die internen Systeme mit externen Anbietern verbunden werden?
4. An wen sollen die Alpha- und Beta-Builds verteilt werden?