Sergiusz Woźnicki ist ein Senior Software Entwickler bei Objectivity
Teilen
Inhaltsverzeichnis
Mendix Native Mobile App Erstellen / Bereitstellen der Automatisierung mit OTA und Azure DevOps
Das Aktualisieren der nativen Mendix-App auf Mobilgeräten kann vereinfacht und automatisiert werden. Eine neue Version kann automatisch und ohne manuellen Aufwand in ca. 10-15 Minuten nach jedem Commit ausgelöst werden.
Das Problem
Mendix eignet sich hervorragend für die Entwicklung mobiler Anwendungen. Entwickler, die keine Erfahrung mit nativen Plattformen oder Sprachen haben, können schnell mobile Apps erstellen. Dabei wird derselbe Ansatz verwendet, den sie aus der Welt des Web kennen: Ziehen und Ablegen von UI-Steuerelementen auf Seiten, Definieren von Datenentitäten mit Domänenmodell und Logik mit Microflows und Nanoflows. All dies sind Standardkonzepte von Mendix und der Entwicklungsprozess ist in seiner Hauptphase - der Implementierungsphase - derselbe.
Was sich jedoch unterscheidet, ist die nächste Phase: Bereitstellung der App für die Benutzer. Um dies zu erreichen, müssen Sie die App erstellen und in der Produktivumgebung bereitstellen.
Bei einer Webanwendung handelt es sich bei dieser Umgebung um einen Webserver, und dieser Vorgang ist vollständig automatisiert: Sie drücken in Ihrem Mendix Studio Pro die Taste F5, und nach einer Weile wird die neue Version Ihrer App entweder lokal oder in der Cloud ausgeführt. Dies geschieht lokal dutzende Male pro Tag in kurzen Zyklen Ihrer Entwicklertests während der Implementierung. In der Cloud passiert dies seltener, aber dann häufig in längeren Zyklen, nachdem Sie die Implementierung abgeschlossen und die Funktionalität an das QA-Team übergeben haben oder nachdem Sie mit der Fehlerbehebung fertig sind. Es gibt noch längere Bereitstellungszyklen, die mit der Freigabe der Änderungen für ein breiteres Publikum verbunden sind, z.B. ausgewählte Benutzer für Benutzerakzeptanztests und schließlich für alle Endbenutzer. Sie unterscheiden sich jedoch hauptsächlich im Formalisierungsgrad. Die Art des Prozesses bleibt gleich.
Im Fall einer mobilen App ist die gewünschte Produktivumgebung ein mobiles Gerät, genauer gesagt mehrere mobile Geräte. Ihr Test-Smartphone sollte für die kurzen Zyklen ausreichen. Für längere Zyklen sind möglicherweise auch andere Testgeräte erforderlich, die Ihrem QS-Team zur Verfügung stehen. Sie beginnen mit dem Erstellungsprozess, der installierbare Dateien erzeugt: .apk für Android und .ipa für iOS. Die Dateien können signiert werden (optional für Android und obligatorisch für iOS) und müssen dann auf die Zielgeräte übertragen und installiert werden. Die App Stores fungieren als Vertriebskanal für die eventuellen Veröffentlichungen. Dieser Schritt fügt dem Prozess eine weitere Komplikationsstufe hinzu. Hoffentlich werden die App Stores für die interne Verteilung weggelassen, wenn gängige Dateiübertragungsmethoden (wie USB oder E-Mail) akzeptabel sind. Dies ist normalerweise sowohl bei kürzeren als auch bei längeren Zyklen der Fall. Der gesamte Prozess ist jedoch immer noch viel zu langsam, schwer und umständlich für eine regelmäßige Entwicklungsroutine in beiden Zyklen.
Die Möglichkeiten
Einige Lösungen können die Auflösung dieses Problems erleichtern, aber jede hat ihre Grenzen.
- Für kurze Zyklen mit lokalen Läufen können Sie Make It Native verwenden. Es handelt sich um einen App-Runner, der nur einmal auf Ihrem Testgerät installiert werden muss. Anschließend wird Ihre App jedes Mal neu geladen, wenn Sie F5 drücken. Es ist ein großartiges Tool und verkürzt den Zyklus erheblich. Es wird jedoch eine andere Umgebung eingeführt, und Ihre App verhält sich möglicherweise etwas anders als bei direkter Ausführung. Einige wichtige Funktionen (z.B. Remote-Push-Benachrichtigungen) werden von Make It Native nicht unterstützt. Es wird empfohlen, die endgültigen Tests immer mit Ihrer echten App auf dem Zielgerät durchzuführen.
- Wenn Sie eine hybride Mobile-App erstellen, wird der Prozess mithilfe von Adobe PhoneGap Build teilweise automatisiert und kann direkt von Ihrem Mendix Developer Portal ausgeführt werden. Dies ist jedoch eine ältere Technologie und Mendix rät davon ab diese zu verwenden: „Leider unterhält Adobe diesen Dienst nicht mehr. (…) Da PhoneGap iOS-Builds 13 und höher nicht mehr unterstützt, empfehlen wir stattdessen native iOS-Apps zu erstellen. “ Es ist eine Sackgasse in der Mendix-Welt. Sie kündigten an, dass es in Mendix 9 nicht möglich sein wird, neue Hybrid-Apps zu erstellen, und dass die Unterstützung der alten Apps in den kommenden Versionen eingestellt wird.
- Die Standardmethode zum Erstellen nativer Mendix-Apps verwendet das Native Builder- Command-Tool. Dies betrifft wiederum MxBuild- und Remote-GitHub- und App Center-Dienste. Dies vereinfacht teilweise das gemeinsame Verbinden, Konfigurieren und Ausführen. Es ist vereinfacht, aber nicht auf dem Niveau, was man von einer Low-Code-Lösung erwarten würde. Es ist weitaus komplizierter als nur die F5-Taste zu drücken. Die GitHub- und App Center-Konten müssen erstellt und verwaltet werden. Das Tool verfügt über einige Unterbefehle und mehrere Optionen, einschließlich Authentifizierungstoken für die Remotedienste. lokale Pfade zu ausführbaren Dateien von Java und Mendix sowie zu Ihrem Projektverzeichnis; Namen und Kennungen Ihres Projekts, Ihrer App und Ihrer Organisation; Build-Nummer und App-Version. Es ist leicht, sich in all dem zu verlieren und Fehler zu machen. Es wäre einfacher, wenn Sie den Entwicklern diese lästige Aufgabe nehmen und sie zentral oder automatisiert ausführen könnten.
- Mendix verspricht, den Prozess auf das Niveau zu vereinfachen, welches wir von den hybriden mobilen Apps kennen. Es wurde für Mendix 9 angekündigt, damit wir auf eine glänzende Zukunft hoffen können. Es wird jedoch immer noch keine automatisierte Lösung sein. Es wird auch kein Ein-Klick-Erlebnis sein, sondern eine assistentenähnliche Benutzeroberfläche mit wenigen Schritten. Gleichzeitig erfordert der Verteilungs- / Übertragungsschritt noch eine zusätzliche Lösung.
- In Mendix 9 gibt es ein ähnliches Versprechen für die Unterstützung von PWA-Apps. Mit PWA ist der gesamte Build / Distribute-Aspekt weg, und Sie kehren in die gute alte Webwelt zurück. PWA ersetzt jedoch keine nativen Apps. Jeder dieser beiden Ansätze hat seine eigenen Vorteile und die Auswahl des optimalen Ansatzes hängt häufig von den Besonderheiten des Projekts ab.
Die Lösung: OTA
Die Lösung kommt in Form von OTA: Over The Air-Updates. Kurz gesagt, es ist eine schnelle und schmerzlose Möglichkeit, vorhandene mobile Installationen zu aktualisieren. "Bestehende Installationen" bezeichnet alle Geräte, auf denen Ihre Anwendung normal installiert ist. Sie müssen also immer noch den gesamten Prozess des Build-Sign-Distribute durchlaufen, aber Sie müssen ihn nur einmal ausführen. Wenn Sie dann eine Änderung veröffentlichen möchten, führen Sie eine Light-Version des Native Builder-Befehls aus, und nach einigen Minuten wird das Update veröffentlicht. Alle Ihre Kunden erhalten es automatisch. Wenn ein Endbenutzer Ihre App ausführt, wird eine Popup-Meldung angezeigt, dass ein neues Update vorliegt, mit der zusätzlichen Beschreibung, die Sie bereitstellen können. Sie können das Update als obligatorisch oder optional festlegen. Im letzteren Fall entscheidet der Benutzer, ob er es anwendet. Auf jeden Fall dauert es Sekunden, bis das Update abgeschlossen ist.
Das Feature basiert auf CodePush und dem App Center-Dienst, der als zentrales Repository fungiert, in dem Ihre Updates veröffentlicht werden. Alle im App Center erstellten React Native-Apps - Dies ist bei nativen Mendix-Apps der Fall. Sie können den Dienst einfach aufrufen, um beim Start nach Updates zu fragen.
In den meisten Fällen müssen Sie den serverseitigen Teil in Mendix Cloud nicht einmal erneut bereitstellen. OTA allein reicht aus, um Änderungen an mobilen Seiten, Layouts, Steuerelementen, Widgets, Nanoflows, JavaScript-Aktionen und sogar zerstörungsfreien Änderungen des Domänenmodells von Seitens des Kunden vorzunehmen. Wenn sich Dinge wie Microflows ändern, stellen Sie diese Seite der Anwendung zusätzlich auf die übliche Weise mit der Taste „F5“ erneut bereit. Es gibt einige Randbedingungen, in denen ein vollständiger Release-Prozess erforderlich ist, die Liste ist jedoch kurz:
- Die Erstfreigabe ist zu Beginn erforderlich.
- Das Hinzufügen eines neuen nativen Moduls oder das Ändern eines Splash-Screens kann ein- oder zweimal erfolgen.
- Die anderen Situationen sind selten oder eher unwahrscheinlich: App umbenennen; Upgrade der Mendix-Version (jedoch nur, wenn eine neue native Vorlagenversion erforderlich ist); Grundlegende Änderung der Funktionalität (eine Einschränkung im App Store: Apple möchte sie dann erneut überprüfen).
Verbesserung: OTA mit Automatisierung
Was den OTA noch interessanter macht ist, dass man ihn ganz einfach automatisieren kann. Am Ende ist es nur ein einziger Befehl. Es sind keine manuellen Arbeiten wie das Übertragen von Dateien auf physischen Geräten erforderlich. Sie können den OTA-Befehl automatisch für ein bestimmtes Ereignis aufrufen, z. B. bei jedem Commit für den Team Server.
Bei Objectivity haben wir genau für diesen Zweck eine Lösung entwickelt. Wir haben eine CI / CD-Automatisierung erstellt, die direkt nach jedem Commit ein neues OTA-Update veröffentlicht. Es kann bedingt sein, z. B. wenn die Nachricht ein bestimmtes Tag enthält. Es dauert nur etwa 10 bis 15 Minuten und geschieht vollkommen „im Hintergrund“, ohne dass manuelle Hilfe erforderlich ist. Dies ist ein erheblicher Vorteil, wenn Sie es mit der Komplexität und Schwere des traditionellen Ansatzes vergleichen, bei dem Entwickler für jeden einzelnen Build etwa eine halbe Stunde aufwenden müssen. Dies muss mit der Anzahl der Builds multipliziert werden, die in Ihrem Tagesablauf benötigt werden, um die App für das QA-Team oder andere Teammitglieder und Rollen verfügbar zu machen. Darüber hinaus müssen Sie die Zeit hinzufügen, die für die Verwaltung der längeren Zyklen der Freigabe nachfolgender Versionen der Anwendung aufgewendet wird (Sie können die bedingten Aktualisierungen für diesen Fall verwenden). Es macht einen großen Unterschied und spart viel sich wiederholende, umständliche und zeitaufwändige Arbeit.
Die Automatisierung basiert auf Azure DevOps. Wir haben eine Pipeline, die mit unserem App-Code-Repository unter SVN verknüpft ist (Mendix Team Server basiert auf Subversion). Eine einzelne Aufgabe, die den Native Builder-Befehl ausführt ist definiert. Es könnte direkt ausgeführt werden (mit Befehlszeileneingabe) - wir verwenden jedoch ein kleines Batch-Skript (ota.bat).
Die Parameter werden als Pipeline-Variablen beibehalten:
Beispielsweise wird die Variable ota_desc verwendet, um den Beschreibungstext zu aktualisieren. In unserem Fall setzen wir den Wert auf:
"SVN: $(Build.SourceBranch)/$(Build.SourceVersion); DevOps run #$(Build.BuildId); AppCenter build/$(build_number); App ver $(app_version)"
Das Skript ota.bat führt lediglich diesen einzelnen Befehlsaufruf um, um die Parameterschnittstelle leicht zu vereinfachen:
set native_builder_path=native-builder.exe
set mxbuild_path=mx/modeler/mxbuild.exe
set java_home=jdk
:: the rest is passed as args:
set appcenter_organization=%1
set appcenter_api_token=%2
:: ...and a few more...
set cmd=call %native_builder_path% release push-update --verbose ^
--rollout-percentage 100 --skip-mxbuild false --mandatory false ^
--java-home %java_home% ^
--mxbuild-path %mxbuild_path% ^
--appcenter-organization %appcenter_organization% ^
--appcenter-api-token %appcenter_api_token% ^
--project-path %project_path% ^
--project-name %project_name% ^
--build-number %build_number% ^
--target-version %app_version% ^
--description %DESC%
echo Calling the release push-update command:
%cmd%
Es gibt drei Abhängigkeiten:
- Native Builder selbst und seine Abhängigkeiten:
- MxBuild-Tool von Mendix (--mxbuild-path param)
- Java JDK-Verzeichnis (--java-home param).
Der Einfachheit halber wurden diese Abhängigkeiten so trivial wie möglich gelöst, indem sie direkt zu unserer Quelle in SVN (unter dem Ressourcenordner) hinzugefügt wurden. Ein ausgefeilterer und effizienterer Weg ist möglich und es würde das Hinzufügen eines weiteren selbst gehosteten DevOps-Agenten auf Virtual-Machine erforderlich sein, der sich der Aufrechterhaltung der Abhängigkeiten widmet.
Die Pipeline ist normalerweise in 10-15 Minuten fertig. Wie Sie auf dem Bildschirm unten sehen können, wird mehr als die Hälfte dieser Zeit für das SVN-Auschecken aufgewendet. Dieser Teil kann erheblich reduziert werden, indem die Abhängigkeiten von unserem Projekt zu einer externen Virtual-Machine wie oben beschrieben entfernt werden.
Zusammenfassung
Unsere Lösung automatisiert CI / CD-Prozesse für mobile Anwendungen. Es funktioniert gut und leicht. In ca. 10-15 Minuten nach jedem Commit wird automatisch eine neue OTA-Version ohne manuellen Aufwand ausgelöst. Die Updates werden reibungslos von jedem einzelnen Entwickler an das gesamte Team verteilt. Auf diese Weise können QA-Tester und andere Rollen, die Zugriff auf die Änderungen haben sollten, den Arbeitsfortschritt kontinuierlich überwachen. Es kann auch in längeren Zyklen für die offiziellen Versionen und nachfolgender Versionen der Anwendung verwendet werden. Die Vorteile sind im Vergleich zum gesamten Prozess der manuellen Bearbeitung enorm.
Dieser Artikel wurde von Objectivity ins Deutsche übersetzt.
Sergiusz Woźnicki ist ein Senior Software Entwickler bei Objectivity
