開発のライフサイクル

コードがサードパーティの Git リポジトリに存在する場合は、UiPath のオートメーションを開発者のマシンから運用環境まで追跡し、CLI コマンドを使用してリリース パイプラインが各段階で実行します。

このページでは、コード、履歴、コラボレーションがサードパーティの Git リポジトリに存在する、開発者のマシンから運用環境に移行する UiPath のオートメーションを描いています。以下の各ステップは、ダイアグラム内の番号付きの操作と一致します。すべてのステップで何が起こるかが説明され、ステップを適用すると、そのステップを実行する uip コマンドが表示されます。$CAPS のプレースホルダーは、ユーザーが指定する値です。

開発者のマシンから運用環境までの幸せなパス。ガードレールはプル要求に対して実行されるため、main はすでにガードレールを通過したマージに対してのみ移動し、そのマージによってリリース パイプラインがトリガーされます。青いボックスは UiPath 以外のシステム、オレンジ色のボックスは UiPath、灰色のボックスはランタイム環境です。破線矢印はイベントであり、人が実行したアクションではありません。ダイアグラムを選択してフルサイズで開きます。

前提条件

• オートメーション プロジェクトのソース管理リポジトリ。
• UiPath CLI を実行し、一時停止して手動承認を得られる継続的インテグレーションおよび継続的デリバリー (CI/CD) システム。
• 開発、テスト、運用用に分離された UiPath 環境。
• パイプラインが UiPath への認証に使用できる資格情報です。「 認証」をご覧ください。

ステップ バイ ステップの手順

01. ローカルに保存する

Studio によって開発者用ディスクにプロジェクトが書き込まれます。作業は進行中であり、他の誰にも表示されません。

uipコマンドはありません。これは Studio のアクションです。

02. 開発時のデバッグ

開発者は、Studio から Development テナントに対してプロジェクトを実行し、デバッグします。

uipコマンドはありません。開発者は Studio で作業します。

03. ブランチをプッシュし、プルリクエストを開く

変更は機能ブランチで実行され、開発者は に対してプル要求を開きます main。

uipコマンドはありません。これは Git 操作です。

04. プルリクエストが検証をトリガー

プル要求を開くと、CI システムが自動的にトリガーされます。誰も手で走り始めません。

uipコマンドはありません。これは Git リポジトリのイベントです。

05. コードを取得する

検証の実行では、pull request ヘッドがチェックアウトされます。

uipコマンドはありません。CI システムがコードをチェックアウトします。

06. 静的解析とその他のガードレール

ワークフロー アナライザーとガバナンス ルールは、プロジェクトに対して実行されます。違反は、 main が変更される前に実行に失敗します。ソリューションの場合は、ソリューションに含まれるプロジェクトごとに 1 回ずつアナライザーを実行します。

uip rpa analyze ./my-solution/MyProject \
  --governance-file-path ./governance.json

「 uip rpa analyze」をご覧ください。

07. プルリクエストで報告されたチェック

結果は、pull request の状態チェックとして表示されます。ブランチ保護では、チェックがアドバイザリではなくブロックになります。

uipコマンドはありません。CI システムは、結果を Git リポジトリに報告します。

08. 承認されたPRをマージする

レビュー担当者が承認してチェックに合格し、プル要求が mainにマージされます。

uipコマンドはありません。これは Git 操作です。

09. メインにプッシュするとパイプラインがトリガーされます

main でコミットを結合すると、リリース パイプラインが自動的にトリガーされます。

uipコマンドはありません。これは Git リポジトリのイベントです。

10. コードを取得する

リリースの実行では、マージ コミット時に main がチェックアウトされます。

uipコマンドはありません。CI システムがコードをチェックアウトします。

11. ステージング/ユーザー受け入れテスト (UAT) 環境へのデプロイ

リリース パイプラインによってソリューションがパッケージ化され、ステージング/UAT テナントにパブリッシュされて、そこにデプロイされます。シーケンスには個別のビルド ステップがないため、このステップでパッキングが行われます。デプロイ前に、パイプラインはデプロイ設定を編集し、重複するリソースを作成するのではなく、テナントに既存のリソースを再利用します。

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$UAT_TENANT"

uip solution pack ./my-solution ./dist \
  --name my-solution --version "$BUILD_VERSION"

uip solution publish "./dist/my-solution_${BUILD_VERSION}.zip"

uip solution deploy config get my-solution \
  --package-version "$BUILD_VERSION" -d ./deploy-config.uat.json
uip solution deploy config link ./deploy-config.uat.json "MyConnection" \
  --name "UatCrmConnection" --folder-path "Shared"
uip solution deploy config set ./deploy-config.uat.json \
  --all conflictFixingAction UseExisting

uip solution deploy run --name "my-solution-uat-${GIT_SHA}" \
  --package-name my-solution --package-version "$BUILD_VERSION" \
  --folder-name MySolution --parent-folder-path Shared \
  --config-file ./deploy-config.uat.json

宣言したリソースを既存のリソースにリンクする方法について詳しくは、「 既存の Orchestrator リソースを再利用する」をご覧ください。

12. テストを実行する

パイプラインは、デプロイされたソリューションに対してテスト セットをステージング/UAT で実行し、実行が完了するまで待機してレポートを取得します。「 パイプラインでテストを実行する」をご覧ください。

uip tm testsets run --test-set-key "$TEST_SET_KEY"
uip tm wait --execution-id "$EXECUTION_ID"
uip tm report get --execution-id "$EXECUTION_ID"

13. 検証のための通知

パイプラインは、リリースをステージング/UAT で検証する準備ができたことをビジネス ユーザーに伝えます。

uipコマンドはありません。CI システムの承認ゲートは、単独でレビュー担当者に通知します。

14. ビジネスの検証

ビジネス ユーザーは、ステージング/UAT テナントでソリューションをテストします。その間、パイプラインの実行は承認ゲートで一時停止し、回答をポーリングしません。

uipコマンドはありません。これは人間のステップです。

15. ビジネス ユーザーの承認

ビジネス ユーザーがリリースを承認し、パイプラインを続行できます。

uipコマンドはありません。承認者は、シェルではなく CI システム内で行動します。

16. パッケージをダウンロード

UAT テナントは成果物フィードとしても機能します。ソースから再度梱包するのではなく、テストに合格した正確なパッケージを取ります。

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$UAT_TENANT"
uip solution packages download my-solution "$BUILD_VERSION" -d ./artifacts/

17. 運用環境にデプロイする

パイプラインによって、手順 11 と同じデプロイの設定方法を使用して、パッケージが Production テナントにパブリッシュされてデプロイされます。手順 16 でダウンロードしたのと同じファイルをパブリッシュします。二度と荷造りしないでください。

uip login --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET --tenant "$PROD_TENANT"

uip solution publish "./artifacts/my-solution_${BUILD_VERSION}.zip"

uip solution deploy config get my-solution \
  --package-version "$BUILD_VERSION" -d ./deploy-config.prod.json
uip solution deploy config link ./deploy-config.prod.json "MyConnection" \
  --name "ProdCrmConnection" --folder-path "Shared"
uip solution deploy config set ./deploy-config.prod.json \
  --all conflictFixingAction UseExisting

uip solution deploy run --name "my-solution-prod-${GIT_SHA}" \
  --package-name my-solution --package-version "$BUILD_VERSION" \
  --folder-name MySolution --parent-folder-path Shared \
  --config-file ./deploy-config.prod.json

宣言したリソースを既存のリソースにリンクする方法について詳しくは、「 既存の Orchestrator リソースを再利用する」をご覧ください。

ロールバックするには、 で同じ deploy run コマンドを実行します --package-version "$PREVIOUS_VERSION"。

参照

• ソリューションをパッケージ化してパブリッシュする
• パイプラインでテストを実行する
• CI から Orchestrator にデプロイする
• CI/CD レシピ