Overview of app versions and upgrades (Legacy)¶
このトピックでは、バージョン、パッチ、アップグレードが Snowflake Native App Framework でどのように機能するかについての情報を提供します。
アプリのバージョンとパッチについて¶
Snowflake Native App Framework では、プロバイダーはアプリのバージョンやパッチを作成することができます。バージョンとパッチにより、プロバイダーは新しい関数とアップデートをコンシューマーにリリースすることができます。
- バージョン
一般的には Snowflake Native App の主な更新が含まれます。バージョンは通常、アプリの新機能や変更された関数を導入します。
- パッチ
一般的には Snowflake Native App に対するより小さな更新が含まれます。バージョンとは異なり、パッチにはセキュリティ修正などの小容量の更新しか含まれていないはずです。
アプリケーションのバージョンとパッチは、アプリケーションパッケージで指定されます。
注意
アプリは一度に2つのバージョンしかアクティブにできません。アプリの各バージョンには最大130のパッチがあります。
現在2つのバージョンが定義されているアプリケーションパッケージに新しいバージョンを追加するには、プロバイダーは既存のバージョンの1つを削除する必要があります。バージョンを削除するには、プロバイダーは以下を行う必要があります：
すべてのコンシューマーが削除するバージョンからアップグレードしていることを確認してください。
アプリケーションパッケージからバージョンを削除します。
新しいバージョンを作成します。
アプリのアップグレードをします。
注意
アプリはコンシューマーアカウントでアップグレードされるかもしれませんが、以前のバージョンのアプリのコードはまだ実行されているかもしれません。プロバイダーは、旧バージョンの実行コードがすべて完了するまで、アプリケーションパッケージから旧バージョンのアプリケーションを削除することはできません。これは、すべてのコンシューマーアカウントにインストールされているすべてのバージョンのアプリに適用されます。1回のアップグレードが失敗した場合、プロバイダーはバージョンを削除する前に、アップグレード失敗の原因を修正しなければなりません。
アプリケーションパッケージには一度に2つのアクティブなバージョンしか含めることができませんが、1つのバージョンには複数のパッチを含めることができます。Snowflake Native App Framework はパッチの削除には対応していません。プロバイダーがアプリケーション・パッケージに新しいバージョンを追加すると、新しいバージョンにはデフォルトでパッチ 0 が自動的に割り当てられます。これは変更できません。
プロバイダーがバージョンに新しいパッチを追加するとき、パッチの識別子を手動で指定することができます。パッチ番号が提供されない場合、Snowflakeは自動的にパッチバージョンを1だけインクリメントします。
注釈
それぞれのバージョンとパッチには、独自のセットアップスクリプトとアプリケーションファイルのバージョンが必要です。
バージョンとパッチのアップグレード¶
プロバイダーがアプリの新バージョンを公開するとき、 Snowflake Native App Framework はアプリの旧バージョンのみがアクティブであることを確認します。例えば、プロバイダーがアプリのバージョンv1とv2を公開している場合、 Snowflake Native App Framework は、v3にアップグレードする前に、コンシューマーアカウントに現在v2のみがインストールされていることを確認します。このため、バージョンv1を使用してインストールされているすべてのアプリをバージョンv2に移行する必要があります。
これにより、アプリのセットアップスクリプトはv2とv3の違いをアカウントするだけでよくなります。セットアップスクリプトは、アプリの最新バージョンとの下位互換性しかありません。プロバイダーがアプリの状態を変更する場合、たとえば新しいテーブルを作成したり、テーブルに列を追加したりする場合、プロバイダーは2つのバージョン間で互換性の問題がないことを確認するだけでよいのです。
対照的に、プロバイダーがアプリのバージョンに新しいパッチを作成する場合、 Snowflake Native App Framework には、アクティブなパッチの実行数に制限はありません。プロバイダーは、複数のパッチにまたがって非互換になることを避けるため、パッチ内でアプリの状態を変更することは避けなければなりません。
ステートフル・オブジェクトとステートレス・オブジェクト¶
Snowflake Native App 内のステートフルオブジェクトとステートレスオブジェクトについては、 Use versioned schema to manage app objects across versions をご参照ください。
バージョン・スキーマについて¶
Snowflake Native App でバージョン管理されたスキーマを使用する方法については、 Use versioned schema to manage app objects across versions をご参照ください。
アプリのアップグレードについて¶
The Snowflake Native App Framework allows providers to upgrade an app to a new version or patch. To see how upgrades fit in the overall workflow for developing a new version or patch of an app, see アプリ更新のワークフロー.
プロバイダーは、アプリケーションパッケージにリリースディレクティブをセットすることで、アプリケーションの新しいバージョンやパッチへのアップグレードを開始することができます。リリースディレクティブが変更されると、Snowflakeは自動的に現在のバージョンのアプリのインストールされているすべてのインスタンスをリリースディレクティブで指定されたバージョンにアップグレードします。
プロバイダーがアップグレードを開始すると、Snowflakeはアップグレードする各アプリをキューに追加します。各アプリはリソースの可用性に応じてアップグレードされます。アップグレードプロセスは、インストールされているすべてのバージョンのアプリで完了するまでに時間がかかることがあります。アップグレードプロセスを迅速化するために、コンシューマーは、新しいバージョンやパッチが利用可能になったときに、手動でアプリのアップグレードを開始することもできます。
注釈
アプリのアップグレードプロセスが開始されると、コンシューマーはアプリを手動でアップグレードすることができなくなります。
詳細については、 Upgrade an app (Legacy) をご参照ください。
リージョン間のアップグレード¶
Cross-Cloud Auto-Fulfillment を使用してリージョンをまたいでインストールされたアプリをアップグレードする情報については、 リージョンをまたいだアプリのアップグレード を参照してください。
アプリのバージョンとパッチのライフサイクル¶
アプリのバージョンとパッチがどのように連動するかを理解するために、プロバイダーがアプリの初期バージョンv1を公開し、コンシューマーAとコンシューマーBがそれぞれのアカウントにそのバージョンのアプリをインストールしたというシナリオを考えてみましょう。
このシナリオは以下のセクションに示されています。
バージョンv1.0はコンシューマーアカウントにインストールされています。¶
図1 は、プロバイダーが公開し、2人のコンシューマーがそのアプリをアカウントにインストールしたアプリのバージョン v1.0 を示しています。
図1 - バージョン v1.0¶
この図は次のことを示しています：
v1.0のアプリケーションファイルはステージに格納されます。アプリケーションパッケージのリリースディレクティブは
v1.0にセットされています。コンシューマーはアカウントに
v1.0をインストールしています。プロバイダーは彼らのアカウントでバージョン2.0の開発を開始しました。
アプリケーションパッケージにバージョンv2.0を追加¶
図2 は、プロバイダーがバージョン v2.0 をアップロードし、アプリケーションパッケージ内に新しい バージョンを作成したことを示しています。
図2 - ステージにアップロードされたファイル¶
この図は次のことを示しています：
アプリのバージョン
v2.0をローカルでテストした後、プロバイダーはv2.0ファイルをステージにアップロードします。プロバイダーはアプリケーションパッケージ内にアプリケーションの新しいバージョンを作成します。
リリースディレクティブは引き続きアプリのバージョン
v1.0を指します。コンシューマーは引き続き、アカウントにインストールされているバージョン
v1.0を使います。
バージョンv1.0からv2.0へのアップグレード¶
アプリのバージョン v1.0 からバージョン v2.0 へのアップグレードを実行するために、プロバイダーはアプリケーションパッケージの リリースディレクティブ をバージョン v2.0 にセットします。これにより、コンシューマーアカウントのアプリのアップグレードプロセスが開始されます。
アップグレードが完了すると、コンシューマー A とコンシューマー B のアカウントには、 図 3 の図のようにバージョン v2.0 がインストールされます。
図3 - バージョン v1.0 から v2.0 へのアップグレード¶
また、このシナリオでは、プロバイダーはローカルの開発環境でバージョンv3.0の開発とテストを開始しています。
バージョンv1.0を削除し、v3.0を作成できるようにする¶
テストが完了すると、プロバイダーはバージョン v3.0 をステージにアップロードします。プロバイダーがバージョン v3.0 へのアップグレードを開始しようとする場合、まず、すべてのコンシューマーがバージョン v1.0 から移行していることを確認する必要があります。
前セクションで示したシナリオでは、現在、すべてのコンシューマーが v2.0 を利用しています。
図4 に示すように、プロバイダーはアプリケーションパッケージからバージョン v1.0 を削除する必要があります。
図4 - アプリケーションパッケージからのドロップバージョン v1.0¶
アプリケーションパッケージにバージョン v3.0 を追加¶
バージョン v1.0 を削除した後、プロバイダーはアプリケーションパッケージにバージョン v3.0 を追加することができます。このコンテキストでは、リリース指令はまだ v2.0 を指しており、コンシューマーは自分のアカウントに v2.0 をインストールされています。
図5 - アプリケーション・パッケージにバージョン v3.0 を追加¶
バージョン v3.0 にアップグレードする¶
v3.0 にアップグレードするには、プロバイダーはリリースディレクティブを v3.0 を指すように更新します。これでアップグレードが始まります。アップグレードが完了すると、コンシューマーは下図のようにバージョン v3.0 にアップグレードされます。
図5 - バージョンアップ v3.0¶