Automation 360 software lifecycle policy

Automation Anywhere software lifecycle policy aims to make innovations and enhancements available to you quickly. Through this policy, we provide you predictability, quality, and importantly nondisruptive access to the latest innovations and enhancements so that you can control when and how you want to adopt these enhancements.

Note: The policies mentioned on this page apply to both Automation 360 Cloud and On-Premises deployments unless where the differences are called out explicitly.

Overview

The software lifecycle policy helps you with change management while providing you the latest software updates with enhancements in the Control Room, Bot Agent, and packages.

Our policy aims to provide faster access to features, bug fixes, and other enhancements for a better customer experience:
  • Predictability: With frequent, regular deployment cycles, you can get access to new and enhanced packages sooner than before with predictable release cadence.
  • Deploy new features: With control over introducing changes to your bots, you can test new features and deploy them at your own pace.
  • Quality: With automated deployments from Automation 360 Cloud, you can use new packages that include critical bug and security fixes.
  • Nondisruptive access: You can update packages without disrupting your existing configurations.
  • Backward compatibility: You now have the option to safely update bots while still having the option to change back to a previous version of a package.

The following image shows the advantages of this lifecycle policy:

Image displaying the advantages of using packages in Automation 360

Control Room

Automation 360 leverages the latest best practices in developing and rolling out incremental software updates across all deployment models using a continuous development and deployment pipeline. Automation 360 Control Room software updates are released approximately every 3 months.

The updates are typically rolled out in the following order:

  • Community Edition and Cloud-Sandbox: These Cloud environments are automatically updated with prior notifications posted on the Automation 360 Cloud Service Status site. As a customer, you can use a Cloud-Sandbox Control Room environment to try out the next update at least 3 weeks before the main development (Dev), testing (Test or UAT), and production (Prod) Cloud environments are updated.
  • Automation 360 On-Premises Control Room: The On-Premises environment is released after the Community Edition and Cloud-Sandbox on the A-People Downloads page (Login required). Customers need to manually download the update from the downloads page and update their Control Room instances.
  • Automation 360 Cloud: The Cloud environments are updated automatically with prior notifications. These updates are typically deployed three to four weeks after the Cloud-Sandbox update. These Cloud updates are scheduled to occur during non-business hours and not close to the beginning or end of a month. Cloud update notifications are posted on the Automation 360 Cloud Service Status site 2 weeks in advance of the update.

Automation 360 software updates are cumulative of all new capabilities. As per our software update policy, bugs are fixed only in the latest version of the software update. Though we support n-2 releases (where n refers to the latest release) for On-Premises deployments, we recommend that On-Premises customer update to the latest release to benefit from the latest features and bug fixes.

Bot Agent updates

When a new version of Bot Agent is available, by default, the Bot Agent is deployed automatically across a customer's pool of devices without impacting existing bot functionality. However, Control Room administrators can disable this default update capability and choose to update the Bot Agent manually. In case of manual updates and in the event of a mandatory update, users will be notified that the Bot Agent must be updated and all bot execution on these devices will stop until the Bot Agent is updated.

For larger deployments where device pools are deployed using standard device Amazon Machine Images (AMI) on separate schedules, these updates will require coordination, change management processes, and approvals in the customer environment. Therefore, Automation 360 will support backward-compatible Bot Agent for a release every 6 months.

Starting with Automation 360 v.24 release, 4 Bot Agent updates will be released each year with 2 optional and 2 updates that might be declared mandatory. You can skip the optional update and update to the next mandatory Bot Agent update.

Our Q2 and Q4 releases will have optional Bot Agent updates and you can choose to skip the Bot Agent update. However, the Q1 and Q3 updates might have mandatory Bot Agent updates. We will notify customers 3 months in advance if a mandatory Bot Agent update is required with a Control Room release. For more information, see Bot Agent compatibility.

Note: We strongly recommend customers to update their Bot Agent instances every 6 months to ensure compatibility and benefit from the latest innovations.

Package updates

Starting with Automation 360 v.24 release, delivery of packages is developed to be separate from the main platform updates. This will help us respond quickly to changes and fixes required and provide the flexibility to deliver updates in packages, going forward.

With this capability, new packages and new package versions can now be automatically downloaded from Automation Anywhere Cloud when they are predictably released on a quarterly release cadence. These downloaded packages become the default package so that customers can start using these package versions on an ongoing basis as they become available.

This capability is enabled differently for Cloud and On-Premises Control Room instances, as listed in the following table:

Seamless package update capability Cloud Control Room On-Premises Control Room
Download packages from Automation Anywhere Cloud Enabled by default and cannot be disabled. Disabled by default and can be enabled.
Set downloaded package to default version Enabled by default and can be disabled. Enabled by default and can be disabled.
  • Cloud users: Automatic package download capability is now enabled across all Control Room instances in all regions at the same time.

    You can start using the latest packages on your current Control Room version before the Control Room update is made available in your region.

  • On-Premises users: This capability is disabled by default but it can be enabled by package administrators.

We recommend that bot developers always use the latest version of the packages because that version provides the latest innovations and all the code and security fixes from previous versions. However, administrators can change this default behavior at any time and roll out the packages to developers after verifying them. These new package versions are also backward-compatible with the existing platform version.

Note that this capability has no impact on existing bots, which continue to run unchanged. Bots that are developed with a particular package version will always continue to do so unless explicitly changed by the bot developer. This provides bot developers the flexibility to adopt new package versions when they are ready for it. Bot developers must explicitly edit the bots in the Bot editor view and use the new package version.

Support and deprecation policy for packages

Support and deprecation policy for packages aims to provide bot longevity and reduce overall maintenance efforts to keep bots updated. The design consideration is to minimize the bot changes required to keep the bot functioning.
Note: This policy is in effect from Control Room release v.23.
Package versions supported for a minimum of 2 years
Package versions that are released will continue to be supported for a minimum of 2 years after the release. Even after 2 years, a package version will continue to be supported unless it is deprecated.

Typically, a new version of the package will be made available if a package is deprecated. All issues and security fixes reported for the package will be fixed in the latest version, with no backporting.

You will be notified 3 months in advance when a package version is planned for deprecation. If there is a critical security vulnerability, we will make the best effort to send an advanced notification.

Packages version compatibility with Bot Agent and Control Room
Package versions and bots that use these versions will be compatible with all the Control Room and Bot Agent versions released within the 2 years after the package version release. Bots that use these supported package versions do not have to be configured to be compatible with the Control Room and Bot Agent versions.
Deprecation policy on package version
Package versions will not be depreciated within the 2 years after their release unless there is a critical security vulnerability that has to fixed. In such a case, a new package version will be made available with the fix.
Minimal bot changes
The package version support policy aim is to minimize the effort required to change existing bots and to keep them functioning.

Bots using a specific package version do not have to be updated to use the package versions if the existing package version is supported. However, we recommend that you use the latest version of the package when developing the bot to increase the longevity of the bot. The package versions used in a bot will have to be updated before they are deprecated for the bot to remain supported.

API deprecation policy

API deprecation indicates that an API is no longer recommended for use but is functional. Developers are encouraged to migrate to newer, supported versions of the API. The API will be available till the End of Life (EoL) date and the release version to enable a smooth transition.

API EoL (End of Life) indicates the date and the release version when the API will cease to function, and will no longer be available for use. Developers should have completed their migration to the newer, supported versions of the API before this date.

The following scenarios require deprecating APIs:

  • Security vulnerabilities: Older API versions contain known security vulnerabilities that have been fixed in newer versions.
  • Technical debt: Older API versions can be built on outdated technologies, approaches or frameworks that are no longer supported, making maintenance or enhancements difficult.
  • Performance: Older API versions are not optimized for modern use cases or increases in scale, leading to poor performance and slower response times.
  • User experience: Deprecated API versions contain confusing or redundant endpoints that can make it difficult for users to navigate.

From the deprecation announcement, an API is available for at least one year (four releases) to provide you with sufficient time to move to the newer version.

Note: There might be rare cases where an API needs to be immediately removed due to a critical issue such as a critical security vulnerability. In such cases, we will make every effort to communicate this change to you as soon as possible.

Bot lifecycle

The design assumption for bots is that the version of the package used in the bots is present in the Control Room that is used to run the bots. Before developers promote bots, we recommend that the developers verify that the package version used in the bots matches the package version in the higher environments.

When promoting bots to higher environments (for example, testing and production) that are on a lower software version, ensure that you include the dependent packages for bots. This will ensure that the target environment has all the package versions required by the bot.
Note: Some package versions will not be backward compatible with an earlier version of the Control Room or Bot Agent. Therefore, refrain from using such incompatible package versions during the Control Room environment update phase.

See also: Automatic package updates for On-Premises Control Room.