Software-Lebenszyklus-Richtlinie für Automation 360
- Zuletzt aktualisiert2024/10/18
Software-Lebenszyklus-Richtlinie für Automation 360
Die Software-Lebenszyklus-Richtlinie von Automation Anywhere zielt darauf ab, Ihnen Innovationen und Verbesserungen schnell zur Verfügung zu stellen. Auf diese Weise bieten wir Ihnen Planbarkeit, Qualität und vor allem einen unterbrechungsfreien Zugang zu den neuesten Innovationen und Verbesserungen, sodass Sie selbst bestimmen können, wann und wie Sie diese Verbesserungen übernehmen möchten.
Übersicht
Die Software-Lebenszyklus-Richtlinie unterstützt Sie beim Änderungsmanagement und bietet Ihnen die neuesten Software-Updates mit Verbesserungen für den Control Room, den Bot Agent und packages.
- Planbarkeit: Dank häufiger, regelmäßiger Bereitstellungszyklen können Sie schneller als bisher und in vorhersehbaren Intervallen auf neue und verbesserte packages zugreifen.
- Bereitstellung neuer Funktionen: Da Sie die Kontrolle über die Einführung von Änderungen an Ihren bots haben, können Sie neue Funktionen testen und in Ihrem eigenen Tempo bereitstellen.
- Qualität: Mit automatisierten Bereitstellungen von Automation 360 Cloud können Sie neue packages nutzen, die kritische Fehler- und Sicherheitsbehebungen enthalten.
- Unterbrechungsfreier Zugang: Sie können Pakete aktualisieren, ohne Ihre existierenden Konfigurationen zu stören.
- Abwärtskompatibilität: Sie haben jetzt die Möglichkeit, bots sicher zu aktualisieren und gleichzeitig zu einer früheren Version eines packages zurückzukehren.
Die folgende Abbildung zeigt die Vorteile dieser Lebenszyklus-Richtlinie:
Control Room
Automation 360 nutzt die neuesten Best Practices bei der Entwicklung und Bereitstellung inkrementeller Software-Updates über alle Bereitstellungsmodelle hinweg, unter Verwendung einer kontinuierlichen Entwicklungs- und Bereitstellungspipeline. Automation 360 Control Room-Software-Updates werden ungefähr alle 3 Monate veröffentlicht.
Die Updates werden in der Regel in der folgenden Reihenfolge bereitgestellt:
- Community Edition und Cloud-Sandbox: Diese Cloud-Umgebungen werden automatisch mit vorherigen Benachrichtigungen aktualisiert, die auf der Automation 360 Cloud Service Status site angezeigt werden. Als Kunde können Sie eine Cloud-Sandbox-Control Room-Umgebung verwenden, um das nächste Update mindestens drei Wochen vor Aktualisierung der Hauptentwicklungs- (Dev), Test- (Test oder UAT) und Produktionsumgebung (Prod) von Cloud zu testen.
- Automation 360 On-Premises Control Room: Die On-Premises-Umgebung wird nach der Community Edition und Cloud-Sandbox auf der Seite „A-People Downloads page (Login required)“ veröffentlicht. Nutzer müssen das Update manuell von der Downloads-Seite herunterladen und ihre Control Room-Instanzen aktualisieren.
- Automation 360 Cloud: Die Cloud-Umgebungen werden automatisch mit vorherigen Benachrichtigungen aktualisiert. Diese Updates werden in der Regel drei bis vier Wochen nach dem Cloud-Sandbox-Update bereitgestellt. Diese Cloud-Updates sind so eingeplant, dass sie außerhalb der Geschäftszeiten und nicht nahe dem Beginn oder Ende eines Monats stattfinden. Cloud-Update-Benachrichtigungen werden auf dem Automation 360 Cloud Service Status site 2 Wochen vor dem Update veröffentlicht.
Automation 360-Softwareupdates sind kumulativ für alle neuen Funktionen. Gemäß unseren Richtlinien für Softwareupdates werden Fehler nur in der neuesten Version des Softwareupdates behoben. Obwohl wir n-2-Versionen (wobei n auf die neueste Version verweist) für On-Premises-Bereitstellungen unterstützen, empfehlen wir On-Premises-Kunden ein Update auf die neueste Version, um von den neuesten Funktionen und Fehlerbehebungen zu profitieren.
Bot Agent-Updates
Wenn eine neue Version des Bot Agents verfügbar ist, wird der Bot Agent standardmäßig automatisch im Gerätepool eines Kunden bereitgestellt, ohne dass die bestehende bot-Funktionalität beeinträchtigt wird. Control Room-Administratoren können diese standardmäßige Aktualisierungsfunktion jedoch deaktivieren und den Bot Agent manuell aktualisieren. Bei manuellen Aktualisierungen und im Falle eines obligatorischen Updates werden Nutzer benachrichtigt, dass der Bot Agent aktualisiert werden muss, und alle bot-Ausführungen auf diesen Geräten werden angehalten, bis der Bot Agent aktualisiert wurde.
Bei größeren Bereitstellungen, bei denen nach separaten Zeitplänen Gerätepools mithilfe von Standard-AMIs (Amazon Machine Image) bereitgestellt werden, erfordern diese Updates eine umfangreichere Koordination, Änderungsmanagementprozesse und Genehmigungen in der Kundenumgebung. Daher unterstützt Automation 360 alle 6 Monate eine abwärtskompatible Bot Agent-Version.
Ab Automation 360 v.24 werden 4 Bot Agent-Updates pro Jahr veröffentlicht, davon 2 optionale und 2 Updates, die als obligatorisch bezeichnet werden können. Sie können optionale Updates überspringen und auf das nächste obligatorische Bot Agent-Update aktualisieren.
Unsere Veröffentlichungen in Q2 und Q4 umfassen optionale Bot Agent-Updates, und Sie können entscheiden, das Bot Agent-Update zu überspringen. Die Veröffentlichungen in Q1 und Q3 enthalten jedoch u. U. obligatorische Bot Agent-Updates. Wir benachrichtigen unsere Kunden drei Monate im Voraus, wenn ein obligatorisches Bot Agent-Update für eine Control Room-Version erforderlich ist. Weitere Informationen finden Sie unter Bot Agent compatibility.
Package-Updates
Ab Version Automation 360 v.24 wird die Bereitstellung von packages getrennt von den Updates der Hauptplattform entwickelt. Dies wird uns künftig dabei helfen, schnell erforderliche Änderungen und Korrekturen vorzunehmen, und verleiht uns die Flexibilität, Updates in packages zu liefern.
Mit dieser Funktion können neue packages und neue package-Versionen nun automatisch aus Automation Anywhere Cloud heruntergeladen werden, wenn sie planbar in einem vierteljährlichen Rhythmus veröffentlicht werden. Diese heruntergeladenen packages werden automatisch als Standard-package eingestellt, sodass die Kunden diese packageversionen kontinuierlich nutzen können, sobald sie verfügbar werden.
Die Funktion wird bei Cloud und On-Premises Control Room-Instanzen unterschiedlich aktiviert, wie in der folgenden Tabelle aufgeführt:
| Nahtlose package-Updates | Cloud Control Room | On-Premises Control Room |
|---|---|---|
| packages Von Automation Anywhere Cloud herunterladen | Standardmäßig aktiviert und kann nicht deaktiviert werden | Standardmäßig deaktiviert und kann aktiviert werden |
| Heruntergeladenes package als Standardversion festlegen | Standardmäßig aktiviert und kann deaktiviert werden | Standardmäßig aktiviert und kann deaktiviert werden |
-
Cloud-Nutzer: Die automatische Download-Funktion für packagee ist jetzt für alle Control Room-Instanzen in allen Regionen gleichzeitig aktiviert.
Sie können die neuesten packages in Ihrer aktuellen Control Room-Version verwenden, bevor das Control Room-Update in Ihrer Region verfügbar ist.
- On-Premises-Nutzer: Diese Funktion ist standardmäßig deaktiviert, kann aber von package-Administratoren aktiviert werden.
Wir empfehlen bot-Entwicklern, immer die neueste Version von packages zu verwenden, da sie sowohl die aktuellen Innovationen als auch alle Code- und Sicherheitskorrekturen der vorherigen Versionen enthält. Administratoren können dieses Standardverhalten jedoch jederzeit ändern und die packages nach einer Überprüfung für die Entwickler bereitstellen. Diese neuen packageversionen sind auch abwärtskompatibel mit der bestehenden Plattformversion.
Beachten Sie, dass diese Fähigkeit keine Auswirkungen auf bestehende bots hat, die unverändert weiterlaufen. Bots, die mit einer bestimmten package-Version entwickelt wurden, werden dies immer tun, es sei denn, sie werden ausdrücklich vom bot-Entwickler geändert. Dies bietet bot Entwicklern die Flexibilität, neue package-Versionen zu übernehmen, wenn sie bereit dafür sind. Bot Entwickler müssen explizit die bots in der Bot editor-Ansicht bearbeiten und die neue package-Version verwenden.
Support- und Einstellungsrichtlinie für packages
- Packageversionen, die mindestens 2 Jahre lang unterstützt werden
-
Packageversionen, die veröffentlicht werden, werden mindestens 2 Jahre lang nach der Veröffentlichung weiter unterstützt. Selbst nach 2 Jahren wird eine packageversion weiter unterstützt, sofern sie nicht eingestellt wurde.
In der Regel wird eine neue Version des packages zur Verfügung gestellt, wenn ein package eingestellt wird. Alle für das package gemeldeten Probleme und Sicherheitsupdates werden in der neuesten Version behoben (ohne Rückportierung).
Sie werden 3 Monate im Voraus benachrichtigt, wenn eine packageversion eingestellt wird. Wenn eine kritische Sicherheitslücke vorliegt, bemühen wir uns, eine Vorankündigung zu senden.
- Versionskompatibilität von Packagesn mit Bot Agent und Control Room
- Paketversionen und bots, die diese Versionen verwenden, werden mit allen Control Room- und Bot Agent-Versionen kompatibel sein, die innerhalb von 2 Jahren nach der Veröffentlichung der package-Version veröffentlicht werden. Bots, die diese unterstützten Paketversionen verwenden, müssen nicht so konfiguriert werden, dass sie mit den Control Room- und Bot Agent-Versionen kompatibel sind.
- Einstellungsrichtlinie für packageversionen
- Packageversionen werden nur dann innerhalb von 2 Jahren nach ihrer Veröffentlichung eingestellt, wenn eine kritische Sicherheitslücke vorliegt, die behoben werden muss. In einem solchen Fall wird eine neue packageversion mit der Korrektur zur Verfügung gestellt.
- Minimale bot-Änderungen
- Ziel der Supportrichtlinie für packageversionen ist es, den Aufwand für die Änderung bestehender bots zu minimieren und sie funktionsfähig zu halten.
Bots, die eine bestimmte packageversion verwenden, müssen nicht aktualisiert werden, um die packageversionen nutzen zu können, sofern die vorhandene packageversion unterstützt wird. Wir empfehlen jedoch, bei der Entwicklung des packages die neueste botversion zu verwenden, um die Lebensdauer des bots zu erhöhen. Die packageversionen, die in einem bot verwendet werden, müssen aktualisiert werden, bevor sie eingestellt werden, damit der bot weiterhin unterstützt wird.
Richtlinie zur Einstellung von APIs
Eine veraltete API bedeutet, dass die Verwendung einer API nicht mehr empfohlen wird, sie aber noch funktioniert. Entwickler werden ermutigt, auf neuere, unterstützte Versionen der API zu migrieren. Die API wird bis zum End-of-Life-Datum (EoL) und der Release-Version verfügbar sein, um einen reibungslosen Übergang zu ermöglichen.
API EoL (End of Life) gibt das Datum und die Release-Version an, an dem die API nicht mehr funktioniert und nicht mehr verwendet werden kann. Entwickler sollten ihre Migration auf die neueren, unterstützten Versionen der API vor diesem Datum abgeschlossen haben.
Die folgenden Szenarien können die Außerkraftsetzung von APIs erfordern:
- Sicherheitslücken: Ältere API-Versionen enthalten bekannte Sicherheitslücken, die in neueren Versionen behoben wurden.
- Technische Schulden: Ältere API-Versionen können auf veralteten Technologien, Ansätzen oder Frameworks basieren, die nicht mehr unterstützt werden, was Wartung oder Erweiterungen erschwert.
- Performance: Ältere API-Versionen sind nicht für moderne Anwendungsfälle oder Skalierungssteigerungen optimiert, was zu schlechter Performance und langsameren Reaktionszeiten führt.
- Benutzererlebnis: Veraltete API-Versionen enthalten verwirrende oder redundante Endpunkte, die es den Nutzern erschweren können, sich zurechtzufinden.
APIs werden für einen Mindestzeitraum von zwei Jahren unterstützt. Nach zwei Jahren kann eine Außerkraftsetzung einer API angekündigt werden, wobei die API mindestens ein weiteres Jahr lang (vier Versionen) verfügbar ist, um Ihnen ausreichend Zeit zu geben, auf die neuere Version umzusteigen.
Bot-Lebenszyklus
Bei der Entwicklung von bots wird davon ausgegangen, dass die Version des packages, die in den bots verwendet wird, im Control Room vorhanden ist, der zur Ausführung der botsverwendet wird. Bevor Entwickler bots übertragen, wird empfohlen, zu überprüfen, ob die im package verwendete Version der bots mit der packageversion in den übergeordneten Umgebungen übereinstimmt.