Best Practices für die Entwicklung mobiler Unternehmens-Apps

Seite 5: Exkurs

Inhaltsverzeichnis

Zentrale Komponenten der Continuous Integration
bei der compeople AG sind:

  • ein gemeinsames Versionsverwaltungssystem auf Basis von Git, das die Entwickler zur Verwahrung von Code, Grafiken und sonstigen multimedialen Inhalten verwenden.
  • eine Instanz des Continuous-Integration-Servers Jenkins (ehemals Hudson), der auf einem separaten Build-Rechner (intern als "Tankstelle" bezeichnet) regelmäßig auf Änderungen im Versionsverwaltungssystem prüft, gegebenenfalls Änderungen auscheckt, das Gesamtsystem neu baut und das Ergebnis (in dem Fall eine signierte IPA-Datei) archiviert. Kunden, Qualitätssicherer oder anderweitig interessierte Mitarbeiter schließen dann einfach ihr iPhone oder iPad an die Tankstelle an und installieren per iPhone-Konfigurationsprogramm den aktuellen Stand der App auf ihr Gerät.
  • TestFlight zur Auslieferung der Builds auf die Endgeräte der Tester, zur Überwachung des Testverhaltens, zum Einholen von Feedback und zur Protokollierung etwaiger Crashes.
möglich

Aber nicht immer können alle Projektverantwortlichen den aktuellen Build von der Tankstelle beziehen. In dem Fall erfolgt bei compeople die Auslieferung der Builds zusätzlich über den kostenlosen Webdienst TestFlight. Er protokolliert neben dem Deployment der Builds bei den Testern deren Testverhalten und Feedback. Auch das unbeliebte Einsammeln der für das Code Signing notwendigen Unique Device Identifiers (UDIDs) der Testgeräte unterstützt der Dienst automatisiert. Der Einsatz von TestFlight ist ausgesprochen einfach: Nach Aufsetzen eines iOS-Projekts auf der Webseite durch einen Entwickler lassen sich die relevanten Testpersonen einladen und in Gruppen organisieren. Entwickler können dann ihre Builds in TestFlight hochladen (entweder manuell oder als Teil des Build-Prozesses in Jenkins) und bestimmen, welche Testgruppen mit dem neuen Build versorgt werden sollen. Die so bestimmten Testpersonen bekommen daraufhin eine E-Mail, die einen Link zur automatischen Installation des Builds enthält.

Entwickler können sich jederzeit informieren, welcher Tester welchen Build zurzeit installiert und wie ausführlich er diesen getestet hat sowie auf welche Probleme er bei der Bedienung gestoßen ist. Benutzt der Build das kostenfreie TestFlight SDK, lassen sich zusätzlich und mit geringem Entwicklungsaufwand detaillierte Informationen wie Checkpoints (wichtig zur Ermittlung der Test Coverage), Crash Logs oder Feedback der Tester automatisch einsammeln und durch die Entwickler jederzeit einsehen. Die Veröffentlichung eines Builds per TestFlight als integraler Bestandteil des automatisierten Build-Prozesses ist durch TestFlights Upload API mit Jenkins verhältnismäßig einfach zu realisieren. (ane)