アドベントカレンダー企画8日目！
こんにちは！Ozawaです！
今回は、ネイティブアプリのバージョン管理方法について、取り上げていきます。
Snowflakeのネイティブアプリには、バージョンという概念が存在し、Pythonのライブラリのように、バージョンを管理することができます。
ネイティブアプリのバージョン操作を、ドキュメントから試行錯誤のナレッジまで、徹底解説していきます！！
ネイティブアプリのバージョン構成
ネイティブアプリのバージョンについてのドキュメントはこちら
ネイティブアプリのバージョン仕様について、v1_0.3 というバージョン名を使って解説すると、「1_0」がバージョン、「3」がパッチという概念になります。
ネイティブアプリでは、1つのアプリにつき2つのバージョンまで保持することができ、共有するバージョンを選択することができます。
また、バージョンごとにパッチは制限なく更新することができ、バージョンとパッチの組み合わせによる共有したいバージョンの指定も可能です。
下図を例にバージョンとパッチをもう少し深ぼってみましょう！
このアプリでは、v1.0 ~ v3.1まで作成しており、共有するバージョンにv3.1を選択し、v3.1が共有されています。
ネイティブアプリでは、バージョンは2つまで持つことしかできないため、このアプリでは、v3を作成する過程で、v1を削除しています。
これによって、v3.1が共有されている裏では、v2.2がスタンバイされています。
v3に致命的な欠陥がありパッチの更新で対応できない場合、v2.2はv3の代わりに共有されるというバッファ的な役割を持つといえます。
バージョン操作をするためのSQL
先のセクションのようなアプリのバージョン操作を実現するために、次の4点の操作が必要です。
バージョン操作のSQLのドキュメントはこちら
① バージョンを作成
② パッチを追加
③ バージョンを削除
④ 共有するバージョン・パッチを選択
① バージョンを作成
新しいバージョンを作成するためにはADD VERSIONというオプションを使います。
以下の例はMyAppPackageというパッケージにv1_0.0を作成しています。ADD VERSIONで作成したバージョンのパッチは0になります。
//バージョンを作成
ALTER APPLICATION PACKAGE MyAppPackage //アプリ名
ADD VERSION v1_0 //v1_0を新しいバージョンとして追加
USING '@dev_stage/v1_0' //ステージに置かれているアプリの設定ファイルを元に
LABEL = 'MyApp Version 1.0'; //v1_0の説明
② パッチを追加
パッチを追加するためには、ADD PATCHオプションを使います。
以下の例はv1_0に対してパッチを追加して、v1_0.1を作成しています。
ちなみに、v1_0.1を修正するために、v1_0.1を一旦削除し再作成することはできません。
v1_0.1を削除しても、Snowflakeの内部ではv1_0.1というログが残るため、v1_0.2が作成されてしまいます。
//パッチを作成
ALTER APPLICATION PACKAGE MyAppPackage //アプリ名
ADD PATCH FOR VERSION V1_0 //v1_0に対して、パッチを追加（パッチをADDすると、1->2->3のように大きくなっていく）
USING '@dev_stage/v1_0_p1'; //ステージに置かれているアプリの設定ファイルを元に
③ バージョンを削除
バージョンを削除するためには、DROP VERSIONオプションを使います。
以下の例ではv2を削除しています。
//バージョンを削除
ALTER APPLICATION PACKAGE MyAppPackage //アプリ名
DROP VERSION V2_0 //v2_0を削除
④ 共有するバージョン・パッチを選択
共有するバージョン・パッチを指定するためにはSET DEFAULT RELEASE DIRECTIVEオプションを使います。
以下の例ではv1_0.2を共有するバージョンとして設定しています。
//共有するバージョンとパッチを設定
ALTER APPLICATION PACKAGE MyAppPackage //アプリ名
SET DEFAULT RELEASE DIRECTIVE //v1_0.2を共有アプリに設定
VERSION = v1_0
PATCH = 2;
バージョン管理のTips
バージョンを変更すると共有オブジェクト（共有の番号みたいなもの）が完全に別物になり、パッチを変更しても共有オブジェクトが変わらない仕様により、
バージョンを更新したい場合はコンシューマ側がその都度アプリを再インストールする必要があります。
また、パッチは自動で更新されてしまいます。
そのため、プロバイダーとコンシューマ側それぞれで、バージョンとパッチの管理には注意が必要です。
プロバイダー側のTips
入力や出力が変わる修正はパッチではなくバージョン更新で実施します。
コンシューマ側がSnowflakeの定期Taskを回していたりする場合には、入力や出力が変わる自動更新はなるべく避けたいためです。
対して、軽微な内部ロジックの修正で、入出力に変化がないときには、パッチでの更新がよいです。
バージョン更新の場合はコンシューマ側が再インストールする必要があるため、ユーザビリティを考慮するとパッチでの自動更新がよいと考えられます。
コンシューマ側のTips
コンシューマ側では、バージョン更新の内容をよく見たうえでアップデートを行うことをお勧めします。
アプリによっては、最新のバージョンのみマーケットプレイスにアップしていることがあるため、一度古いバージョンを削除してしまうと、古いバージョンを再取得できないといった後戻りできないケースがあります。
おまけ コンシューマ側に古いバージョンを個別に共有する
コンシューマ側がどうしても古いバージョンのアプリが欲しい場合は、プロバイダー側が古いバージョンをダイレクトシェアしてアプリを共有する手もあります。
例えば、プロバイダー側がv2をマーケットプレイスで共有していたとして、コンシューマ側が古いバージョンv1をインストールしたいとします。
プロバイダー側は、マーケットプレイス上のアプリをv2からv1にバージョン変更するわけにもいかないので、
コンシューマ側に対して、個別にDirect Sharingを実施してv1を共有することも手です。
おわりに
truestarではSnowflakeの検討、導入支援や環境構築からアプリ開発まで幅広くサポート可能です。
Snowflakeに゙興味がある、導入済みだけどもっとうまく活用したい等々ありましたら、ぜひこちらから相談ください！
MarketPlaceにてリリースした「逆ジオコーディングアプリ」、その開発裏話や、
Streamlit in Snowflakeの試行錯誤記事のようにNative AppやStreamlit in Snowflakeに関する調査も行っています！
これまでのSnowflakeに関する記事はこちら
