Politique de cycle de vie des logiciels Automation 360
- Dernière mise à jour2024/10/18
Politique de cycle de vie des logiciels Automation 360
La politique de cycle de vie des logiciels Automation Anywhere vise à mettre rapidement à votre disposition les innovations et les améliorations. Grâce à cette politique, nous vous offrons la prévisibilité, la qualité et, surtout, un accès non perturbé aux dernières innovations et améliorations afin que vous puissiez contrôler quand et comment vous souhaitez adopter ces améliorations.
Présentation
La politique de cycle de vie des logiciels vous aide à gérer les changements tout en vous fournissant les dernières mises à jour avec des améliorations dans les domaines suivants : Control Room, Bot Agent, et packages.
- Prédictions : Grâce à des cycles de déploiement fréquents et réguliers, vous pouvez accéder aux nouveautés et aux améliorations de packages plus tôt qu\'avant et à une cadence de publication prévisible.
- Déployer de nouvelles fonctionnalités : En contrôlant l\'introduction de changements dans vos robots, vous pouvez tester de nouvelles fonctionnalités et les déployer à votre propre rythme.
- Qualité : Grâce aux déploiements automatisés de Automation 360 cloud, vous pouvez utiliser les nouveaux packages qui incluent des corrections critiques de bogues et de sécurité.
- Accès non perturbateur : Vous pouvez mettre à jour les packages sans perturber vos configurations.
- Rétrocompatibilité : Vous avez maintenant la possibilité de mettre à jour les robots en toute sécurité, et de revenir à une version antérieure d\'un package.
L\'image suivante montre les avantages de cette politique de cycle de vie :
Control Room
Automation 360 tire parti des meilleures pratiques les plus récentes pour développer et déployer des mises à jour logicielles incrémentielles à travers tous les modèles de déploiement en utilisant un pipeline de développement et de déploiement continu. Automation 360 Control Room les mises à jour logicielles sont publiées environ tous les 3 mois.
Les mises à jour sont généralement déployées dans l\'ordre suivant :
- Édition Community et cloud-Sandbox : Ces environnements cloud sont automatiquement mis à jour avec des notifications préalables publiées sur le Automation 360 Cloud Service Status site. En tant que client, vous pouvez utiliser un environnement cloud-Sandbox Control Room pour tester la prochaine mise à jour au moins trois semaines avant la mise à jour des principaux environnements cloud de développement (Dev), de test (Test ou UAT) et de production (Prod).
- Automation 360 Sur site Control Room: L\'environnement Sur site est publié après Édition Community et cloud-Sandbox sur l\'A-People Downloads page (Login required). Les clients doivent télécharger manuellement la mise à jour à partir de la page des téléchargements et mettre à jour leurs instances de la Control Room.
- Automation 360 cloud: Les environnements cloud sont mis à jour automatiquement avec des notifications préalables. Ces mises à jour sont généralement déployées trois à quatre semaines après la mise à jour d\'cloud-Sandbox. Ces mises à jour Cloud sont prévues pour se produire en dehors des heures de travail et pas près du début ou de la fin d\'un mois. cloud Les notifications de mise à jour sont publiées sur le Automation 360 Cloud Service Status site 2 semaines avant la mise à jour.
Les mises à jour logicielles d\'Automation 360 peuvent être cumulées avec toutes les nouvelles fonctionnalités. Conformément à notre politique de mise à jour logicielle, les bogues sont résolus uniquement dans la dernière version de la mise à jour logicielle. Bien que nous prenons en charge les versions n-2 (où n fait référence à la dernière version) pour les déploiements de Sur site, nous recommandons aux clients Sur site de mettre à jour vers la dernière version pour bénéficier des dernières fonctionnalités et des correctifs de bogues.
Mises à jour de Bot Agent
Lorsqu\'une nouvelle version de l\'Bot Agent est disponible, par défaut, la version de l\'Bot Agent est déployée automatiquement sur le pool de périphériques d\'un client, sans impact sur les fonctionnalités existantes du robot. Cependant, les administrateurs de la Control Room peuvent désactiver cette fonction de mise à jour par défaut et choisir de mettre à jour manuellement l\'Bot Agent. En cas de mises à jour manuelles et dans l\'éventualité d\'une mise à jour obligatoire, les utilisateurs seront informés que l\'Bot Agent doit être mis à jour et que toute exécution du robot sur ces appareils s\'arrêtera jusqu\'à la mise à jour effective de l\'Bot Agent.
Pour les déploiements à plus grande échelle, lorsque les pools de périphériques sont déployés à l\'aide d\'une Amazon Machine Image (AMI) de périphérique standard sur des planifications séparées, ces mises à jour nécessitent de la coordination, des processus de gestion des modifications et des approbations dans l\'environnement utilisateur. Par conséquent, Automation 360 supportera la version rétrocompatible Bot Agent pour une publication tous les 6 mois.
À partir de Automation 360 v.24, 4 mises à jour de l\'Bot Agent seront publiées chaque année, 2 facultatives et 2 qui pourraient être déclarées obligatoires. Vous pouvez ignorer la mise à jour facultative et passer à la prochaine mise à jour obligatoire de l\'Bot Agent.
Nos publications Q2 et Q4 auront des mises à jour Bot Agent facultatives. Vous pourrez choisir d\'ignorer la mise à jour Bot Agent. Cependant, les mises à jour Q1 et Q3 pourraient avoir des mises à jour obligatoires de l\'Bot Agent. Nous informerons nos clients 3 mois à l\'avance si une mise à jour obligatoire de l\'Bot Agent est requise avec une publication de la Control Room. Pour plus d\'informations, consultez Bot AgentCompatibilité.
Mises à jour de Package
À partir de la version Automation 360 v.24, la livraison des packages est développée pour être séparée des mises à jour principales de la plateforme. Cela nous aidera à répondre rapidement aux changements et aux corrections requis et nous donnera la flexibilité nécessaire pour fournir des mises à jour dans les packages à l\'avenir.
Grâce à cette fonction, les nouveaux packages et nouvelles versions de package peuvent désormais être téléchargées automatiquement à partir d\'Automation Anywhere cloud lorsqu\'ils sont publiés de manière prévisible selon une cadence trimestrielle. Ces versions de packages téléchargées sont définies comme package par défaut pour que les clients puissent utiliser ces versions de package en permanence, à mesure qu\'elles deviennent disponibles.
Cette fonction est activée différemment pour les instances cloud et Sur site de la Control Room, comme indiqué dans le tableau suivant :
| Fonction de mise à jour transparente du package | cloud Control Room | Sur site Control Room |
|---|---|---|
| Télécharger les packages depuis Automation Anywhere cloud | Activé par défaut et désactivation impossible. | Désactivé par défaut activation possible. |
| Définir la version de package téléchargée sur la version par défaut | Activé par défaut et désactivation possible. | Activé par défaut et désactivation possible. |
-
Utilisateurs de cloud : La fonction de téléchargement automatique du package est maintenant activée dans toutes les instances de la Control Room dans toutes les régions en même temps.
Vous pouvez commencer à utiliser les dernières versions de packages sur votre version actuelle de la Control Room avant que la mise à jour de la Control Room soit disponible dans votre région.
- Utilisateurs de Sur site : Cette fonction est désactivée par défaut mais elle peut être activée par les les administrateurs de package.
Nous recommandons aux développeurs de robot de toujours utiliser la dernière version des packages, car elle intègre les dernières innovations et l\'ensemble des correctifs de code et de sécurité des versions précédentes. Cependant, les administrateurs peuvent changer ce comportement par défaut à tout moment et déployer les packages aux développeurs après vérification. Ces nouvelles versions de package sont également rétrocompatibles avec la version existante de la plateforme.
Notez que cette fonctionnalité n\'a aucun impact sur les robots existants, qui continuent de fonctionner sans changement. Robots qui sont développés avec une version package particulière continueront toujours à le faire, sauf si cela est explicitement modifié par le développeur robot. Cela offre à robot développeurs la flexibilité d\'adopter de nouvelles package versions lorsqu\'ils sont prêts. Robot développeurs doivent explicitement modifier le robots dans la vue Éditeur de Bot et utiliser la nouvelle version package.
Politique de support et d\'obsolescence appliquée aux packages
- Les versions de Package sont prises en charge pendant un minimum de 2 ans
- Les versions de Package publiées continueront d\'être prises en charge pendant au moins 2 ans après leur publication. Même après 2 ans, une version de package continuera d\'être prise en charge, sauf si elle est obsolète.
Généralement, une nouvelle version du package sera mise à disposition si un package est obsolète. Tous les problèmes et correctifs de sécurité signalés pour le package seront corrigés dans la dernière version, sans rétroportage.
Vous serez informé 3 mois à l\'avance lorsque l\'obsolescence d\'une version de package est prévue. S\'il existe une faille de sécurité critique, nous ferons tout notre possible pour envoyer une notification préalable.
- Compatibilité des versions de Packages avec l\'Bot Agent et la Control Room
- Les versions de package et robots qui utilisent ces versions seront compatibles avec toutes les versions Control Room et Bot Agent publiées dans les 2 ans suivant la publication de la version package. Robots qui utilisent ces versions de package prises en charge n\'ont pas besoin d\'être configurés pour être compatibles avec les versions Control Room et Bot Agent.
- Politique d\'obsolescence sur la version du package
- Les versions de Package ne seront pas obsolescentes dans les 2 ans qui suivent leur sortie, sauf si une vulnérabilité de sécurité critique doit être corrigée. Dans ce cas, une nouvelle version de package sera mise à disposition avec le correctif.
- Changements minimum du robot
- La politique de support de la version de package a pour but de minimiser l\'effort nécessaire pour changer les robots existants et les maintenir en état de fonctionnement.
Les Robots utilisant une version spécifique de package ne doivent pas être mis à jour pour utiliser les versions de package si la version de package existante est prise en charge. Cependant, nous vous recommandons d\'utiliser la dernière version du package lors du développement du robot afin d\'augmenter la longévité du robot. Les versions de package utilisées dans un robot devront être mises à jour avant qu\'elles ne soient obsolètes pour que le robot reste pris en charge.
Politique de dépréciation de l\'API
La dépréciation de l\'API indique qu\'une API n\'est plus recommandée pour une utilisation mais est fonctionnelle. Les développeurs sont encouragés à migrer vers des versions plus récentes et prises en charge de l\'API. L\'API sera disponible jusqu\'à la date de fin de vie (EoL) et la version de sortie pour permettre une transition en douceur.
API EoL (Fin de Vie) indique la date et la version de publication à laquelle l\'API cessera de fonctionner et ne sera plus disponible à l\'utilisation. Les développeurs devraient avoir terminé leur migration vers les versions plus récentes et prises en charge de l\'API avant cette date.
Les scénarios suivants peuvent nécessiter la dépréciation des API:
- Vulnérabilités de sécurité: Les anciennes versions de l\'API contiennent des vulnérabilités de sécurité connues qui ont été corrigées dans les versions plus récentes.
- Dette technique: Les anciennes versions d\'API peuvent être construites sur des technologies, des approches ou des frameworks obsolètes qui ne sont plus pris en charge, rendant la maintenance ou les améliorations difficiles.
- Performance : Les anciennes versions de l\'API ne sont pas optimisées pour les cas d\'utilisation modernes ou les augmentations d\'échelle, ce qui entraîne de mauvaises performances et des temps de réponse plus lents.
- Expérience utilisateur : Les versions d\'API obsolètes contiennent des points de terminaison confus ou redondants qui peuvent rendre la navigation difficile pour les utilisateurs.
Les API seront prises en charge pendant une période minimale de 2 ans. Après 2 ans, une dépréciation de l\'API peut être annoncée, l\'API étant disponible pendant au moins un an de plus (quatre versions) pour vous donner suffisamment de temps pour passer à la version plus récente.
Cycle de vie du Robot
L\'hypothèse de conception des robots est que la version du package utilisée dans les robots est présente dans la Control Room qui est utilisée pour exécuter les robots. Avant que les développeurs ne promeuvent les robots, nous recommandons aux développeurs de vérifier que la version de package utilisée dans les robots correspond à la version de package des environnements supérieurs.