Nach der Entwicklung einer Applikation muss diese auf dem Rechnersystem des Kunden bereitgestellt werden. Das kann über ein klassisches Installationsprogramm oder über den Anwendungsstore des Betriebssystems geschehen. Delphi bietet Unterstützung für eine Vielzahl von Möglichkeiten des Deployments – Ein Überblick.
Ist eine Anwendung erfolgreich implementiert, gilt es diese für die Nutzer bereitzustellen. Die Phase der Auslieferung eines Anwendungssystems wird auch als Softwaredeployment bezeichnet und gliedert sich gemäß Bild 1 in den Softwarelebenszyklus ein.
Bild 1: Die Phase des Softwaredeployments ist Bestandteil des Softwarelebenszyklus.
Nach der Implementierung und umfangreichen Tests, gilt es die neue Version möglichst zeitnah und unkompliziert den Nutzern zur Verfügung zu stellen. Dabei gibt es kein allgemeingültiges Vorgehen. Die konkrete Vorgehensweise ist sowohl von der Art der Anwendung als auch vom Zielsystem abhängig. Die Bereitstellung einer Unternehmensapplikation auf einer Vielzahl von Desktop-Rechnern erfolgt grundsätzlich anders als man eine App für den Einsatz auf mobilen Geräten für private Nutzer verteilt. Trotz dieser Unterschiede können einige allgemeine Anforderungen an ein zeitgemäßes Softwaredeployment ausgemacht werden:
- Möglichst weitgehende Automatisierung: Moderne Software wird heute schrittweise und sehr oft nach agilen Vorgehensmustern entwickelt. Statt eines einmaligen Abarbeitens eines umfangreichen Entwicklungszyklus, wird dieser wiederholend, in kleinteiliger Art und Weise in kurzen Zeitabständen durchlaufen. Für den Nutzer ergibt sich daraus die Notwendigkeit die Software in kürzeren Zeitabständen zu aktualisieren. Der Gesamtprozess des Deployments sollte daher so weit wie möglich automatisiert werden.
- Vollständige Installationspakete: Die erstellte Anwendung ist i.d.R. Bestandteil eines umfassenderen Anwendungssystems. Oft müssen auch weitere Dateien, Dokumente usw. im Zuge der Verteilung auf das Zielsystem installiert werden.
- Nahtlose Integration in den Entwicklungsprozess: Idealerweise kann das Softwaredeployment direkt aus dem Entwicklungssystem angestoßen werden. Dadurch werden Systembrüche und der Einsatz zusätzlicher Tools vermieden bzw. minimiert.
Weitere spezifische Anforderungen ergeben sich aus der Art der Software und dem Zielsystem. Sollen Apps beispielsweise über einen Store des Betriebssystems bereitgestellt werden, dann sind die Vorgaben und Bedingungen für den App-Store zwingend zu beachten.
Die konsequente Umsetzung einer automatisierten Bereitstellung von Software in der Zielumgebung führt zu einer so genannten Continuous Deployment Pipeline. Diese ist das Ergebnis und das Ziel einer möglichst weitgehenden Automatisierung und Integration der einzelnen Schritte des Softwareentwicklungsprozesses (Bild 2).
Betrachten wir diese Pipeline. Diese startet mit dem Wünschen (Anforderungen) an die zu entwickelnde Software. Es folgen die Codierung (Implementierung) und das Build der Applikation. Ein regelmäßiges und sofortiges Testen der Applikation wird in einem agilen Entwicklungszyklus eingebettet. Kommen wir zum Begriff Continuous Integration (CI). CI umfasst den Automatisierungsprozess für Entwickler. Bei einer erfolgreichen CI werden regelmäßig neue Quellcodeänderungen für Apps entwickelt, geprüft und in einem gemeinsamen Repository zusammengeführt. Damit soll beispielsweise der Konflikt verhindert werden, den zu viele Branches einer App verursachen können, wenn sie zeitgleich entwickelt werden. Nach dem Testen einer Version wird eine Release-Version erstellt. Diese ist in Bezug auf die Nutzung in der Produktionsumgebung optimiert und damit die Basis für die Bereitstellung. Das Release-Build steht damit im Gegensatz zum Debug-Build. Continuous Delivery (CD) geht einen Schritt weiter als Continuous Integration. Es kommt das Packaging der Anwendung zum Release hinzu. Die Idee: Jedes Commit löst einen Workflow – den Build – aus, welcher die Codebasis generiert, testet und das Paket erstellt, das dann ausgeliefert wird. Damit könnte theoretisch jedes Commit jederzeit bereitgestellt werden.
Wird diese Pipeline noch um den Schritt der tatsächlichen Bereitstellung (Deployment) erweitert, dann sprechen wir vom Continuous Deployment. Das Ziel besteht in einer möglichst unmittelbaren Bereitstellung der stabilen Builds (Release-Versionen) in die Produktionsumgebung. Auf diese Weise steht jede neue und endgültige Funktion allen Endbenutzern auf dem schnellstmöglichen Weg zur Verfügung. Diese Vorgehensweise beschleunigt die Bereitstellung von neuen Funktionen und steigert das Business Value. Eine umfassende Qualitätssicherung ist eine wichtige Voraussetzung dafür, dass man eine neue Version direkt ausliefern kann.
Bereitstellung mit RAD Studio
Mit RAD Studio erstellen Sie Anwendungen für alle gängigen Front-End Geräte und Betriebssysteme. Dank der Technologie von FireMonkey sind es Applikationen für die folgenden Systemumgebungen:
- Windows
- macOS
- Linux
- Android
- iOS
Alle Applikationstypen können aus einer gemeinsamen Quellcodebasis generiert werden. Die Bereitstellung erfordert jedoch ein differenziertes Vorgehen – je nach Plattform. Dabei kann in Anlehnung an die oben beschriebene Deployment-Pipeline nach den folgenden drei Schritten vorgegangen werden:
- Erstellen des finalen Builds nach umfangreichen Tests auf der Zielplattform.
- Definition der Dateien für die Bereitstellung nach Plattform und Build-Konfiguration.
- Bereitstellen der Dateien direkt aus der Entwicklungsumgebung RAD Studio.
Mit Hilfe des so genannten Plattform-Assistenten kann man für jedes Projekt ermitteln, welche Dateien auf der Basis der Zielplattform und der Build-Konfiguration bereitgestellt werden sollen. Zusätzliche Dateien (Ressourcen), wie Bilder, Töne, Videos usw. können über wenige Mausklicks in die Bereitstellungskonfiguration aufgenommen werden. Sie werden dann ebenfalls auf das Zielsystem an den angegebenen Ort kopiert.
Je nach Zielsystem kann ein Anwendungs-Package für die Übermittlung an den jeweiligen App-Store generiert werden oder es erfolgt eine Bereitstellung mit Hilfe des Platform Assistant Servers (PA Server). Anwendungs-Package müssen an die Stores der Betriebssysteme übermittelt werden. Dabei handelt es sich um eine einzelne Datei, welche das Programm und alle zusätzlichen Ressourcen beinhaltet. Je nach Anwendungsstore sind einige zusätzliche Angaben zur übermittelten App notwendig.
Der Einsatz des PA-Servers ermöglicht dagegen eine automatisierte Bereitstellung der Applikation auf den Zielgeräten. Der PA Server verbindet die für die Bereitstellung definierten Dateien zum Paket einer Anwendungsinstanz. Aus RAD Studio wird das Anwendungspaket auf den ausgewählten Remotecomputer übertragen und installiert.
Bereitstellung für Microsoft Windows
Für Windows Applikationen gibt es mehrere Optionen der Bereitstellung. Für einfache Anwendungen, ohne externe Abhängigkeiten, ohne Datenbankinstallation und ohne die Nutzung von weiteren Ressourcen kann man die Anwendungsdatei einfach kopieren (xcopy-Installation). Sind zusätzliche Dateien an ausgewählten Orten auf dem Zielsystem zu installieren, Konfigurationseinstellungen vorzunehmen usw., dann bietet sich der Einsatz eines Installationsprogramms an. Beide Varianten der Anwendungsbereitstellung sind etabliert und für viele Anwendungsfälle auch das passende Vorgehen. Unter Windows 10 kommt eine weitere Option hinzu. Die Nutzung des Microsoft Store. Diese Möglichkeit der App-Distribution ist bisher ausschließlich den so genannten Apps für die Universelle Windows Platform (UWP) vorbehalten. Man kann jedoch auch klassische Applikationen für den Desktop verpacken, signieren und dann im Store zur Distribution anmelden. Microsoft bietet dazu das Tool Desktop Bridge an. Um dieses Tool zu verwenden, sind einige Schritte der Konfiguration notwendig.
Aus RAD Studio ist es möglich direkt das Anwendungs-Package für die Bereitstellung einer Windows 10-Applikation zu erstellen. Dazu aktiviert man im Projekt-Manager zunächst als Zielplattform Windows 32 Bit bzw. Windows 64 Bit (Bild 3).
Bild 3: Auswahl der Zielplattform – Hier Microsoft Store Windows 10.
Unterhalb des Knotens Konfiguration ist der Eintrag Anwendungs-Store durch Doppelklick auszuwählen. Erfolgt die Bereitstellung einer Windows Desktop Applikation über den Microsoft Store ist analog zu Apps für die UWP eine bestimmte Version des Software Development Kits (SDK) zuzuweisen. Das erledigt man über das Kontextmenü des Eintrags Anwendungs-Store im Projektmanager (Bild 4).
Bild 4: Zuweisung eines SDK für die Bereitstellung über den Store.
Ebenso benötigen diese Anwendungen ein so genanntes Manifest mit bestimmten Basiseinstellungen. Dieses kann automatisch generiert werden oder man ordnet eine Manifest-Datei manuell zu. Die dafür notwendigen Einstellungen sind wahrscheinlich schon korrekt und können in den Projektoptionen eingesehen bzw. angepasst werden (Bild 5).
Bild 5: Manifest-Datei für Anwendungsbereitstellung.
Die konkreten Konfigurationsangaben für die Bereitstellung über den Store erfolgen über den Eintrag Provisioning – ebenfalls in den Projektoptionen. Für die ausgewählte Konfiguration, d.h. meist eine Release-Konfiguration, ist als Build-Typ der Eintrag Anwendungs-Store auszuwählen. Als Distributionstyp kann zwischen folgenden Optionen unterschieden werden (Bild 6):
- Ad-hoc: Es wird ein signiertes Package erstellt, welches manuell auf einem Zielsystem, durch so genanntes Querladen, installiert werden kann.
- Store: Das generierte Package ist dafür vorgesehen, dass man es in den Store hochladen kann. Dieses Package wird nicht manuell signiert. Das erfolgt automatisch, wenn das Package in den Store hochgeladen wurde im Rahmen des Prüfungs- und Freigabeprozesses durch Microsoft.
Bild 6: Provisioning für das Deployment über den Store.
Beim Distributionstyp Ad-hoc ist es notwendig das Package manuell mit einer Signatur zu versehen. Sofern man über eine solche Signatur verfügt, kann die zugehörige Datei hier ausgewählt werden. Ebenso ist es möglich für die eigene Verwendung ein so genanntes Selbstsigniertes Zertifikat zu verwenden. Ein solches kann man direkt über das Dialogfeld erstellen.
Bild 7: Zuweisen eines Zertifikates.
Hierzu ist die Auswahl eines Dateinamens und die Vergabe eines Passwortes notwendig. Ist das Zertifikat korrekt zugeordnet, dann kann das Projekt neu erstellt werden. Dabei wird das App-Package generiert. Über ein Dialogfeld wird der Erfolg des Vorgangs angezeigt (Bild 8).
Bild 8: Erfolgreich erstelltes Anwendungs-Package.
Das generierte Anwendungs-Package wird als *.appx-Datei unterhalb des bin-Ordners im Projektverzeichnis gespeichert (Bild 9).
Bild 9: Generiertes Package (appx-Datei).
Also Store-Distribution ist seit RAD Studio 10.4.2 auch die MSIX Erstellung möglich. Siehe dazu http://docwiki.embarcadero.com/RADStudio/Sydney/en/Windows_MSIX_Support
Dieses App-Package kann für eine lokale Installation – Querladen – verwendet werden. Dazu muss das generierte, selbstsignierte Zertifikat auf dem Rechner als vertrauenswürdig eingestuft werden. Man wählt dazu die Datei mit dem Zertifikat im Explorer aus und ruft die Installation über das Kontextmenü auf. Das Zertifikat wird in den Zertifikatsspeicher installiert (Bild 10).
Bild 10: Import des Zertifikates.
Ausgewählt wird der Speicherort Nichtvertrauenswürdige Zertifikate. Nach dem Import des Zertifikates kann die Anwendung über das Package installiert werden, d.h. es wird jetzt auf diese Weise installiert, wie es auch für Apps der UWP möglich ist (Bild 11).
Bild 11: Installation der Anwendung mittels Package (Querladen).
Distribution für weitere Plattformen
Die vorherigen Textabschnitte haben die Distribution einer Anwendung für Windows 10 gezeigt. Dabei lag der Fokus auf die Bereitstellung über den Anwendungs-Store. Auch für die Betriebssysteme macOS, iOS und Android gibt es Anwendungsstores zur direkten Distribution der Apps. Auch für diese Systeme können die Anwendungs-Packages direkt aus der Entwicklungsumgebung generiert werden. Die Vorgehensweise ist ähnlich, wie es für das Betriebssystem Windows 10 gezeigt wurde.
Nutzung des Bereitstellungsmanagers
Ein zentraler Ort zur Verwaltung und Durchführung aller Aufgaben im Zusammenhang mit der Bereitstellung der Software, welche mit RAD Studio erstellt wurde, ist der Bereitstellungsmanager (Bild 12).
Bild 12: Bereitstellungsmanager in RAD Studio.
Dieser wird über das Anwendungsmenü Projekt | Bereitstellung aufgerufen. Hier können je nach Zielsystem die individuellen Einstellungen für das spezifische Deployment zusammengestellt werden. Ebenso können weitere Dateien für das Zielsystem hinzugefügt werden und der Bereitstellungsprozess kann über den Platform Assistant Server gesteuert werden.
Zusammenfassung und Ausblick
Die Anwendungsbereitstellung ist der finale Schritt bei der Entwicklung von Software. Sie sorgt dafür, dass die Applikation auf den Zielgeräten der Anwender installiert wird. Unterschiedliche Geräte (Desktop, Mobil) und Zielsysteme (Windows, macOS, Linux, iOS, Android) erfordern ein differenziertes Vorgehen. Mit RAD Studio sind Entwickler auf einfache Weise in der Lage diese Anforderungen zu erfüllen. Es ist sowohl möglich die Anwendungs-Packages für das Einstellen der App in die Stores als auch eine automatisierte Remote-Bereitstellung zu konfigurieren. In beiden Fällen erfolgt die Bereitstellung direkt aus der integrierten Entwicklungsumgebung.
Links
[1] https://www.embarcadero.com/de/products/delphi/features/deploy
[2] http://docwiki.embarcadero.com/RADStudio/Sydney/en/Deploying_Applications_Overview
[3] http://docwiki.embarcadero.com/RADStudio/Sydney/en/Deployment_Manager
[4] https://blogs.embarcadero.com/learn-how-to-deploy-your-delphi-applications-to-the-microsoft- store/
[5] https://blogs.embarcadero.com/deploying-windows-10-apps-through-the-microsoft-store- 1863306656/