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

Oracle Cloud ApplicationのPRODインスタンスに拡張をデプロイする前に、いくつかのパッケージ・ジョブおよびデプロイメント・ジョブを設定する必要があります。次のプロセスに従います:

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

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

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

ソース・インスタンスとターゲット・インスタンスが同じリリースであることを確認し、同じ標準パッチと1回限りのパッチを両方の環境に適用します。
visual-application.jsonで定義されたアプリケーションのバージョンを上書きするように開発パッケージング・ジョブを構成した場合は、新しいバージョンを取得します。同じバージョンを使用するように本番のパッケージング・ジョブを構成します。

本番パッケージ・ビルド・ジョブの作成

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

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

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

ノート

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

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

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

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

デプロイメント・ジョブは、パッケージング・ジョブで生成された拡張のアーティファクトをOracle Cloudアプリケーションの本番インスタンスにデプロイします。ジョブを作成する前に、VB StudioがOracle Cloud Applicationの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が推奨される認可タイプです。OAuth接続の設定で問題が発生した場合のみ、Basic認証を使用します。Basic認証を使用するには、「基本の使用」を選択し、「ユーザー名」および「パスワード」でOracle Cloud Applicationsインスタンスにアクセスできるユーザーの資格証明を入力します。これらの資格証明は、フェデレーテッド・アイデンティティではなくローカル・ユーザーの資格証明である必要があり、マルチファクタ認証を必要としません。

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

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

ノート

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

ジョブ保護設定の構成

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

ノート

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

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

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

「Job Protection」ページが表示されます。

図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*)を入力し、「作成」を押して新しいジョブ保護ルールを作成します。
「PRIVATE」チェック・ボックスを選択します。
これは、ジョブの「プライベート」オプションを選択した後に表示されます。

図job-protection-private.pngの説明

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

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

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

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

図authorized-groups-and-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-and-triggers.pngの説明
  
  このチェック・ボックスを選択するだけで、定期トリガーは、コミットおよびトリガーによるプライベート・ジョブの開始を許可するように設定されたプライベート・ジョブを含む、任意のジョブまたはパイプラインを実行します。ただし、このオプションが選択されたプライベート・ジョブがパイプラインに含まれていて、認可されていないユーザーがパイプラインを手動で実行しようとすると、プライベート・ジョブは実行されませんが、定期的なトリガーおよびSCMコミットは実行されます。
  
  ジョブがSCMコミットまたはタイマーによってトリガーされたときに起動しない場合は、チェック・ボックスの選択を解除したままにします。
  ノート
  
  ベスト・プラクティス:
  
  チェックボックスを使用して、SCMコミットによって保護されたビルドをトリガーできるようにする場合は、ビルド・ジョブが関連付けられているブランチを保護する必要があります。これを行わないと、だれでもコミットしてトリガーすることにより、保護されたビルドをトリガーできます。
  
  これは、テスト・ルールに対して「コミットおよびトリガーによる、このGLOBパターンに一致するジョブの開始の許可」を選択した場合に表示されます。
  
  図job-protection-page-allow-commits-and-triggers.pngの説明
「保存」をクリックします。

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