パッケージの管理方法について

概要

UiPath Studioで開発するプロセスプロジェクトとライブラリプロジェクトにおいては、パッケージの依存関係を適切に管理する必要があります。さもないと、プロセスが期待どおりに動作しないなどの不具合の要因となり得ます。一方で、パッケージの依存関係をよく理解していれば、UiPath 製品バージョンアップ時に既存プロセスが動作しなくなるリスクの評価や、プロジェクトにおけるライブラリのバージョンアップの要否判断などがうまく行えるようになります。 そこで、本記事では Studio プロジェクトにおけるパッケージの依存関係の管理に関する指針を示します。

結論

本稿で紹介するパッケージファイルとその依存関係の管理に関する指針は、下記のとおりです。

開発時のパッケージ管理の指針

• 不要な依存は削除すべし

• プロセスプロジェクトならランタイムルールに「ストリクト」を指定すべし

• ライブラリプロジェクトならランタイムルールに「最も低い適用可能なバージョン」を指定すべし

運用時のパッケージ管理の指針

• 既存のプロセスの依存は、その必要がない限りは更新することを避けるべし

• 古いバージョンのパッケージも利用可能のまま残すべし

次節より、これらの技術的な背景について説明します。 

前提知識

Studio で作成できるプロジェクトの種別

Studioでは、プロセスプロジェクトとライブラリプロジェクトの2種類のプロジェクトを作成できます。どちらのプロジェクトも、パブリッシュすることでパッケージファイル（.nupkg）が生成されます。どちらのプロジェクトにも、ほかのライブラリパッケージやアクティビティパッケージへの依存を追加できます。これにより、追加したパッケージに含まれるアクティビティが利用できるようになります。

プロセスプロジェクト

パブリッシュの操作によって、プロセスパッケージを生成するプロジェクトです。プロセスパッケージはエントリポイントを含んでおり、Robotで実行することができます。ロボットで業務を自動化するときには、プロセスプロジェクトを作成することになります。 

ライブラリプロジェクト

パブリッシュの操作によって、ライブラリパッケージを生成するプロジェクトです。このプロジェクトのワークフローファイルのそれぞれはカスタムアクティビティになり、生成されたライブラリパッケージに含まれます。なおライブラリパッケージはエントリポイントを含んでいないため、単体では Robot で実行することができません。ライブラリは、ほかのプロセスもしくはライブラリから呼び出して使うことを意図して作成されます。なおライブラリのバージョン番号の採番方法については、下記を参考にしてください。

参考情報: セマンティックバージョニング

ランタイムルールについて

プロセス実行開始時に、呼び出すパッケージのバージョンを決めることを「依存先パッケージのバージョンを解決する」といいます。ランタイムルールとは、このときに適用されるルールです。このルールに則って、パッケージのバージョンが解決されます。利用できるランタイムルールには「ストリクト」と「最も低い適用可能なバージョン」のふたつがあります。このどちらかを、プロジェクトに依存を追加したパッケージごとに指定しなければなりません。

ストリクト

設計時に依存先として指定したパッケージのバージョンについて、実行時にはそれと同じバージョンのパッケージだけを使うルールです。ロボットがこのプロセスを実行開始するときに、指定のバージョンのパッケージが見つからず利用できないときは、このプロセスの実行開始に失敗します。これにより、プロセスの設計時と同じ動作が、プロセスの実行時にも期待できるので、とても安全なルールです。

最も低い適用可能なバージョン

設計時に依存先として指定したパッケージのバージョンについて、実行時にはそれと同じか新しいバージョンのパッケージを使うルールです。ロボットがこのプロセスを実行開始するときに、指定のバージョンのパッケージが見つからなくても、それより新しいバージョンのパッケージがあればそれを使ってプロセスを実行します。この場合には、可能な限り低い（指定のバージョンに近い）バージョンのパッケージを使います。 

開発時のパッケージ管理の指針

1. 不要な依存は削除すべし

プロジェクトに必要となるパッケージへの依存だけを追加しましょう。たとえば、PDF の操作をしないプロジェクトには、PDF パッケージ（UiPath.PDF.Activities.###.nupkg）への依存を追加する必要はありません。不要な依存を除去しておけば、より短い時間でプロセスを実行開始できます。また、このプロジェクトに追加されたほかのパッケージの依存とバージョンが競合してしまうリスクを減らすことができます。このリスクについては3番目の指針において後述します。

2. プロセスプロジェクトならランタイムルールに「ストリクト」を指定すべし

プロセスを安定して動作させるには、ランタイムルールに「ストリクト」を指定して同じバージョンのパッケージを使い続けることです。アクティビティパッケージやライブラリパッケージは、バグの修正やパフォーマンスの向上のために継続してバージョンアップされます。

しかし、このバージョンアップに起因して、既存のプロセスが正常に動作しなくなることがあります。ランタイムルールに「ストリクト」を指定しておけば、同じバージョンのパッケージを使い続けることができ、パッケージのバージョンアップに起因する副作用の影響を受けることはありません。こうしておけば、たとえ UiPath 製品をバージョンアップしても、既存のプロセスが動かなくなることはありません！ ただし、「ストリクト」のランタイムルールは Studio v18.3.3 から利用可能であることにご留意ください。

なお「ストリクト」とした場合には、設計時に指定したバージョンのパッケージが実行環境で利用できない場合はプロセスの実行開始に失敗します。このため、当該のバージョンのパッケージが利用可能となるようにご配慮ください。この方法は本稿の最後のセクションで説明します。

3. ライブラリプロジェクトならランタイムルールに「最も低い適用可能なバージョン」を指定すべし

あるプロセスが複数のライブラリに依存するとします。これらのライブラリは、また別のパッケージに依存することができます。このとき、プロセスが依存する複数のライブラリのそれぞれが、同じパッケージの別のバージョンにストリクトで依存していると、このプロセスはこのパッケージのバージョンを解決できず、実行できなくなってしまいます。このような状況を避けるため、ライブラリに別のパッケージの依存を追加するときには「最も低い適用可能なバージョン」のランタイムルールを指定するようにしてください。弊社外のサイトの情報で恐縮ですが、バージョンを解決できない状況については下記のドキュメントをご参照ください。

ご参考情報: NuGet でのパッケージ依存関係の解決方法

しかし、「ストリクト」を指定しないということは、前節で説明した懸念が生じるでしょう。つまり、このライブラリが実行時に呼び出されるとき、このライブラリが依存するパッケージは、どのバージョンに解決されるかのか設計時にはわかりません。すると、前節で説明した事情から、このライブラリが期待どおり動作することを担保できません。しかし、このライブラリをより多くのプロセスプロジェクトで利用可能にするためには、これは受け入れる必要があるリスクです。というのは、プロセスを実行するとき、依存するパッケージについて複数のバージョンを同時にロードすることはできないからです。そのため、あるパッケージに対しては、利用可能なバージョンのどれかひとつに解決しなければなりません。

このようなリスクを少なくするためには、ライブラリを作成するときには、依存するパッケージをなるべく少なくする（本稿 1. の指針に従う）ことがより重要であることがわかります。また、依存先のパッケージに大きな変更をともなうバージョンアップがあれば、それに追随する形で新しいバージョンのライブラリをリリースする必要もあるでしょう。ライブラリの提供者は、そのライブラリをほかの開発者たちに心地よく使ってもらえるように、本稿で示したガイドラインを心に留め置いて頂ければ幸いです。 

運用時のパッケージ管理の指針

4. 既存のプロセスの依存は、その必要がない限りは更新することを避けるべし

Excel や Mail などのアクティビティパッケージは、継続して新しいバージョンがリリースされます。開発者が作成したライブラリパッケージも、継続して新しいバージョンをリリースしていく必要があるでしょう。これにはバグの修正や新機能の追加、パフォーマンスの向上などのほか、前述のように依存先パッケージの更新に追随するためなどの事情があります。しかし、これらのパッケージに依存するプロセスでは、その更新内容を取り込むべき動機がない限りは、その依存を更新するべきではありません。この技術的な背景を説明します。

既存のプロセスは、設計時に指定したバージョンのパッケージを使い続けるのが安全

新しいバージョンのパッケージがリリースされても、既存のプロセスは古いバージョンのパッケージに依存したままとすべきです。新しいパッケージに含まれる新機能やバグ修正などを取り込む必要がない限り、既存のプロセスは同じバージョンのパッケージを使い続けるべきです。これは、安定して動作しているプロセスが、変わらず同じように動作できるようにするための重要な戦略です。 

依存先のパッケージバージョンを新しくすることにより、生じるリスクについて

プロセスが依存するアクティビティパッケージのバージョンを更新すると、そのパッケージ自体の振る舞いが変わってしまうことに起因して、プロセスが期待どおり動作しなくなる可能性があります。あるいは、その（プロセスから見て子の）アクティビティパッケージが依存する別の（プロセスから見て孫の）パッケージのバージョンが更新されていれば、このプロセスはその孫パッケージをの振る舞いが変わっている可能性もあります。 子アクティビティパッケージは以前のバージョンと同様に動作できるとしても、その孫パッケージに依存する別のパッケージの動作に影響があるかもしれません。あるいは、プロセスが依存するほかのパッケージとバージョンが衝突することでバージョンを解決できなくなり、実行そのものができなくなる危険もあります。

5. 古いバージョンのパッケージも利用可能のまま残すべし

上記 4. の指針で述べたように、（繰り返しになりますが）その必要がない限りは安定して動作しているプロセスを修正するべきではありません。プロセスの依存関係も更新するべきではありません。このことは、古いバージョンのパッケージも、すべて利用可能なままロボットの実行環境に残しておくべきことを示唆します。もし誤って古いパッケージを失うことがあれば、それはそのまま既存のプロセスが利用できなくなってしまうことになります。その場合には、その古いプロセスのプロジェクトを Studio で開いて、依存先のパッケージを新しい（利用可能な）バージョンを使うように更新してパブリッシュし、それが期待どおり動作するかテストすることではじめて、このプロセスを元通り利用できる状態に回復させることができます。これまでに運用環境にリリースされた任意のバージョンのパッケージをそのまま利用可能な状態に維持することは、管理者が果たすべき重要な責務です。

付録: パッケージを、プロセスの実行環境（ロボット端末）で利用可能にする方法

前述のとおり、ランタイムルールを「ストリクト」とした場合には、そこで指定したバージョンのパッケージが実行環境（ロボット端末）で利用可能になっていなければ、そのプロセスの実行開始に失敗します。そのため、当該のバージョンのパッケージを実行環境で利用可能となるように配慮する必要があります。これには、次の方法があります。

インターネット上にある、オフィシャルフィードからダウンロードする

MyGet のオフィシャルフィードには、これまでに UiPath がリリースしたすべてのバージョンのパッケージが配置されています。これらのパッケージは、必要なものをロボットが自動でダウンロードします。このため、ロボット端末がインターネットに接続されていれば、特に何をする必要もなく、過去のバージョンのパッケージが利用可能となります。

接続した Orchestrator のフィードに、当該のパッケージを配置する

Orchestrator は NuGet サーバーの機能が内包されており、アクティビティパッケージやライブラリパッケージを管理できます。そこで、当該のバージョンのパッケージを Orchestrator のフィードに配置しておくことができます。組織にインストールされた実績のある Studio バージョンに同梱されている、すべてのバージョンのパッケージを配置しておくことをお勧めします。Orchestrator に接続されている Robot 端末は、Orchestrator のフィードを検索し、必要なパッケージを自動でダウンロードします。

ロボット端末のローカルフィードに、当該のパッケージを配置する

もしもロボット端末がインターネットと Orchestrator のどちらにも接続されていないなら、当該のバージョンのパッケージをこの端末のローカルフィードに配置しておく必要があります。既定のローカルフィードは C:\Program Files (x86)\UiPath\Studio\Packages です。ここにパッケージをコピーしてください。組織にインストールされた実績のある Studio バージョンに同梱されている、すべてのバージョンのパッケージをコピーしておくことをお勧めします。このとき、この端末の管理者権限が必要となることにご注意ください。 なお、ロボット端末がインターネットや Orchestrator に接続されている場合でも、当該のパッケージがローカルフィードにある方が処理速度や可用性の面で有利なので、補助的に活用してください。