sdk Onews022017

Software Development Kit (SDK):

Build-Prozess mal anders

In diesem ersten Artikel der zweiteiligen Reihe werden die Grundkonzepte sowie die Verwendung von System Time dargestellt. In der nächsten Ausgaben werden dann die Benutzung von Business Time und die Kombination aus System- und Business Time gezeigt.

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:

  1. Ausgabe aller Parameter für diesen Build
  2. Verbindung zum Netzlaufwerk herstellen
  3. Kopieren der Kernsoftware in das Arbeitsverzeichnis
  4. Aufruf des Ant-Skriptes zur Paketierung der Anwendung
  5. Speichern der Build-Artefakte im TFS
  6. 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.

 

Phillipp Kürsten ()