Alle Low-Code Plattformen haben ihre Stärken und Schwächen. Im folgenden Blogartikel möchte ich auf die verschiedenen Plattformen hinsichtlich ihrer Versionierung einer Applikation eingehen.
Wenn wir mit mehreren Entwicklern zusammen an einer Anwendung arbeiten, sind Versionskontrollsysteme (VCS) gar nicht mehr wegzudenken. Ohne sie geschieht es schnell, dass die Änderungen beim Deployment gegenseitig überspielt werden.
Viele Teams greifen zu Versionskontrollsystemen wie GIT oder Subversion um eventuelle Konflikte im Code zu erkennen und anschließend zu beseitigen. Daraufhin wird die aktuelle Version der Software in einer Zielumgebung installiert. Software wie Jenkins kann dabei helfen, diesen Installationsprozess zu automatisieren. Der Einsatz von einem VCS sowie einer Build-Software kostet jedoch viel Aufwand, sowohl bei der Einführung als auch im Betrieb.
Oracle Application Express (APEX) bietet von Haus aus keine Versionskontrolle. Die nötigen Features eines Versionskontrollsystems lassen sich jedoch mit einigen Workarounds auch in APEX realisieren. Dennoch ist auch dieser mit Zeit und Aufwand verbundene Ansatz nicht die optimalste Lösung.
Bei der Nutzung von VisionX bin ich auf Versionskontrollsysteme wie GIT angewiesen. Wäre es nicht besser, wenn wir diese Zeit in die Entwicklung investieren könnten?
Service Studio, die Low-Code IDE von OutSystems, ist dieser Thematik einen Schritt voraus und bietet uns eine integrierte Lösung für Konfliktmanagement, sowie für den automatisierten Build-Prozess. Die Software wird nämlich auf dem Client definiert (nicht programmiert) und dann per Klick auf dem Server lauffähig gebracht. Somit existieren keine Abhängigkeiten von externen Kontrollsystemen. Alle Versionen der Software stehen über das Tool Service Center zur Verfügung und können unabhängig voneinander bearbeitet oder eingespielt werden.
Abb 1: Versionsverwaltung mittels Service Center
Aber wie sieht es mit dem Konfliktmanagement aus, falls wir mit mehreren Entwicklern dieselbe Anwendung bearbeiten müssen? OutSystems merkt sich, welche Änderungen seit dem Arbeitsbeginn bzw. der letzten Version vorgenommen wurden. Meine zuerst veränderte und im Anschluss veröffentlichte Version wird erkannt und sorgt für eine Meldung, sobald mein Kollege seine Änderungen ebenfalls veröffentlichen möchte. Ab diesem Punkt erhält der Entwickler, welcher seine Version zuletzt veröffentlicht hat, die Möglichkeit, Änderungen bzw. Konflikte zu vergleichen. Falls Konflikte bestehen, kann der Entwickler entscheiden, welche Änderungen eines Moduls beibehalten oder verworfen werden sollen. Sollten jedoch keine Konflikte bestehen, werden die Änderungen automatisch übernommen.
OutSystems bietet außerdem eine „Developer Sandbox“ an. Diese Sandbox wird in eine private und eine öffentliche Sandbox unterteilt. Solange ich in meiner privaten Sandbox arbeite, kann ich meine Änderungen an einer Applikation für mich selbst veröffentlichen. Hiermit wird uns ermöglicht, parallel an einem Entwicklungsserver zu arbeiten, ohne die Arbeit der anderen zu beeinträchtigen. Wenn meine Änderungen an der Applikation fehlerfrei funktionieren, kann ich diese mit der aktuellen Version der öffentlichen Sandbox verbinden und den anderen Entwicklern zugänglich machen.
Zu guter Letzt stellt sich noch die Frage, wie das Deployment von z.B. Hotfixes für eine Applikation abläuft. Es kann nämlich vorkommen, dass wir bereits eine neue Version entwickeln, aber auf Basis der bestehenden Version in der Produktion ein Update entwickelt werden muss. Hier bietet OutSystems die Möglichkeit, sogenannte Snapshots von einer bestimmten Version zu machen und diese mit einem Tag zu versehen. Es wird dann ein Abbild von dieser Applikation und deren Abhängigkeiten erstellt. Auf dieser Basis kann z.B. einen Hotfix entwickelt werden, der später mit der Hauptversion zusammengeführt wird.
Weitere Informationen über Lifecycle Management mit OutSystems finden Sie auf den Seiten von OutSystems.