5 Tipps für effektivere Anwendungs-Releases

Von Tim Bond, Produktmanager

Low-Code-Entwicklungsteams verwenden beträchtliche Zeit und Energie darauf, die nächsten Funktionen für ihre Low-Code-Anwendungen zu konzipieren und zu entwickeln. Die Entwicklung robuster Apps, die die erwarteten Ergebnisse liefern, ist von größter Wichtigkeit. Aber der Prozess, die Anwendung von einer Entwicklungsumgebung über eine Testumgebung in eine Produktiv- oder Live-Umgebung zu überführen, wird allzu oft erst im Nachhinein bedacht.

Ein gut ausgearbeiteter und klar kommunizierter Plan für die Freigabe einer Anwendung in eine Produktionsumgebung ist der wichtigstens Bestandteil eines Go-Lives. Hier sind einige Punkte, die Sie vor jedem Release durchdenken sollten:

• Wann beginnt die Veröffentlichung und wie lange wird sie dauern?

  Arbeiten Sie mit den Beteiligten zusammen, um einen Zeitpunkt zu ermitteln, zu dem sie am wenigsten beeinträchtigt werden. Die Dauer ist schwer vorherzusagen – je öfter Sie es tun, desto besser werden Sie in der Lage sein, dies einzuschätzen. Versprechen Sie weniger bei Ihrer Schätzung, als Sie halten können.

• Wie sind die Endbenutzer während der Freigabe betroffen?

  Egal wie gut Sie Releases und geplante Ausfallzeiten im Voraus kommunizieren, Sie müssen davon ausgehen, dass sich ein Benutzer in der Anwendung befindet, wenn dies möglich ist. Das ist vielleicht kein Problem, aber wenn doch, sollten Sie in Erwägung ziehen, den Zugriff auf die Anwendung während des Wartungszeitraums zu sperren.

• Wer ist für jeden Schritt des Release-Prozesses verantwortlich?

  Ein detaillierter Plan sollte mit dem Team, das die Schritte ausführt, abgestimmt werden. Nehmen Sie sich die Zeit, den Plan gemeinsam durchzugehen, und betonen Sie, dass es keine dummen Fragen gibt, wenn es um die Klarheit des Release-Plans geht. Stellen Sie sicher, dass jede Person über den korrekten Zugriff verfügt, um die ihr zugewiesenen Schritte auszuführen.

• Welche neuen Verbindungen/Integrationspunkte zu Drittanwendungen werden eingeführt?

  Das erste Mal, wenn eine Verbindung oder Integration live geht, herrscht im Hinterkopf des Teams immer eine gewisse Ungewissheit. Ein falscher API-Schlüssel oder blockierter Netzwerkverkehr könnte den Plänen einen Strich durch die Rechnung machen. Entwickler sollten dies unbedingt gegenüber dem Team ansprechen, damit die neue Verbindung entsprechend eingeplant werden kann.

• Wie sieht der Rollback-Plan aus, wenn die Freigabe nicht erfolgreich ist?

  Dies ist niemals das erwartete oder erwünschte Ergebnis, aber ein im Voraus ausgearbeiteter Plan wird das Team in einer stressigen Situation leiten.

Sie haben nur eine Chance für einen erfolgreichen Go-Live beim ersten Versuch. Ich schlage vor, ein Test- oder Staging-Release als Probelauf für die Produktion zu nutzen, um eventuelle Probleme zu lösen.

Was die Jitterbit App Builder-Anwendungsreleases betrifft, erstellen Ihre Entwickler ein Release aus der Entwicklungsumgebung, laden die Release-Datei (wir bezeichnen sie als LP-Datei) herunter und laden sie zur Installation in die Zielumgebung hoch. Es gibt einige häufige Risiken, die Sie unbedingt überprüfen sollten, bevor Sie das Release erstellen und in der Produktionsumgebung installieren:

• Tabellen-Installationsoptionen:

  Meistens sind in Ihrem Release physische Tabellen enthalten. Jede Tabelle verfügt über eine Installationsoption, die festlegt, wie die in der Tabelle gespeicherten Daten gehandhabt werden, wenn das Release in einer Zielumgebung erstellt und anschließend installiert wird. Dies ist eine leistungsstarke Funktion, die jedoch mit Vorsicht eingesetzt werden sollte. Sie möchten auf jeden Fall vermeiden, hochwertige Produktionsdaten durch alle von Entwicklern erstellten Daten zu ersetzen. Weitere Informationen zu diesen Optionen finden Sie auf unserer Dokumentationsseite für ein Release-Paket erstellen.

• Rollen:

  Der Zugriff auf eine Seite sowie die nativen Erstellungs-, Bearbeitungs- und Löschfunktionen für die einem Benutzer auf einer Seite angezeigten Daten werden in der logischen Schicht granular gesteuert. Immer wenn ein Entwickler die Rollen einer Geschäftsregel ändert oder eine neue Geschäftsregel für eine Seite einführt, kann dies unbeabsichtigte Auswirkungen auf die Fähigkeit einer bestimmten Benutzergruppe haben, auf die Seite zuzugreifen. Das Erstellen eines Testbenutzers für jede Benutzergruppe und Regressionstests für Rollen sind eine hervorragende Praxis vor jeder Freigabe in die Produktion. Dies hilft Ihnen, die gefürchtete E-Mail von Ihrem Endbenutzer am Tag nach einem Release zu vermeiden: “Ich kann nicht mehr auf diese Seite zugreifen”. Schauen Sie sich an diese Dokumentationsseite für weitere Informationen zu Privilegien und Berechtigungen.

Überprüfen Sie jedes Mal, wenn Sie Ihre Jitterbit App Builder-Anwendung freigeben möchten, die Freigabevorlage sorgfältig. Sie sollten nur die Komponenten der Anwendung freigeben, die sich geändert haben und die Sie in die Produktion überführen möchten.

In Ihrer Release-Vorlage können Sie diese verschiedenen Komponenten auswählen. Sie können natürlich eine gesamte Anwendung veröffentlichen, die alle Datenquellen, die Logik und die Seiten umfasst. Oder, wenn Ihre Änderung geringfügiger war, könnten Sie nur eine einzelne Seite oder eine einzelne Geschäftsregel veröffentlichen und diese kleineren Komponenten in die Produktion übernehmen, während der Rest der Anwendung unverändert bleibt. Diese Flexibilität bei der Freigabeprozess ermöglicht es Ihrem Entwicklungsteam, einfacher auf kritische Probleme zu reagieren, die bei der Bearbeitung größerer Anfragen auftreten.

Die Anwendungs-Komponentenfunktion verbessert die Flexibilität, Geschwindigkeit und Kontrolle über den Software-Bereitstellungsprozess, was sie zu einem leistungsstarken Werkzeug in Umgebungen macht, die häufige Aktualisierungen und minimale Ausfallzeiten erfordern. Die Hauptvorteile für Ihre Entwicklungsteams sind:

• Modulare Updates:

  Ermöglicht die unabhängige Aktualisierung spezifischer Komponenten einer Anwendung, wodurch Code-Abhängigkeiten reduziert werden.

• Minimierte Ausfallzeiten:

  Nur die geänderten Komponenten werden aktualisiert, was reibungslosere Upgrades ermöglicht.

• Größere Entwicklungsagilität:

  Teams können schnell Updates oder Patches für einzelne Komponenten veröffentlichen, was die Reaktionszeit verbessert.

Mehr erfahren über Jitterbit App Builder, oder das Eine leistungsstarke Reihe von KI-Funktionen, die in Kürze für App Builder 4.0 verfügbar sein wird.