リリースシナリオの作成と管理

印刷する
共有
PDF

リリースシナリオの作成と管理

印刷する
共有
PDF

Article Summary

Share feedback

Thanks for sharing your feedback!

Classic/VPC環境で利用できます。

リリースシナリオの作成と管理でリリースターゲット別のリリースシナリオを作成し、管理する方法を説明します。

参考

リリースシナリオを作成して管理するには、顧客アカウントまたは changeProject権限を持つサブアカウントが必要です。権限の設定方法は Sub Account ご利用ガイドをご参照ください。

リリースシナリオはリリースターゲットに応じて作成方法が異なります。

作成するリリースシナリオのリリースターゲットに応じて作成方法を確認してください。

Serverリリースシナリオの作成
Auto Scalingリリースシナリオの作成
Ncloud Kubernetes Serviceリリースシナリオの作成
Object Storageリリースシナリオの作成

Serverリリースシナリオの作成

リリースターゲットが Serverであるリリースシナリオを作成する方法は、次の通りです。

NAVERクラウドプラットフォームコンソールにアクセスします。
Services > Developer Tools > SourceDeploy メニューを順にクリックします。
シナリオを作成するリリースプロジェクトをクリックした後、リリースターゲットが Server であるリリース Stageをクリックします。
[作成] ボタンをクリックします。
リリースシナリオの作成画面が表示されたら、次のステップを順に行います。

1. 基本設定

リリースシナリオの名前と説明を入力した後、 [次へ] ボタンをクリックします。

2. リリース戦略設定

リリース戦略とリリースコースを選択した後、 [次へ] ボタンをクリックします。
sourcedeploy-use-scenario_strategy_ko

リリース戦略は基本のみ提供され、設定したリリースサーバに対してリリースを行います。
リリースコースは 順次リリース と 同時リリース が提供されます。
- 順次リリース : 設定されたリリースサーバに対して順次リリースを行う
- 同時リリース : 設定されたリリースサーバに対して同時リリースを行う

3. リリースファイル設定

リリースファイルの保存場所とビルドプロジェクトを選択した後、 [次へ] ボタンをクリックします。
sourcedeploy-use-scenario_file_ko

リリースファイルの保存場所は、 Source Build 、 Object Storage 、 後で設定 が提供されます。
- Source Build を選択した場合、ビルドプロジェクトを選択します。最後のビルド結果が失敗だった場合やビルド結果をアップロードしていない場合には、リリースは実行されません。
- Object Storage を選択した場合、保有している Object Storage内のバケットの中からリリースファイルを選択します。リリースファイルは.zipで圧縮されたファイルのみリリースできます。
- 後で設定 を選択した場合、シナリオのリリース時にリリースファイルを設定できます。

4. リリースコマンド設定

sourcedeploy-use-scenario_command_ko

複数のコマンドを入力でき、順次実行されます。
リリース前に実行 : リリース前にサーバで実行するコマンドを設定した後、[追加] ボタンをクリックします。
実行アカウント : コマンドを実行するサーバアカウントを入力します。
実行コマンド : サーバで実行するコマンドを入力します。
ファイルのリリース : ファイルをリリースするパスを設定した後、[追加] ボタンをクリックします。
ソースファイルパス : リリースするファイルのパスを入力します。
リリースパス : イリースするサーバのフルパスを入力します。
3. リリースファイル設定でリリースファイルの保存場所として 後で設定 を選択する場合や、SourceBuildの最後のビルド結果がない場合、 ファイルのリリース に 後で設定 または 最後のビルド結果なし と表記されます。
リリース後に実行 : リリース後にサーバで実行するコマンドを設定した後、[追加] ボタンをクリックします。
実行アカウント : コマンドを実行するサーバアカウントを入力します。
実行コマンド : サーバで実行するコマンドを入力します。
追加したコマンドを削除するには、 [削除] ボタンをクリックします。
リリースが失敗した場合にロールバック機能を使用するには、使用をクリックして選択します。
- ロールバック機能を使用するとリリースに失敗した場合、自動的に以前のバージョンにロールバックします。
- 当該 Stageを基準に最後に成功したリリースを再実行することで、ロールバックが行われます。
- 過去にリリースしたファイルが Object Storageに存在しない場合や最後に成功したリリースがない場合、ロールバックは失敗します。

5. 最終確認

設定したリリースシナリオ情報を確認した後、 [リリースシナリオ作成] ボタンをクリックします。

Auto Scalingリリースシナリオの作成

リリースターゲットが Auto Scalingであるリリースシナリオを作成する方法は、次の通りです。

NAVERクラウドプラットフォームコンソールにアクセスします。
Services > Developer Tools > SourceDeploy メニューを順にクリックします。
シナリオを作成するリリースプロジェクトをクリックした後、リリースターゲットが Auto Scaling であるリリース Stageを選択します。
[作成] ボタンをクリックします。
リリースシナリオの作成画面が表示されたら、次のステップを順に行います。

1. 基本設定

リリースシナリオの名前と説明を入力した後、 [次へ] ボタンをクリックします。

2. リリース戦略設定

リリース戦略とリリースコースを選択した後、 [次へ] ボタンをクリックします。
sourcedeploy-use-scenario_strategy3_ko

リリース戦略は基本と ブルー/グリーン が提供されます。
参考
Classic環境では基本のみ提供され、VPC環境では基本と ブルー/グリーン のいずれも提供されます。
- 基本 : 設定された Auto Scaling Group内のサーバに対して順次リリースを実行
- ブルー/グリーン : 設定された Auto Scaling Groupをコピーして新しい Auto Scaling Groupを作成し、当該グループにリリースを実行
  - リリースが正常に完了すると、新規 Auto Scaling Group内のサーバが Load Balancer Target Groupに接続され、その Groupにトラフィックがルーティングされます。ブルー/グリーン戦略で、リリース中断時間を最小限に抑えられます。
リリースコースは 順次リリース と 同時リリース が提供されます。
- 順次リリース : 設定されたリリースサーバに対して順次リリースを行う
- 同時リリース : 設定されたリリースサーバに対して同時リリースを行う
リリース戦略で ブルー/グリーン を選択した場合、以下を設定します。
- 新しい Auto Scaling Groupに接続する Load Balancer Target Groupを選択します。
  - リリースターゲットに設定した Auto Scaling Groupに接続された Target Groupの中から選択できます。
  - [ヘルスチェック] ボタンをクリックすると Targetのヘルスチェック状態を確認できます。
- ブルー/グリーンリリースの完了後、既存の Auto Scaling Groupの削除と返却の有無を選択します。
  - 維持 : ブルー/グリーンリリースが完了しても既存の Auto Scaling Groupは返却されない
  - 削除と返却 : ブルー/グリーンリリースが完了すると既存の Auto Scaling Groupを返却し、既存の Auto Scaling Groupに属するサーバも自動で返却
- 既存の Auto Scaling Group を維持に選択する場合、ブルー/グリーンリリースが完了してから既存の Auto Scaling Group内のサーバに対する対応方法を選択します。
  - 維持 : ブルー/グリーンリリースの完了後、既存の Auto Scaling Group内サーバは返却されず、Load Balancer Target Groupでのみ接続が解除
  - 返却 : ブルー/グリーンリリースの完了後、既存の Auto Scaling Group内サーバを自動で返却
参考
Auto Scaling Groupに Cloud Insightモニタリングイベントが設定された場合、Auto Scaling Groupは返却できません。

したがって、ブルー/グリーンリリースで既存の Auto Scaling Groupに Cloud Insightモニタリングイベントが設定された場合、リリース完了後に既存の Auto Scaling Groupを自動返却できません。これ以上既存の Auto Scaling Groupが不要な場合、直接当該サービスで返却します。

:::

3. リリースファイル設定

リリースファイルの保存場所とビルドプロジェクトを選択した後、 [次へ] ボタンをクリックします。
sourcedeploy-use-scenario_file_ko

リリースファイルの保存場所は、 Source Build 、 Object Storage 、 後で設定 が提供されます。
- Source Build を選択した場合、ビルドプロジェクトを選択します。最後のビルド結果が失敗だった場合やビルド結果をアップロードしていない場合には、リリースは実行されません。
- Object Storage を選択した場合、保有している Object Storage内のバケットの中からリリースファイルを選択します。リリースファイルは.zipで圧縮されたファイルのみリリースできます。
- 後で設定 を選択した場合、シナリオのリリース時にリリースファイルを設定できます。

4. リリースコマンド設定

リリースコマンドを設定した後、 [次へ] ボタンをクリックします。

sourcedeploy-use-scenario_command_ko

複数のコマンドを入力でき、順次実行されます。
リリース前に実行 : リリース前にサーバで実行するコマンドを設定した後、[追加] ボタンをクリックします。
実行アカウント : コマンドを実行するサーバアカウントを入力します。
実行コマンド : サーバで実行するコマンドを入力します。
ファイルのリリース : ファイルをリリースするパスを設定した後、[追加] ボタンをクリックします。
ソースファイルパス : リリースするファイルのパスを入力します。
リリースパス : イリースするサーバのフルパスを入力します。
3. リリースファイル設定でリリースファイルの保存場所として 後で設定 を選択する場合や、SourceBuildの最後のビルド結果がない場合、 ファイルのリリース に 後で設定 または 最後のビルド結果なし と表記されます。
リリース後に実行 : リリース後にサーバで実行するコマンドを設定した後、[追加] ボタンをクリックします。
実行アカウント : コマンドを実行するサーバアカウントを入力します。
実行コマンド : サーバで実行するコマンドを入力します。
追加したコマンドを削除するには、 [削除] ボタンをクリックします。
リリースが失敗した場合にロールバック機能を使用するには、使用をクリックして選択します。
- ロールバック機能を使用するとリリースに失敗した場合、自動的に以前のバージョンにロールバックします。
- 当該 Stageを基準に最後に成功したリリースを再実行することで、ロールバックが行われます。
- 過去にリリースしたファイルが Object Storageに存在しない場合や最後に成功したリリースがない場合、ロールバックは失敗します。

5. 最終確認

設定したリリースシナリオ情報を確認した後、 [リリースシナリオ作成] ボタンをクリックします。

Ncloud Kubernetes Serviceリリースシナリオの作成

リリースターゲットが Ncloud Kubernetes Serviceであるリリースシナリオを作成する方法は、次の通りです。

NAVERクラウドプラットフォームコンソールにアクセスします。
Services > Developer Tools > SourceDeploy メニューを順にクリックします。
シナリオを作成するリリースプロジェクトをクリックした後、リリースターゲットが Ncloud Kubernetes Service であるリリース Stageを選択します。
[作成] ボタンをクリックします。
リリースシナリオの作成画面が表示されたら、次のステップを順に行います。

1. 基本設定

リリースシナリオの名前と説明を入力した後、 [次へ] ボタンをクリックします。

2. マニフェスト設定

マニフェストファイルが位置するレポジトリとパスを設定した後、 [次へ] ボタンをクリックします。

sourcedeploy-use-scenario_manifest_ko

マニフェストファイルの保存場所タイプを選択した後、必要な詳細項目を設定します。
- SourceCommit を選択時、以下の項目を設定
  - リポジトリ : マニフェストファイルが保存されているリポジトリを選択
  - ブランチ : マニフェストファイルが保存されているリポジトリのブランチを選択
- Github Enterprise Server を選択時、 [ログイン] ボタンをクリックして次の項目を設定
  - 次のいずれかの認証情報を入力した後、 [Github Enterprise Serverにログイン] ボタンをクリック
    - OAuth : リポジトリをインポートする Github Enterprise Server URL とそのサーバで作成した OAuth Appの Client Id、Client Secret を入力
    - Personal Access Token : リポジトリをインポートする Github Enterprise Server URL とそのサーバで作成した Personal Access Token を入力
    - Username/Password : リポジトリをインポートする Github Enterprise Server URL とそのサーバの ユーザーアカウント情報 を入力
    - SSH Key : SSHプロトコル形式の Gitリポジトリ URL と認証のための SSH Private Key、Passphrase を入力(Passphraseは、SSH Keyに Passphraseを設定した場合に入力します)。
  参考
  - ファイアウォールの設定などにより Github Enterprise Serverと通信ができない場合は、当該保存場所タイプは使用できません。
  - Github Enterprise Server URLは IPアドレス、Hostnameで入力でき、publicな環境である必要があります。
  - SSH Keyログインは他のログインと違って、入力した Gitリポジトリ URLのリポジトリにのみアクセスできます。
  - GitHub Enterprise Server公式ガイド
    OAuth APP作成ガイド
    OAuth App設定時、プラットフォーム/リージョンに適した Callback URLを設定します。各 URLは次の通りです。
    KR(Classic) : https://devtools.ncloud.com/ghes/sourcedeploy
    KR(VPC) : https://devtools.ncloud.com/ghes/vpc/sourcedeploy
    SGN(VPC) : https://devtools-sg.ncloud.com/ghes/vpc/sourcedeploy
    JPN(VPC) : https://devtools-jp.ncloud.com/ghes/vpc/sourcedeploy
    Personal Access Token作成ガイド
    SSH key設定ガイド
  - 所有者 : マニフェストファイルが保存されているリポジトリの所有者を選択
  - リポジトリ : マニフェストファイルが保存されているリポジトリを選択
  - ブランチ : マニフェストファイルが保存されているリポジトリのブランチを選択
リリースするマニフェストファイルのパスを入力した後、 [追加] ボタンをクリックします。
- 追加したパスは [削除] ボタンをクリックして削除できます。

参考

Ncloud Kubernetes Serviceのクラスタにオブジェクトをリリースするには、マニフェストを作成する必要があり、リリースに使用するマニフェストは SourceCommitリポジトリに保存されている必要があります。
マニフェストファイルの作成順にリリースを行います。
ブルー/グリーン、Canaryアップデートのために新しいマニフェストを作成する必要はありません。ブルー/グリーン、Canaryに必要な新しいオブジェクトは、SourceDeployで自動でリリースします。

マニフェストの作成については以下の例をご参照ください。
例) 過去にリリースした Kubernetesオブジェクト(kind: Deployment、name: sampleapp、namespace: dev)
sourcedeploy-use-scenario_manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sampleapp
  namespace: dev
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - image: '${registry_endpoint}/nodejs_dockerbuild:latest'
          imagePullPolicy: Always
          name: sampleapp
          ports:
            - containerPort: 3000
      imagePullSecrets:
        - name: pub

3. リリース戦略設定

リリース戦略を選択した後、 [次へ] ボタンをクリックします。

sourcedeploy-use-scenario_strategy2_ko

Rolling : 過去にリリースしたオブジェクトがない場合、新しいオブジェクトをリリース
オブジェクトのアップデートではなく、新しいオブジェクトをリリースする場合は Rolling を選択します。
ブルー/グリーン /Canary : 過去にリリースしたオブジェクトがない場合、リリース失敗
ブルー/グリーン、Canaryリリース戦略では新しいオブジェクトはリリースできません。
ブルー/グリーン戦略でリリースする場合、新しいバージョン(Green)のオブジェクトがリリースされるため、オブジェクトの名前が変更されます。オブジェクト名が変更されてもマニフェストを変更せず、SourceDeployで継続的にリリースできます。ただし、そのマニフェストを利用して kubectl applyなどを通じて手動でリリースすることで既存名のオブジェクトが作成される場合、アップデートするオブジェクトは特定できません。そのため、SourceDeployによる継続的なリリースは不可能になります。
リリース戦略で Canary を選択した場合、分析方法に応じて Canary手動分析設定、Canary自動分析設定をご参照ください。

Canary手動分析設定

sourcedeploy-use-scenario_canary_ko

Baseline、Canary Pod数 : Baseline、Canaryバージョンのアプリケーションに適用する Replicas数を入力します。
1~10まで設定できます。
Canaryの分析方法 : 手動を選択します。
Baseline、Canaryバージョンのアプリケーションをユーザーが手動で分析し、リリースの承認/キャンセルを決定します。
Time Out : ユーザーが Canaryリリース/キャンセルを決定できる最大時間を入力します。
1~360分まで設定できます。
設定された時間を超えると自動的にリリースがキャンセルされ、Baseline、Canaryアプリケーションは終了します。

Canary自動分析設定

sourcedeploy-use-scenario_canary2_ko

Baseline、Canary Pod数 : Baseline、Canaryバージョンのアプリケーションに適用する Replicas数を入力します。
1~10まで設定できます。
Canaryの分析方法 で自動を選択します。
Baseline、Canaryバージョンのアプリケーションを自動で分析し、分析結果に応じてリリースを行います。
Prometheus Url : Prometheus収集ログリクエストのために Prometheusエンドポイントを入力します。
アプリケーションを自動で分析するには、Ncloud Kubernetes Serviceのクラスタに Prometheusがインストールされている必要があります。
エンドポイントは SourceDeployからアクセスできるようにパブリック IPアドレスを設定します。
- Prometheus Serviceを Load Balancer typeに設定します。
分析環境変数 : Prometheusの分析時に Baselineと Canaryを区別するための変数を入力します。
この入力値は PromQL構文で ${basecanary}として活用できます。
分析環境変数は、Baseline、Canaryそれぞれ Pod Labelの ncp_sourcedeploy_canary="baselineenv"/ncp_sourcedeploy_canary="canaryenv"に設定され、その値を Canaryの分析時に活用できます。
評価対象となる Metricを作成してから選択します。
- Metricの作成に関する内容は Metric作成をご参照ください。
- Metricの設定を変更するには、設定を変更する Metricを選択した後、 [設定変更] ボタンをクリックします。各項目についての詳細は Metric作成をご参照ください。
- Metricを削除するには、削除する Metricを選択した後、 [削除] ボタンをクリックします。
- すべての Metric Weightの合計は100にしてください。
分析の設定を行います。
- 分析遅延時間 : Baseline、Canaryバージョンのアプリケーションをリリースした後、分析を開始する時間を入力します。
  - 入力した時間以降に分析を開始し、0~60分まで設定できます。
- 分析時間 : 分析を実行する合計時間を入力します。
  - 10~360分まで設定できます。
- 分析周期 : 分析を実行する周期を入力します。
  - 1~360分まで設定でき、分析時間を超過できません。
- Metricの収集周期 : 分析時に収集された Metric値をサンプリングする周期を入力します。
  - 1~360秒まで設定できます。
分析成功スコア : 分析時のすべての Metricに対する分析スコアを入力します。
1~100まで設定できます。
分析ステップごとにこのスコアを満たさないと、リリースは行われません。
分析ステップでこのスコアを満たさない場合、分析は直ちに停止され、Baselineと Canaryバージョンのアプリケーションは終了します。
登録されたすべての Metricスコアの合計です。
- Metricスコアに関する詳細は Metric作成をご参照ください。

Metric作成

3. リリース戦略設定ステップでリリース戦略で Canary を選択し、分析方法で自動を選択した場合、Metricを作成する方法は次の通りです。

Metric設定 で [作成] ボタンをクリックします。
Metric作成のポップアップで Metric情報を入力します。
- Metric名を入力します。
- 成功基準 を選択します。
  - 登録されたクエリ結果の成功基準で、成功または失敗と分析されます。
  - クエリ結果は n個出ることがあり、各クエリの結果ごとに成功/失敗が決定されます。
  - 登録された Metricスコアは(成功したクエリの結果/全クエリの結果)の重み付けで計算されます。
  - Baseline < Canary : Baselineバージョンの値が Canaryバージョンの値よりも大きい場合、成功(偏差値が負の数であるか、同じである場合に成功)
  - Baseline > Canary : Canaryバージョンの値が Baselineバージョンの値よりも大きい場合、成功(偏差値が正の数であるか、同じである場合に成功)
- クエリタイプ を選択します。
  - Default : Label selectorのみ活用する場合に使用
    - Metric : Canary自動分析設定時に入力した Prometheus Urlの設定された Metricを選択します。
    - Filter : 希望するラベル条件を入力します。
      例)
```
kubernetes_namespace="dev" , ncp_sourcedeploy_canary="${basecanary}"
```
    - Filter の ${basecanary}は、Baselineと Canaryの比較・分析のために予約語として提供します。クエリにその予約語を使用して分析すると、分析環境変数値に置換されてクエリします。
      例) Metric: requests total
      Filter: ncp sourcedeploy_canary=${basecanary}
      Canary: canaryenv、Baseline: baselineenv(Canary自動分析設定の 分析環境変数 をご参照)
      Baselineバージョンクエリ requests_total{ncp_sourcedeploy_canary="baselineenv"}
      Canaryバージョンクエリ requests_total{ncp_sourcedeploy_canary="canaryenv"}
  - PromQL : ユーザーが クエリ に直接 PromQLを入力して使用
    例) ウェブアプリケーション requests成功率 PromQL
```
sum(requests_total{kubernetes_namespace="dev",custom_status="good", ncp_sourcedeploy_canary="${basecanary}"})/sum(requests_total{kubernetes_namespace="dev", ncp_sourcedeploy_canary="${basecanary}"})
```
- Weight : 当該 Metricの重み付けを入力します。
  - 1~100まで設定できます。

4. 最終確認

設定したリリースシナリオ情報を確認した後、 [リリースシナリオ作成] ボタンをクリックします。

CI/CD環境構築

SourceDeployを使用して Ncloud Kubernetes Serviceのクラスタに継続的なリリースを構成するために、CI/CD環境を構築できます。

CI/CD環境を構築する方法は、次の通りです。

NAVERクラウドプラットフォームコンソールにアクセスします。
Services > Containers > Container Registry メニューを順にクリックします。
[レジストリ作成] ボタンをクリックしてレジストリを作成します。

レジストリの作成に関する詳細は Container Registryご利用ガイドをご参照ください。

Services > Developer Tools > SourceBuild メニューを順にクリックします。
[ビルドプロジェクト作成] ボタンをクリックしてビルドプロジェクトを作成します。

ビルドプロジェクトの作成に関する詳細は SourceBuildご利用ガイドをご参照ください。
Dockerイメージビルド機能を使用して Dockerイメージをビルドし、Container Registryに保存できます。
- ビルド環境の設定ステップで Dockerイメージビルド をクリックして選択した後、ビルドコマンドの設定ステップで Dockerイメージビルドの設定 を使用に設定します。
- イメージタグ は latestに設定 をクリックして選択します。
  - SourceDeployで自動的に latestタグを digest形式に変更してリリースをしようとするため、イメージ設定が変更されなくても、正常に継続的なリリースを実行できます。
  - イメージのバージョン管理とともに使用して常に latestイメージをビルドできます。

Services > Developer Tools > SourceDeploy メニューを順にクリックします。
[リリースプロジェクトの作成] ボタンをクリックしてリリースターゲットが Ncloud Kubernetes Serviceであるリリースプロジェクトを作成します。

リリースプロジェクトの作成に関する詳細は、リリースプロジェクト作成をご参照ください。

Ncloud Kubernetes Serviceリリースシナリオの作成を参照してリリースシナリオを作成します。
Services > Developer Tools > SourcePipeline メニューを順にクリックします。
[パイプライン作成] ボタンをクリックしてパイプラインを作成します。
* パイプラインの作成に関する詳細は、SourcePipelineご利用ガイドをご参照ください。
- Dockerイメージビルドが設定された SourceBuildプロジェクトと、Ncloud Kubernetes Serviceリリースが設定された SourceDeployプロジェクトをパイプラインで構成して CI/CD環境を構築できます。
- Trigger設定 をクリックして選択すると、SourceCommitにプッシュすると同時に Dockerイメージ、Ncloud Kubernetes Serviceのクラスタに新しいオブジェクトをリリースしてサービスを運用できます。

参考

SourceDeployを使用して Ncloud Kubernetes Serviceのクラスタに継続的なリリースを構成するには、リリースイメージが Container Registryに保存されている必要があります。

Object Storageリリースシナリオの作成

リリースターゲットが Object Storageであるリリースのシナリオを作成する方法は、次の通りです。

NAVERクラウドプラットフォームコンソールにアクセスします。
Services > Developer Tools > SourceDeploy メニューを順にクリックします。
シナリオを作成するリリースプロジェクトをクリックした後、リリースターゲットが Object Storage であるリリース Stageを選択します。
[作成] ボタンをクリックします。
リリースシナリオの作成画面が表示されたら、次のステップを順に行います。

1. 基本設定

リリースシナリオの名前と説明を入力した後、 [次へ] ボタンをクリックします。

2. リリースファイル設定

リリースファイルの保存場所とビルドプロジェクトを選択した後、 [次へ] ボタンをクリックします。
sourcedeploy-use-scenario_file2_ko

リリースファイルの保存場所は、 Source Build 、 Object Storage 、 後で設定 が提供されます。
- Source Build を選択した場合、ビルドプロジェクトを選択します。最後のビルド結果が失敗だった場合やビルド結果をアップロードしていない場合には、リリースは実行されません。
- Object Storage を選択した場合、保有している Object Storage内のバケットの中からリリースファイルを選択します。リリースファイルは.zipで圧縮されたファイルのみリリースできます。
- 後で設定 を選択した場合、シナリオのリリース時にリリースファイルを設定できます。

3. リリースパス設定

ファイルのリリースパスを設定した後、 [次へ] ボタンをクリックします。
sourcedeploy-use-scenario_route_ko

ソースファイルパス とリリースパス を入力した後、[追加] ボタンをクリックします。
パスは複数入力して追加できます。
ソースファイルパス : リリースするファイルのパスを入力します。
リリースパス : リリースするバケットのパスを入力します。
ロック処理したバケットの場合、既にアップロード済みのファイルはロックされます。そのため、同じファイル名(リリースパス)で作成すると、正常にリリースされません。
2. リリースファイル設定でリリースファイルの保存場所として 後で設定 を選択する場合や、SourceBuildの最後のビルド結果がない場合、 後で設定 または 最後のビルド結果なし と表記されます。
追加したパスを削除するには [削除] ボタンをクリックします。
設定したリリースパスにあるファイルのバックアップ機能を使用するには、使用をクリックして選択します。
- バックアップ機能を使用する場合、設定したリリースパスにあるすべてのファイルをバックアックします。

4. 最終確認

設定したリリースシナリオ情報を確認した後、 [リリースシナリオ作成] ボタンをクリックします。

リリースシナリオの設定変更

リリースシナリオの設定を変更する方法は、次の通りです。

NAVERクラウドプラットフォームコンソールにアクセスします。
Services > Developer Tools > SourceDeploy メニューを順にクリックします。
シナリオの設定を変更するリリースプロジェクトとリリース Stageを順にクリックします。
設定を変更するシナリオを選択した後、 [設定変更] ボタンをクリックします。
リリースシナリオの設定ポップアップで変更する内容を適用した後、 [適用] ボタンをクリックします。
- リリースシナリオの作成時に設定したシナリオ名以外の項目はいずれも変更できます。
- 各項目に関する詳細はリリースターゲット別に以下をご参照ください。
  - Serverリリースシナリオの作成
  - Auto Scalingリリースシナリオの作成
  - [Ncloud Kubernetes Serviceリリースシナリオの作成](#Ncloud KubernetesService배포시나리오생성)
  - Object Storageリリースシナリオの作成

リリースシナリオの削除

リリースシナリオを削除する方法は、次の通りです。

NAVERクラウドプラットフォームコンソールにアクセスします。
Services > Developer Tools > SourceDeploy メニューを順にクリックします。
シナリオを削除するリリースプロジェクトとリリース Stageをクリックします。
削除するシナリオを選択した後、 [削除] ボタンをクリックします。
リリースシナリオの削除ポップアップで、 [削除] ボタンをクリックします。
- 当該リリースシナリオが削除されます。

この記事は役に立ちましたか?

What's Next

リリースの実行と管理

Serverリリースシナリオの作成
Auto Scalingリリースシナリオの作成
Ncloud Kubernetes Serviceリリースシナリオの作成
Object Storageリリースシナリオの作成
リリースシナリオの設定変更
リリースシナリオの削除

タグ