6 Minuten Lesezeit (1107 Worte)

Software Development Kit (SDK) - Build-Prozess mal anders

Dienstag, 06. März 2018

Wird eine Software vom Kunden eingekauft anstatt diese selbst zu entwickeln, wird sie in vielen Fällen zunächst angepasst, bevor sie in den Betrieb geht. Die Softwarehersteller bieten hierfür meist die Möglichkeit mittels des Software Development Kit (SDK) einen Teil der Software zu personalisieren, um die Anwendung an die Wünsche des Kunden anzupassen. Dieser Artikel erläutert eine Möglichkeit, wie solche Software versioniert, automatisiert, gebaut und deployed werden kann.

Die Situation

Der Kunde möchte durch den Einkauf einer Standardsoftware Zeit und Kosten sparen. Die eingekaufte Software unterstützt die Personalisierung verschiedener Softwareteile mittels des Software Development Kit (SDK). Durch dieses SDK wird es dem Kunden ermöglicht, die eingekaufte Software an die vorhandenen Prozesse des Unternehmens anzupassen.

Bei einem solchen Vorgehen werden zwei Softwarestände zu einem Softwarerelease zusammengeführt. Die zwei Softwareteile lassen sich wie folgt unterscheiden:

Kernsoftwareteile: Software, die vom Softwarehersteller geliefert wird
Personalisierte Softwareteile: Eigene Softwareentwicklung die mittels SDK vorgenommen wurde

Hierbei können Seiteneffekte entstehen, wenn der personalisierte Softwareteil nicht kompatibel mit der Kernsoftware ist. Um dieses Problem frühzeitig identifizieren zu können, werden statt einer eigenen Entwicklungsumgebung mit dem aktuellen Entwicklungsstand, mehrere Versionen der Software für Smoke-Tests zur Verfügung gestellt, um die grundsätzliche Kompatibilität zu überprüfen.

Damit die Bereitstellung der verschiedenen Softwareversionen keinen übermäßigen Aufwand für das Projektteam erfordert, muss der Build-Prozess soweit wie möglich automatisiert werden. Nur so ist es möglich die Bereitstellung der Releases für die Entwicklungsumgebung und gleichzeitig für die Testumgebung zu ermöglichen.

Das nachfolgende Beispiel basiert auf einem aktuellen Kundenszenario. Die Verwendung vereinzelter Komponenten, wie beispielsweise dem Team Foundation Server, kann somit in anderen Projekten variieren.

Ein Repository, zwei Softwareteile

Die Grundlage zur Automatisierung des Build-Prozesses ist eine zentrale Quellcodeverteilung, die in diesem Fall mit Hilfe von Git bewerkstelligt wird. Innerhalb des Git- Repository ist hierbei nur der personalisierte Softwareteil versioniert.

Die Kernsoftware wird nicht im Git gepflegt, da es hierbei meist um vorkompilierte Softwareteile handelt. Stattdessen wird dieser Teil der Software lokal auf einem Netzlaufwerk gespeichert, der im späteren Verlauf des Deployment- Prozesses eine wichtige Rolle spielen wird.

Das Repository besteht im Grunde aus zwei verschiedenen Branches:

Entwicklung
Innerhalb des Entwicklungs-Branch werden die verschiedenen personalisierten Softwareteile entwickelt. Jede Änderung der Software wird innerhalb dieses Branch, bzw. eines Unterzweigs der Entwicklung, vorgenommen.
Release
Wurden genügend Features für ein neues Release ent- wickelt, wird der aktuelle Stand der Entwicklung in den Release-Branch zusammengeführt. Dieser Branch wird somit nur dann aktualisiert, wenn die vorhandene Menge an neuen Funktionen ein neues Release bilden kann.

Build on Commit

Sobald innerhalb des Git-Repository ein neuer Commit im Release Branch entstanden ist, wird automatisch ein neuer Build angestoßen. Dies wird ermöglicht durch die Verwendung des Continuous Integration Plattform Team Foundation Server (TFS).

Der TFS bietet die Möglichkeit verschiedene Build-Regeln zu angeschlossenen Repositories zu definieren. So ist es möglich, bei jedem Commit innerhalb eines bestimmten Branch einen neuen Build anzustoßen oder wiederholend zu einem definierten Zeitpunkt. Diese Funktionalität wird auch Trigger genannt. Konfiguriert wird die gesamte Konfiguration mittels einer Weboberfläche, wie die Abbildung 1 am Beispiel der Continuous-Integration-Einstellung beweist.

Ein solcher Trigger wird innerhalb einer Build-Definition konfiguriert. Diese Build-Definition hält zudem alle Aufgaben, die währen des Build-Prozesses anfallen können. Die Abbildung 2 zeigt hierbei einen beispielhaften Ablauf, der wie folgt beschrieben werden kann:

Ausgabe aller Parameter für diesen Build
Verbindung zum Netzlaufwerk herstellen
Kopieren der Kernsoftware in das Arbeitsverzeichnis
Aufruf des Ant-Skriptes zur Paketierung der Anwendung
Speichern der Build-Artefakte im TFS
Verbindung zum Netzlaufwerk trennen

Die verschiedenen Build-Schritte werden vom TFS bereitgestellt. Des Weiteren ist es möglich eigene Erweiterungen für den TFS zu entwickeln, beziehungsweise den Erweiterungsmanager zu verwenden.

Ebenso wäre es natürlich möglich als Continuous Integration Plattform beispielsweise den Apache Jenkins oder Atlassian Bamboo zu verwenden, da diese einen ähnlichen Funktionsumfang besitzen.

Gebaut wird mit Ant

Innerhalb des Ant-Skriptes wird der eigentliche Build gesteuert. Die verschiedenen personalisierten Softwareteile werden innerhalb des Arbeitsverzeichnisses in die Kernsoftware integriert. Hierbei werden verschiedene Teile der Kernsoftware überschrieben, bzw. neue Teile hinzugefügt. Neue Softwareteile werden der Kernsoftware durch verschiedene Property-Dateien bekannt gemacht.
Nach der vollständigen Integration aller personalisierten Softwareteile, wird das gesamte Arbeitsverzeichnis als Java-Enterprise-Applikation gepackt.

Ein erfolgreicher Build führt zum Deployment

Wurde der Build erfolgreich durchgeführt, kann der TFS hierauf automatisch reagieren und ein Deployment auf dem WebSphere Application Server durchführen. Ermöglicht werden kann das durch die Verwendung von entsprechenden Erweiterungen, der einzelnen Java Enterprise Application Server oder durch die Verwendung eines weiteren Build- bzw. Deployment-Skriptes durch Maven oder Ant.

Ausblick

In der aktuellen Konfiguration wird das gesamte Deployment automatisiert. Allerdings zieht eine Änderung der Software nicht selten auch eine Änderung an der Datenbank mit sich.

Dieser Teil des Build- und Deployment-Prozesses ist momentan manuell zu tätigen. Um die Struktur der Datenbank ebenfalls automatisiert anpassen zu können, kann beispielsweise auf Tools wie Liquibase zurückgegriffen werden.

Tools zur automatischen Anpassung von Datenbanken sollten allerdings nicht in der Produktiv- oder Prelive- Umgebung eingesetzt werden, da hier immer die Anpassungen an der Datenbank manuell erfolgen müssen.

Fazit

Durch die Verwendung des Team Foundation Server und der Continuous-Integration-Funktionalität ist es nun möglich, den gesamten Build-Prozess von einem neuen Commit im Git-Branch bis zum Deployment auf dem jeweiligen Server stark zu reduzieren.

In unserem Beispiel wurde somit die Zeit für ein Deployment von ungefähr 40 Minuten manuellen Arbeitsaufwands auf insgesamt fünf Minuten automatisierte Verarbeitung reduziert.

Durch diesen Ansatz ist sehr früh ersichtlich, ob der aktuelle Stand der Entwicklung ein wirklicher Kandidat für die Produktionsumgebung ist oder nicht. Die gesamte Softwarequalität kann durch einen solchen automatisierten Prozess erheblich verbessert werden.

Durch eine weitere Erhöhung des Automatisierungsgrades, gerade im Bereich der Datenbankaktualisierung, kann so in Zukunft noch mehr Zeit eingespart werden.

Glossar

Apache Ant
Software zur automatisierten Erstellung von installierbaren Softwarepaketen aus existierendem Quellcode. Gesteuert wird Ant durch eine Build-Datei im XML-Format, in welchem die einzelnen Build-Schritte definiert werden.

Continuous Integration
Continuous Integration beschreibt den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung. Das Ziel der kontinuierlichen Integration ist die Steigerung der Softwarequalität.

Git
Eine Software zur verteilten Versionsverwaltung von Dateien. Git ist ein sehr beliebtes Tool innerhalb von Softwareentwicklungsprojekten, da hierdurch sowohl die Versionsverwaltung als auch die parallele Arbeit im Team ermöglicht wird.

Smoke-Test
Ein funktionaler Test, der in diesem Fall die grundsätzliche Funktionalität der Software sowie die Verbindung mit den nach- bzw. vorgelagerten Systemen prüft.

Team Foundation Server
Der Team Foundation Server von Microsoft ist eine Continuous Integration Plattform, die zur Verwaltung von Repositories, von Arbeitspaketen und Testfällen sowie dem Build und Release Management genutzt werden kann. Ähnliche Produkte sind beispielsweise der Apache Jenkins und Bamboo von Atlassian.