アプリのバージョンおよびアップグレードの概要¶
このトピックでは、バージョン、パッチ、アップグレードが 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 には、アクティブなパッチの実行数に制限はありません。プロバイダーは、複数のパッチにまたがって非互換になることを避けるため、パッチ内でアプリの状態を変更することは避けなければなりません。
ステートフル・オブジェクトとステートレス・オブジェクト¶
アプリの新しいバージョンを開発するとき、プロバイダーは、変更するコンポーネントが、あるバージョンやパッチから別のバージョンへの状態を保持する必要があるかどうかを考慮する必要があります。一般的なアプリには2つのタイプのコンテナーがあります。
- ステートレス・オブジェクト
ステートレス・オブジェクトは、アプリの新しいバージョンやパッチごとに再作成されます。ステートレス・オブジェクトはバージョンの有効期間中だけ利用可能であればよく、必要に応じて再作成することができます。ステートレス・オブジェクトは通常、ストアドプロシージャ、ユーザー定義関数、Streamlit アプリ、および同様のコンテンツを含むアプリのコードです。
ステートレス・オブジェクトは、 バージョン管理されたスキーマ で作成されるべきです。
- ステートフル・オブジェクト
ステートフルオブジェクトは、アプリのバージョンやパッチ間で共有されます。ステートフルなコンポーネントは、アプリの複数のバージョンにまたがるライフタイムを持つことを意図しています。例えば、アプリがコンシューマーアカウント内の構成情報を保存するためにテーブルを使用している場合、このテーブルの内容はアップグレード中も保持される必要があります。
ステートフル・オブジェクトは、通常のスキーマを使用して作成する必要があります。
バージョン・スキーマについて¶
新しいバージョンのアプリのセットアップスクリプトを書くとき、プロバイダーはステートレスおよびステートフル・コンポーネントをアカウントしなければなりません。ステートレスオブジェクトを扱うために、 Snowflake Native App Framework はバージョンスキーマと呼ばれる特別なタイプのデータベーススキーマを提供します。バージョン管理スキーマは、通常のデータベーススキーマと似ていますが、異なるアプリのバージョンによって作成された複数のバージョンのオブジェクトを処理する関数が追加されています。
詳細については、 バージョンスキーマを使用して、バージョン間でアプリ・オブジェクトを管理 をご参照ください。
アプリのアップグレードについて¶
Snowflake Native App Framework では、プロバイダーはアプリを新しいバージョンやパッチにアップグレードすることができます。アプリの新しいバージョンやパッチを開発するための全体的なワークフローの中で、アップグレードがどのように適合するかについては、 アプリ更新のワークフロー をご参照ください。
プロバイダーは、アプリケーションパッケージにリリースディレクティブをセットすることで、アプリケーションの新しいバージョンやパッチへのアップグレードを開始することができます。リリースディレクティブが変更されると、Snowflakeは自動的に現在のバージョンのアプリのインストールされているすべてのインスタンスをリリースディレクティブで指定されたバージョンにアップグレードします。
プロバイダーがアップグレードを開始すると、Snowflakeはアップグレードする各アプリをキューに追加します。各アプリはリソースの可用性に応じてアップグレードされます。アップグレードプロセスは、インストールされているすべてのバージョンのアプリで完了するまでに時間がかかることがあります。アップグレードプロセスを迅速化するために、コンシューマーは、新しいバージョンやパッチが利用可能になったときに、手動でアプリのアップグレードを開始することもできます。
注釈
アプリのアップグレードプロセスが開始されると、コンシューマーはアプリを手動でアップグレードすることができなくなります。
詳細については、 アプリをアップグレードする をご参照ください。
リージョン間のアップグレード¶
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¶