本番ビルド・ジョブの作成および構成

Oracle Cloud ApplicationのPRODインスタンスに拡張をデプロイするには、「拡張ライフサイクルの管理」ページを使用するか、CI/CDパイプラインを設定できます。パイプラインを使用する場合は、いくつかのパッケージ・ジョブおよびデプロイメント・ジョブを設定する必要があります。

構成を本番Oracle Cloud Applicationインスタンスに移行します。手順については、構成ライフ・サイクルの概要およびアプリケーションの構成と拡張の移行の概要を参照してください。
拡張機能をパッケージ化するビルド・ジョブを作成します。手順は、Production Packaging Buildジョブの作成を参照してください。
拡張を本番インスタンスにデプロイするビルド・ジョブを作成します。手順については、「本番デプロイメント・ビルド・ジョブの作成」を参照してください。
(オプション)本番ビルド・ジョブを表示または編集したり、そのビルドを実行できるユーザーを制限します。手順は、「ジョブ保護設定の構成」を参照してください。
パッケージングおよびデプロイメント・ジョブを連続して実行するようにパイプラインを構成します。手順は、本番パイプラインの作成および構成を参照してください。
本番パイプラインを実行して拡張をパッケージ化し、それを本番インスタンスにデプロイします。手順は、本番パイプラインの実行を参照してください。

ビルド・ジョブおよびパイプラインを構成する前に

ビルド・ジョブおよびパイプラインを構成および実行する前に知っておく必要がある事項を次に示します。

ソースとターゲットのインスタンスが同じリリースであること、および同じ標準および1回かぎりのパッチが同じ両方の環境に適用されていることを確認してください。
visual-application.jsonで定義されたアプリケーションのバージョンを上書きするように開発パッケージング・ジョブを構成した場合は、新しいバージョンを取得します。同じバージョンを使用するように本番のパッケージング・ジョブを構成します。
かわりに、VB Studioでビルド・ジョブおよびパイプラインを作成して有効にできます。拡張機能の設定エディタの「ビルドおよびパブリッシュ」で、本番ブランチを選択し、「CI/CDパイプラインの作成」をクリックします。その後、必要に応じて新しく作成したビルドジョブを変更できます。たとえば、デプロイメント・ジョブでは、デプロイメント・ターゲットは常にワークスペースに関連付けられた環境であるため、ターゲット・インスタンスを本番インスタンスに変更する必要があります。

Production Packaging Buildジョブの作成

パッケージ・ジョブは、本番インスタンスにデプロイする準備ができた拡張アーティファクトを生成します。

左側のナビゲータで、「ビルド」をクリックします。
「ジョブ」タブで、「+ジョブの作成」をクリックします。
「新規ジョブ」ダイアログ・ボックスの「名前」に、一意の名前を入力します。
「説明」に、ジョブの説明を入力します。
「テンプレート」で、「Visual Builderのシステム・デフォルトOL7」テンプレートを選択します。
「作成」をクリックします。
「構成」 をクリックします。
「Git」タブをクリックします。
「Gitの追加」リストから、「Git」を選択します。
「リポジトリ」で、Gitリポジトリをクリックします。「ブランチまたはタグ」で、本番ブランチを選択します。
「ステップ」タブをクリックします。
「ステップの追加」から、「アプリケーション拡張」を選択し、「パッケージ」を選択します。
デフォルトでは、パッケージ化ステップによって、ビルドを実行する前にアプリケーションのソース・コードが最小化されます。ソース・ファイルを最小化しない場合は、「拡張機能の最適化」チェック・ボックスの選択を解除します。

最小化とは、ソース・コードから不要な文字(空白、改行、コメントなど)を削除し、ファイルのサイズを小さくして、ファイルの転送で消費される帯域幅と記憶域を少なくするプロセスです。

ノート

「拡張の最適化」チェック・ボックスの選択を解除すると、次の警告が表示されます: 「最適化」が選択されていません。最適化なしでパッケージングを行うと、パフォーマンスの問題が発生する可能性があるため、デバッグ中またはトラブルシューティング中を除き、最適化なしでパッケージングを行うのは避けてください。
(オプション)アーティファクト・ファイルの名前を変更する場合は、「アーティファクトのビルド」に新しい名前を入力します。ベスト・プラクティスは、デフォルトのextension.vxを保持することです。ただし、変更できます。
変更する場合は、「アーカイブするファイル」フィールド(ステップ18)およびデプロイメント・ジョブの「アーティファクトの構築」フィールドでも新しい名前を使用する必要があります。「本番デプロイメント・ビルド・ジョブの作成」を参照してください。
(オプション)visual-application.jsonファイルに定義されている拡張機能のデフォルトのバージョンを上書きするように開発パッケージング・ジョブを構成した場合は、「拡張バージョン」に同じバージョンを指定します。
「ジョブ構成」ウィンドウの「作成後」タブをクリックします。
「ビルド・アクション後に追加」から、「アーティファクト・アーカイバ」を選択します。
「アーカイブするファイル」に、ビルド・アーティファクト名を入力します。

ワイルド・キャラクタを使用できます。たとえば、*.vxです。アプリケーション拡張ビルド・アーティファクトのパスが含まれていることを確認してください。

デプロイメント・ジョブの「アーティファクトのコピー」の「ターゲット・ディレクトリ」フィールドに値を入力した場合、ワークスペースのサブディレクトリとみなされ、「アーティファクトの構築」フィールドのアーティファクトのパスの一部である必要があります。
ビルドの古いアーティファクトを破棄する場合は、「設定」をクリックします。「一般」タブで、「古いビルドの破棄」チェック・ボックスを選択し、破棄オプションを指定します。
「保存」をクリックします。

本番デプロイメント・ビルド・ジョブの作成

デプロイメント・ジョブは、パッケージング・ジョブで生成された拡張のアーティファクトをOracle Cloudアプリケーションの本番インスタンスにデプロイします。ジョブを作成する前に、VB StudioがOracle CloudアプリケーションのPRODインスタンスへのアクセスに使用できる資格証明があることを確認してください。

左側のナビゲータで、「ビルド」をクリックします。
「ジョブ」タブで、「+ジョブの作成」をクリックします。
「新規ジョブ」ダイアログ・ボックスの「名前」に、一意の名前を入力します。
「説明」に、ジョブの説明を入力します。
「テンプレート」で、「Visual Builderのシステム・デフォルトOL7」テンプレートを選択します。
「作成」をクリックします。
「構成」 をクリックします。
「作成前」タブをクリックします。
「ビルド前に追加アクション」から、「アーティファクトのコピー」を選択します。
「ジョブ: 自」で、拡張機能のアーティファクトを生成したパッケージング・ジョブを選択します。
「作成中」で、次のいずれかを選択します:
- 最終成功ビルド(デフォルト)
- 最後の永久に保持するビルド
- このパイプライン・インスタンスのアップストリーム・ビルド
- パーマリンクで指定
- 特定のビルド
- ビルド・パラメータで指定
選択内容に応じて、使用するパーマリンク、ビルドまたはビルド・パラメータを選択するように求められる場合があります。
他のフィールドはデフォルトまたは空の値のままにします。
「ステップ」タブをクリックします。
「ステップの追加」から、「アプリケーション拡張」を選択し、「デプロイ」を選択します。

この図は、部分的に入力されたビルド・ジョブのデプロイ・ページを示しています。

図oracle-deploy-build-step.pngの説明
「ターゲット・インスタンス」で、Oracle Cloudアプリケーションの本番インスタンスを含む環境を選択します。
「認可」セクションで、このビルド・ステップを実行する認可タイプを指定します。「OAuthを使用」がデフォルトで選択されていると、Authorization is requiredメッセージが表示され、このビルド・ステップでは、環境のOracle Cloud Applicationsインスタンスに対するOAuthリクエストを処理するための1回かぎりの認可が必要であることを示します。「認可」をクリックして、Oracle Cloud Applicationsインスタンスにアクセスするための資格証明を入力します。また、ジョブを手動で実行し、プロンプトが表示されたら資格証明を入力することもできます。

いずれの場合も、初期構成時にOAuth接続を承認することをお薦めします。このステップをスキップすると、デザイナから変更を公開できなくなり、変更のデプロイを試行する前に必要な認可を完了する必要があります。

承認されると、Authorization has been providedメッセージが表示されます。

ノート

OAuthが推奨される認可タイプです。Basic認証は、OAuth接続の設定で問題が発生した場合にのみ使用します。Basic認証を使用するには、「Basicの使用」を選択し、「ユーザー名」および「パスワード」でOracle Cloud Applicationsインスタンスにアクセスできるユーザーの資格証明を入力します。これらの資格証明は、フェデレーテッド・アイデンティティではなくローカル・ユーザーの資格証明である必要があり、マルチファクタ認証を必要としないでください。

OAuthトークン(アクセスおよびリフレッシュ)は、通常の使用中に循環されます。リフレッシュ・トークンは、ユーザーがターゲット・インスタンスにアクセスするたびにアクセス・トークンを取得するために使用されます。このリフレッシュ・トークンは通常、7日間有効です。(トークンの有効期限はIDCSリソース・アプリケーションで設定され、セキュリティ要件によって異なる場合があります。) ユーザーが7日以内にターゲット・インスタンスで認証すると、アクティブなリフレッシュ・トークンによって新しいアクセス・トークンと新しいリフレッシュ・トークンが生成されます。リフレッシュ・トークンが有効であるかぎり、このサイクルは無期限に続行されます。リフレッシュ・トークンが長時間非アクティブ状態(休暇中など)で期限切れになった場合は、「認可の更新」をクリックします(または、ジョブを手動で実行すると、期限切れのOAuthトークンを承認するよう求められます)。

「ビルド・アーティファクト」フィールドには、パッケージング・ビルド・ステップで使用されたものと同じアーティファクト名が表示されます。この値を確認します(特に、パッケージング・ジョブでデフォルト以外のアーティファクト名extension.vxが使用されている場合)。
「保存」をクリックします。

ノート

拡張機能(たとえば、テスト環境で24D)を開発して、拡張機能を24C本番環境にデプロイする場合は、本番インスタンスが24Dにアップグレードされるまで待ってから、正常にデプロイできます。ほとんどの場合、ポッド・アップグレードの間に2週間以上のギャップはありません。

ジョブ保護設定の構成

アクセスを制限するために、プロジェクト所有者はジョブをプライベートとしてマークできます。アクセス権がないユーザーは、「ジョブの概要」ページでビルド・ジョブを表示できますが、「ジョブの詳細」ページを表示したり、ビルドの詳細を表示したり、ジョブ構成を表示または編集したり、ビルド・ジョブを削除/有効化/無効化したりすることはできません。また、プロジェクト所有者は、ルールで定義されたglobパターンを使用して、指定したパターンに一致する名前を持つジョブを保護できます。

ノート

ジョブに保護を適用する前に、次の点を考慮する必要があります。

globパターンで定義された保護ルールは、名前を使用して定義されたジョブ保護を上書きしません( globパターンやルールはありません)。
単一のジョブに適用される保護は、ルール(globパターンで定義)を使用して適用される保護をオーバーライドします。
2つのルールを組み合せると、保護は最も制限の多いルールによって決定されます。アクティビティ・フィードのイベントを確認し、通知を調べる必要があります。通知は、あるルールが別のルールをオーバーライドする場合の制限を説明する情報を提供します。
ジョブを作成しているユーザーが自分のジョブにアクセスできない場合、ジョブは作成されません。同じ原則がジョブの名前変更にも当てはまります。

左側のナビゲータで、「プロジェクト管理」 をクリックします。
「ビルド」タイルを選択します。
「ジョブ保護」タブを選択します。

職務保護ページが表示されます。

図job-protection-page-initial.pngの説明
ジョブ/ルール・リストの上にある「次によるルールの検索」パネルで、次のいずれかのラジオ・ボタンを選択します。
- 「ジョブ名」を選択して、リストからジョブを選択します。
  プロジェクトに多数のジョブがある場合、保護する特定のジョブを見つけることが困難な場合があります。フィルタ・ジョブのバーを使用して、制限付き設定を追加するジョブをすばやく検索します。
  
  ジョブ・リストを右クリックして、追加のソート・オプションを表示します。「ジョブ名でソート」または「プライベート・ジョブでソート」をクリックして、リストを適切にソートします。ソート・オプションを再度クリックして、昇順と降順を切り替えます。
  
  ジョブにロック・アイコンがある場合は、すでに保護されています。保護されたジョブの制限は変更、削除することも、認可されたユーザーおよびグループのリストを変更することもできます。
  
  「ジョブ保護」ダイアログ・ボックスが表示されます。
  
  図job-protection-open.pngの説明
  ジョブが直接保護されておらず、かわりにルールによって保護されている場合、次のような情報メッセージに、特定のジョブを保護するルール<ExampleRegex05>が表示されます。
```
This job is protected by the following glob pattern rules matching this job name: <ExampleRegex05>
```
- 「Globパターン」を選択して、ジョブ名と一致する文字列を指定します。
  これは、まだルールが定義されていない場合に表示されます。
  
  図job-protection-page-glob-pattern-selected.pngの説明
  
  glob構文を使用すると、パターンマッチング動作を指定できます。これらのワイルドカード文字は、*、**、?、[]、{}および\のglobパターンで使用できます。
  
  リストから既存の保護ルールを選択するか、「+ルール」をクリックして「新規保護ルール」ダイアログを表示し、新しい保護ルールを作成します。
  
  「保護ルール」ダイアログ・ボックスが表示されます。
  
  図protection-rule-dialog-populated.pngの説明
  ここでは、名前(テスト・ルール)とglobパターン(test*)を入力しました。「作成」を押して新しいジョブ保護ルールを作成しようとしています。
「プライベート」チェック・ボックスを選択します。
これは、ジョブの「プライベート」オプションを選択した後に表示されます。

図job-protection-private.pngの説明

このオプションのみを選択すると、「ジョブ詳細」ページの表示、ジョブの編集または手動実行が可能なのは、認可ユーザーおよびグループのみになります。ジョブが未認可ユーザーまたはグループによってパイプライン内でトリガーされた場合、またはジョブがSCMまたはタイマーによってトリガーされた場合、そのジョブは開始されません。

これは、保護ルールの「プライベート」オプションを選択した後に表示されます。

図job-protection-rule-private.pngの説明
「認可されたユーザー/グループ」フィールド内をクリックして、選択可能なプロジェクトの「グループ」および「ユーザー」をリストするダイアログを表示します。

「ユーザー」の下には、グループのメンバーであるすべてのユーザーのフラット化されたリストと、個別に追加されたユーザーのリストが表示されます。たとえば、開発グループ・メンバー(Clara Coder、Don DeveloperおよびTina Testsuite)は、個別に追加されたAlex Adminとともに「Users」リストに表示されます。リストから、1つ以上のグループまたはユーザー(あるいはその両方)を選択します。自分を追加することを忘れないでください。

図authorized-groups-users.pngの説明

これは、認可ユーザーとしてAlex Adminを選択した後に、myProtectedJobジョブに表示される内容です。

図job-protection-private-authorized-user.pngの説明

これは、認可ユーザーとしてAlex Adminを選択した後に、テスト・ルール保護ルールに表示される内容です。

図job-protection-rule-authorized-user.pngの説明
チェック・ボックスを選択して、プロジェクト・メンバーがプライベート・ジョブを手動で開始したり、コミットおよびトリガーがプライベート・ジョブを自動的に開始できるようにします。
- 「プロジェクトの任意のメンバーにこのプライベート・ジョブの手動開始を許可」チェック・ボックスを選択して、認可されたユーザーのみでなく、任意のプロジェクト・メンバーにジョブの手動開始を許可してください。
  
  これは、myProtectedJobジョブの「プロジェクトの任意のメンバーにこのプライベート・ジョブを手動で開始させる」チェック・ボックスを選択した後に表示される内容です。
  
  図job-protection-private-both-checkboxes-selected.pngの説明
  
  最初のチェック・ボックスを選択すると、VB Studioによって2番目のチェック・ボックスが自動的に選択され、コミットおよびトリガーによってプライベート・ジョブが開始され、グレー表示されます。この設定では、承認されたユーザーおよびグループのみが「ジョブ詳細」ページを表示したり、ジョブを編集できますが、プロジェクト・メンバーはジョブを開始して実行できます。さらに、SCMのコミットまたはトリガーもジョブを自動的に開始して実行します。
  
  これは、テスト・ルール保護ルールの「プロジェクトの任意のメンバーにこのプライベート・ジョブを手動で開始させる」チェック・ボックスを選択した後に表示されます。
  
  図job-protection-page-both-check-boxes.pngの説明
- SCMのコミットおよびトリガーでこのジョブを自動的に実行できるようにする場合は、「コミットおよびトリガーによるこのプライベート・ジョブの開始の許可」チェック・ボックスのみを選択します。
  
  図job-protection-private-allow-commits-triggers.pngの説明
  
  このチェック・ボックスのみを選択すると、定期的なトリガーは、プライベート・ジョブの開始を許可するプライベート・ジョブ・セットを含む、任意のジョブまたはパイプラインを実行します。ただし、パイプラインにこのオプションが選択されたプライベート・ジョブが含まれていて、権限のないユーザーがパイプラインを手動で実行しようとすると、プライベート・ジョブは実行されませんが、定期的なトリガーとSCMコミットが実行されます。
  
  SCMコミットまたはタイマーによってトリガーされたときにジョブを開始しない場合は、チェック・ボックスの選択を解除したままにします。
  ノート
  
  ベストプラクティス:
  
  このチェック・ボックスを使用して、SCMコミットによって保護されたビルドをトリガーできるようにする場合は、ビルド・ジョブが関連付けられているブランチを保護する必要があります。これを実行しない場合、誰でも保護されたビルドをトリガーするためにコミットすることで、そのビルドをトリガーできます。
  
  これは、テスト・ルールの「このGLOBパターンに一致するジョブの開始をコミットおよびトリガーに許可」を選択した場合に表示されます。
  
  図job-protection-page-allow-commits-triggers.pngの説明
「保存」をクリックします。

アクティビティ・ストリームには、ジョブ保護のパブリックからプライベートへの変更、プライベートからパブリックへの変更、コミットおよびトリガーを許可するプライベート・ジョブの変更など、ジョブの保護ステータスに対するすべての変更が表示されます。