Getty Images
Bewährte Praktiken für die Low-Code-Integration
Wenn ein nichttechnisches Team die Anwendungsentwicklung leitet, obliegt es dennoch Entwicklern und Testern, Low-Code-Anwendungen in die Pipeline zu integrieren.
Entwickler und Tester müssen in den frühen Phasen der Low-Code-Entwicklung die richtigen Fragen stellen – einschließlich Fragen zur Integration.
Eine vorausschauende Planung der Low-Code-Integration kann Probleme im weiteren Verlauf des Entwicklungsprozesses verhindern. Teams müssen bedenken, wie Low-Code-Anwendungen weiterhin funktionieren werden, wenn sich die zugrunde liegenden Unternehmens-APIs ändern. Sie müssen auch festlegen, wer für die Integration von Low-Code-Tools in die Entwicklungspipeline verantwortlich ist und welche Plattformen sie für die Verwaltung dieses Prozesses verwenden.
Herausforderungen der Low-Code-Integration
Anhand eines Beispiels lassen sich einige der wichtigsten Herausforderungen für ein Entwicklungsteam im Zusammenhang mit der Low-Code-Integration veranschaulichen.
Nehmen wir an, ein Lebensmittelgeschäft entwickelt eine App für eine mobile Einkaufsliste. Die Idee stammt ursprünglich aus der Marketingabteilung, und die Anwendung soll den Einkauf für die Kunden vereinfachen. Das Unternehmen verwendet Low-Code-Tools, um den Entwicklungsprozess der App zu starten.
Die Einkaufslisten-App existiert jedoch nicht isoliert. Sie nutzt APIs, um auf den Produktkatalog des Unternehmens zuzugreifen, so dass die Nutzer nach Produkten suchen und sie zu ihrer Einkaufsliste hinzufügen können. Die App verknüpft das Produkt auch mit einer Gangnummer in einem bestimmten Geschäft, so dass die Benutzer ihre Liste nach Gängen organisieren können. Die APIs, die diese Funktionalität ermöglichen, ändern sich mit der Zeit und sind nicht versioniert.
Darüber hinaus möchte der Projektleiter, dass das Tool in der Staging-Umgebung getestet wird. In diesem Beispiel gibt es einige Punkte, welche die Integration betreffen. Die API ist einer davon, der Build ein anderer, der vielleicht noch entscheidender ist.
Sobald die Marketingabteilung das Projekt abgeschlossen hat, muss jemand dafür sorgen, dass die App funktioniert, während sich die Software um sie herum weiter verändert.
Integrationspunkte für Low-Code-Tools
Die meisten CI/CD-Tools gehen von einem einfachen Build-Paradigma aus. Das Tool, zum Beispiel Jenkins oder CircleCI, läuft auf einem Server, physisch oder virtuell. Dieser Server läuft unter einem Betriebssystem, zum Beispiel Linux oder Windows. Ein Build checkt den Code aus der Versionskontrolle aus und führt ein Build-Skript aus. Das Build-Skript gibt eine Null (Erfolg) oder eine Eins (Fehler) an das Betriebssystem zurück und kann die Ergebnisse als stdout (Standardausgabe) oder stderr (Standardfehlerausgabe) schreiben. So kann das Tool den Schritt rot oder grün anzeigen und eventuell Text anzeigen. Wenn das Skript Testergebnisse in einer Datei erzeugt, kann ein Post-Build-Schritt diese Testergebnisse mit dem Build verbinden.
Das Problem bei diesem Paradigma ist, dass viele Low-Code-Tools keinen Befehlszeilen-Runner haben. Wenn sie einen haben, dann vielleicht für das falsche Betriebssystem. Und wenn doch und für das richtige Betriebssystem, haben sie möglicherweise keinen Mechanismus zum Einchecken, Festschreiben, Überprüfen und Genehmigen von Änderungen. Stattdessen verfügt das Tool möglicherweise nur über eine Schaltfläche zum Speichern. Das heißt, wenn CI/CD einen Build startet, kann dieser die letzte ungeprüfte Arbeit eines Entwicklers enthalten.
All diese Bedenken werfen Fragen zur Architektur auf, bevor man sich für ein Low-Code-Tool entscheidet. Ein Low-Code-Tool, das kein Konzept für das Promoten von Code hat, ist am besten für eine Pipeline geeignet, die von der Hauptcodebasis getrennt ist. Allerdings kann sowohl die Pipeline des Low-Code-Tools als auch die APIs selbst Vertragstests haben, bei denen von den APIs erwartet wird, dass sie auf eine bestimmte Weise funktionieren. Wenn die API so geändert wird, dass die Einkaufslisten-App nicht mehr funktioniert, möchte das Unternehmen die Freigabe der Software wahrscheinlich blockieren. Das bedeutet, dass ein Vertragstest an zwei Stellen zum Ausdruck kommt: in der API und im Low-Code-Tool selbst.
Einige Low-Code-Tools wie Mendix verfügen über eine API für den Zugriff auf das Build, andere über eine Befehlszeile. Canonic ist ein Low-Code-Backend-as-Service-Tool, bei dem der Code in GitHub ausgedrückt wird, was Codeprüfungen, Tests und Pull-Requests ermöglicht. Mit Canonic kann die Build-Pipeline wie bei der traditionellen Softwareentwicklung lokal ausgeführt, bestanden und dann zusammengeführt werden.
Die meisten Low-Code-Tools stellen den Code jedoch in ihren eigenen Walled Garden, bis hin zu ihrer eigenen CI/CD-Plattform. Die Entwicklungsteams entscheiden sich dann für einen Tool-Anbieter, der sowohl Low-Code-Tools als auch andere Unternehmenssoftware anbietet, wie Microsoft, Oracle oder Salesforce. Auf diese Weise haben sie die besten Chancen, beides nahtlos miteinander zu verbinden.
Integrationstests und Pflege
An diesem Punkt gibt es zwei Optionen für unsere Einkaufslistenanwendung: Aufruf des Low-Code-Builds aus der bestehenden CI/CD-Pipeline oder Beibehaltung eines separaten Build-Prozesses.
Beide Optionen können Tests beinhalten, die APIs in der Legacy-Software aufrufen. Diese APIs müssen bekannt gute Antworten haben. Die Testteams müssen Code zum Aufrufen der APIs erstellen. Dazu können sie ein API-Testtool wie SoapUI oder Postman verwenden oder kleine benutzerdefinierte Skripts in einer Produktionsprogrammiersprache erstellen.
Pytest ist ein Python-basiertes Integrationstest-Tool, mit dem Tests und Skripte für den Aufruf von APIs erstellt werden können. Wenn das Team Python nicht kennt oder verwendet, sollte es ein anderes Tool oder eine andere Programmiersprache verwenden, mit der es vertraut ist. Ein letztes Element, das zu berücksichtigen ist, ist das Passwort und die Anmeldung bei diesen Tools. Die meisten APIs erfordern sie, und die Python-Skripte, die die API aufrufen, müssen sie ebenfalls kennen. Denken Sie an eine Anwendung für das Secret-Management, so wie Sie es bei Passwörtern für andere Unternehmensanwendung machen würden.
Sobald diese Skripte existieren, muss sie jemand pflegen. Am besten eignet sich dafür dasselbe Team, das auch das traditionelle CI/CD-System verwaltet. Das kann ein DevOps-Team, ein internes Architekturteam oder möglicherweise das Programmierteam sein.
Bei der Beispiel-Einkaufslisten-App verfügt das Unternehmen jedoch nicht über ein zentrales DevOps-Team. Stattdessen unterstützen die Entwicklungsteams die Systeme, für die sie zuständig sind. Das Marketingteam hat die App als einmaliges Projekt entwickelt. Der Projektleiter wird wahrscheinlich das API-Team für die Produktsuche damit beauftragen, den Build in Zukunft zu pflegen, was wahrscheinlich die beste Lösung ist.
Mit diesen Ideen kann ein kluges Team das Low-Code-Projekt unterstützen und gleichzeitig die Freigaben mit neuem Code zeitlich abstimmen, wodurch die Zuverlässigkeit beider Systeme gewährleistet wird. Dies zeigt, dass Teams mit ein wenig Vorarbeit die Herausforderungen der Low-Code-Integration minimieren können.
