Automation 360 ソフトウェア ライフサイクル ポリシー

Automation Anywhere ソフトウェア ライフサイクル ポリシーは、イノベーションおよび機能強化を迅速に提供することを目的としています。 このポリシーを通じて、お客様に予測可能性、品質、そして重要なことに、最新のイノベーションと機能強化への中断のないアクセスを提供するため、お客様はいつ、どのようにこれらの機能強化を導入するかをコントロールできます。

注: 相違が明示されていない限り、このページに記載されているポリシーは、Automation 360 CloudOn-Premisesの両方のデプロイに適用されます。

概要

ソフトウェア ライフサイクル ポリシーでは、Control RoomBot Agentpackagesで、変更管理を支援しながら、機能強化による最新のソフトウェア更新を提供します。

当社のポリシーは、お客様の体験を向上させるために、機能、バグ修正、その他の機能強化へのより迅速なアクセスを提供することを目的としています。
  • 予測可能性: 頻繁で定期的なデプロイ サイクルにより、予測されたリリース頻度で、以前より早く、新しい強化されたpackagesにアクセスできます。
  • 新機能のデプロイ: bots への変更の導入をコントロールすることで、新機能をテストし、お客様のペースでデプロイできます。
  • 品質: Automation 360 Cloudからの自動デプロイによって、重要なバグおよびセキュリティの修正を含む新しいpackagesを使用できます。
  • 中断のないアクセス: 既存の構成を中断することなく、パッケージを更新できます。
  • 下位互換性: 変更内容を以前のバージョンのbotsに戻すオプションを引き続き保持しながら、package を安全に更新するオプションが追加されました。

以下の画像は、このライフサイクル ポリシーのメリットを示しています。

Automation 360 でパッケージを使用するメリットを表示した画像

Control Room

Automation 360 は、継続的な開発と展開パイプラインを使用して、すべての展開モデルにわたって段階的なソフトウェア更新を開発および展開する際の最新のベストプラクティスを活用しています。 Automation 360 Control Room ソフトウェア更新は、約3か月ごとにリリースされます。

更新は通常、次の順序で展開されます。

  • Community EditionおよびCloud サンドボックス: これらの Cloud 環境は、Automation 360 Cloud Service Status siteに投稿された以前の通知で自動的に更新されます。 お客様は、Cloud サンドボックス Control Room 環境を使用して、メインの 開発 (Dev)、テスト (Test または UAT)、および本番 (Prod) Cloud 環境が更新される 3 週間前に、次回更新分を試すことができます。
  • Automation 360 On-Premises Control Room: On-Premises 環境は、Community EditionCloud および A-People Downloads page (Login required) サンドボックスの後にリリースされます。 お客様は、手動でダウンロード ページから更新をダウンロードし、Control Room インスタンスを更新する必要があります。
  • Automation 360 Cloud: Cloud 環境は、以前の通知で自動的に更新されます。 これらの更新は通常、Cloud サンドボックス更新の 3 ~ 4 週間後にデプロイされます。 これらのクラウド更新は、月初や月末に近い時間帯を除いた営業時間外にスケジュール設定されています。Cloud アップデート通知は、アップデートのAutomation 360 Cloud Service Status site 2週間前に掲載されます。

Automation 360 ソフトウェア更新は、すべての新機能の累積です。 当社のソフトウェア更新ポリシーに従って、バグは最新バージョンのソフトウェア更新でのみ修正されます。 On-Premises デプロイについては n-2 リリース (n は最新リリースを指します) をサポートしていますが、On-Premises のお客様には、最新の機能およびバグ修正のメリットを得るために、最新リリースに更新することをお勧めします。

Bot Agentの更新

新バージョンの Bot Agentが利用可能になると、デフォルトでは、Bot Agentは、既存の bot 機能に影響を与えることなく、お客様のデバイスのプール全体に自動的にデプロイされます。 ただし、Control Room 管理者は、このデフォルトの更新機能を無効にして、手動で Bot Agentを更新することができます。 手動更新で必須の更新の場合は、ユーザーに Bot Agentを更新する必要があることが通知され、botが更新されるまで、これらのデバイスのすべての Bot Agent の実行が停止します。

標準的なデバイス Amazon Machine Image (AMI) を使用してデバイス プールを個別のスケジュールでデプロイする比較的大規模なデプロイの場合、これらの更新には、調整、変更管理プロセス、お客様の環境での承認が必要になります。 そのため、Automation 360 は、6 か月ごとのリリースに対応する下位互換性のある Bot Agentをサポートします。

Automation 360v.24 リリース以降、4 Bot Agentつの更新が毎年リリースされる予定です。2 つの任意の更新と、2つの更新を含む、必須と宣言される可能性があります。 任意の更新をスキップして、次回の必須の Bot Agentの更新へ更新することができます。

第 2 四半期と第 4 四半期のリリースは、任意の Bot Agent更新となるため、Bot Agent更新をスキップすることができます。 ただし、第 1 四半期と第 3 四半期の更新は、必須の Bot Agent更新が含まれる場合があります。 Bot Agent リリースで、必須の Control Room更新が必要な場合は、3 か月前にお客様に通知されます。 詳細については、「Bot Agent compatibility」を参照してください。

注: 互換性を確保し、最新のイノベーションのメリットを得るために、6 か月ごとに Bot Agent インスタンスを更新することを強くお勧めします。

Packageの更新

Automation 360 v.24 リリース以降、packagesの配信は、メイン プラットフォームの更新とは別に開発されます。 これにより、今後は、必要な変更と修正に迅速に対応し、packagesで更新を柔軟に配信できるようになります。

この機能により、四半期ごとのリリース頻度で予想どおリにリリースされたときに、新しいpackagesと新しいpackage バージョンを Automation Anywhere Cloudから自動的にダウンロードできるようになりました。 これらのダウンロードされたpackagesは、デフォルトのpackageとなるため、お客様は、これらのpackage バージョンが使用可能になったときに、継続的に使用し始めることができます。

この機能は、以下の表にリストするとおり、CloudOn-Premises Control Room のインスタンスでは、それぞれ異なる方法で有効化されます。

シームレスなpackageの更新機能 Cloud Control Room On-Premises Control Room
packages Automation AnywhereからのCloudのダウンロード デフォルトで有効であり、無効にすることはできません。 デフォルトでは無効でありますが、有効にすることができます。
ダウンロードしたpackageをデフォルト バージョンに設定 デフォルトでは有効でありますが、無効にすることができます。 デフォルトでは有効でありますが、無効にすることができます。
  • Cloud ユーザー: 自動package ダウンロード機能は、すべての領域のすべての Control Room インスタンスで同時に有効にすることができるようになりました。

    packages の更新がお客様の領域で入手可能になる前に、現在の Control Room バージョンで最新のControl Roomを使用し始めることができます。

  • On-Premises ユーザー: この機能はデフォルトでは無効ですが、package管理者によって有効にすることができます。

最新バージョンは、最新のイノベーションとすべてのコード、以前のバージョンからのセキュリティ修正を提供しているため、bot 開発者は、常にpackagesの最新バージョンを使用することをお勧めします。 ただし、管理者はいつでもこのデフォルトの動作を変更し、packagesを検証した後に、それらを開発者に展開することができます。 この新しい package バージョンは、既存のプラットフォーム バージョンと下位互換性もあります。

この機能は、既存の bots に影響を与えず、変更されずに実行され続けることに注意してください。特定の package バージョンで開発された Bots は、bot 開発者によって明示的に変更されない限り、常にそうし続けます。 これは bot の開発者に、新しい package バージョンを準備ができたときに採用する柔軟性を提供します。Bot の開発者は、Bot editor ビューで bots を明示的に編集し、新しい package バージョンを使用する必要があります。

packagesのサポートと非推奨のポリシー

packagesのサポートと非推奨のポリシーは、bot の有効期間を延長し、bots を最新の状態に保つためのメンテナンス労力全体を削減することを目的としています。 設計の考慮事項は、Bot の機能を維持するために必要とされる bot の変更を最小限にすることです。
注: このポリシーは、Control Room リリース v.23 から有効となります。
2 年以上サポートされるPackage バージョン
リリースされたPackage バージョンは、リリース後 2 年以上はサポートが継続されます。 2 年後でも、package バージョンは、非推奨にならない限り、サポートが継続されます。

通常、packageが非推奨になった場合は、新しいバージョンのpackageが使用可能になります。 packageについて報告されたすべての問題およびセキュリティ修正は、バックポートされることなく、最新バージョンで修正されます。

package バージョンの非推奨化が予定された場合は、3 か月前にお客様に通知されます。 重大なセキュリティの脆弱性がある場合は、事前に通知するための最大限の努力をします。

Packages バージョンと Bot Agentおよび Control Room との互換性
パッケージのバージョンと bots は、Control Room バージョンのリリース後 2 年以内にリリースされたすべての Bot Agent および package バージョンと互換性があります。これらのサポートされているパッケージバージョンを使用する Bots は、Control Room および Bot Agent バージョンと互換性を持つように構成する必要はありません。
package バージョンの非推奨ポリシー
重要なセキュリティの脆弱性を修正する必要がある場合を除き、Package バージョンがそれらのリリース後 2 年以内に非推奨になることはありません。 修正が必要な場合は、修正された新しいpackage バージョンが利用可能になります。
最小限の bot の変更
package バージョン サポート ポリシーの目的は、既存の bots を変更し、それらの機能を維持するために必要な労力を最小限にすることです。

特定のBots バージョンを使用する package は、既存のpackage バージョンがサポートされている場合、そのpackage バージョンを使用するために更新する必要はありません。 ただし、package の有効期間を延長するために bot を開発する場合は、bot の最新バージョンを使用することをお勧めします。 package 内で使用されるbot バージョンは、bot がサポートされた状態を維持するために、非推奨になる前に更新する必要があります。

API 廃止ポリシー

API の非推奨 は、API の使用が今では推奨されていないものの、機能していることを示します。 API の対応しているより新しいバージョンに移行することが奨励されます。 APIは、スムーズな移行を可能にするために、エンドオブライフ(EoL)日およびリリースバージョンまで利用可能です。

API EoL (サポート終了) は、API が機能しなくなり、使用できなくなる日付とリリースバージョンを示します。 開発者は、この日付までにサポートされている最新バージョンの API への移行を完了している必要があります。

次のシナリオではAPIの非推奨化が必要になるかもしれません。

  • セキュリティ脆弱性: 古いAPIバージョンには、最新のバージョンで修正された既知のセキュリティ脆弱性が含まれています。
  • 技術的負債 古いAPIバージョンは、もはやサポートされていない古い技術、アプローチ、またはフレームワークに基づいて構築される可能性があり、メンテナンスや拡張が困難になります。
  • パフォーマンス: 古いAPIバージョンは、現代の事例や規模の拡大に最適化されておらず、パフォーマンスの低下や応答時間の遅延を引き起こします。
  • ユーザーエクスペリエンス: 廃止されたAPIバージョンには、ユーザーがナビゲートするのが難しくなる混乱したまたは冗長なエンドポイントが含まれています。

API は最低2年間サポートされます。 非推奨の発表から2年後、API は少なくともさらに1年間(4回のリリース)利用可能であり、新しいバージョンに移行するための十分な時間を提供します。

注: 上記のポリシーは、公開 API のセキュリティ脆弱性による非推奨には適用されません。 そのような場合、リスクを軽減するために即時の対応が必要でありま。当社はできるだけ早くこの変更をお知らせするよう努めます。

Bot のライフサイクル

bots の設計の前提条件は、package で使用されているbotsのバージョンが、Control Room を実行するために使用されている bots に存在していることです。 開発者は bots を昇格させる前に、package で使用されているbots バージョンと上位の環境のpackage バージョンが一致していることを確認することをお勧めします。

下位のソフトウェア バージョン上の bots を上位の環境に昇格させる場合 (たとえば、テスト環境から本番環境) は、packages の依存botsが含まれていることを確認します。 これによって、ターゲット環境には package が必要とするすべてのbot バージョンが確実に含まれます。
注: 一部のpackage バージョンは、Control Room または Bot Agentの以前のバージョンとの下位互換性を備えていません。 そのため、package 環境の更新段階では、このような非互換のControl Room バージョンの使用は避けてください。

次のページも参照してください: オンプレミス Control Room の自動パッケージ更新.