Streamlit in SnowflakeのGit Repository統合サポートについての速報
みなさん、Streamlit in Snowflake活用していますか〜？
2025_01Bundleに個人的に気になっていたSiSのGit Repository統合やマルチファイルの編集が可能になる動作変更リリースが含まれていましたが、ついにAWS Tokyoリージョンにロールアウトされました！
早速わかる範囲で検証してみたのでまとめます。
この動作変更で何ができるようになったのか
この変更でユーザー側から見たSiSの変更は以下の3つです。
- Git Repositoryとネイティブに繋ぐことができるようになった（pull/push）
- Git Repositoryからアプリを作ることがサポートされるようになった
- 複数ファイルをSnowSight上で編集できるようになった
実は2つ目のGit Repositoryからアプリを作ること自体は別に今までもハックしてできてはいたのですが、ちょっと権限周りでバグっぽいのもあったりしたのでちゃんと正式にサポートされるようになったので安心です。
個人的に注目ポイントはpullできるようになったという点です。
そもそもこの変更の裏側を想像してみた
この変更に関してはアプリのファイル管理に関してのテコ入れがなされているように感じました（変更があるよの告知メールにもそんなことが書いてあった気がする）。
まずは上記のGit Repositoryのコードを利用できるようになったドキュメントを読んでみましょう。
pullの手順に関しての記述に注目してみます。以下の通りです。
- Sign in to Snowsight.
- Select Projects » Streamlit and then open or create a Streamlit app.
- On the Files tab in the database object explorer, select Pull.
実際に検証してもこの手順でpullができました。
ただ、実際には一歩手前のGit Repositoryを含めた手順まで遡っていく必要があります。
大枠ですが、以下のような流れの手順でないと反映されません。（前提としてGitHubを利用しているものとして書いています）
- GitHubに変更をpushする（ここは当たり前として）
- Git Repositoryをfetchする（このステップが必要）
- Streamlitでpullをする（これはドキュメントの通り）
つまり、Streamlitアプリのコードは実は3箇所に分かれて管理されているということで、それぞれを同期していく必要があるということです。
GitHub -> Git Repository -> Streamlit専用領域
今回の変更はこのStreamlit専用領域（名前は本当はもっと正式なのがあるかもしれない）が追加されたというところが本質的なところだと想像しています。
Streamlit専用領域（仮）が何者なのかを妄想
このStreamlit専用領域（仮）に関してより詳しくなれそうなヒントが DESC STREAMLIT コマンドの出力に隠されています。
（ここからはさらに妄想が膨らんでいるのでふ〜んそうなんだ〜くらいの軽い感じで見てください。）
live_version_location_uriという項目を見てみるとsnow://streamlit/<データベース>.<スキーマ>.<Streamlitアプリの物理名>/versions/live/のようになっています。
なんだろうこれは？と気になりますね。
他にもこんな項目もあります。
last_version_location_uriという項目を見てみるとsnow://streamlit/<データベース>.<スキーマ>.<Streamlitアプリの物理名>/versions/version$6/
（何回かpullしたのでバージョンが6になっていますが、最初は1でした）
default_version_nameという項目はVERSION$6でした。
これらの情報から推理するに、snow://というURIで管理される何かしらの内部ステージ的な何かがあって、そこにファイルが同期されるようになっているのではないかと思います。そしてバージョンがそれらのポインタ的な役割をして表出する際のファイルを管理をしてくれているのではないかと妄想が膨らみます。
今はまだversionの機能はユーザ側には提供されていないっぽいのですが、将来的にこのバージョンをSnowSightのUIとかからプルダウンとかで選択できるようになったら最高ですね。（そうなるかは知らないです。夢です。）
安心してどんどん新しいバージョンをデプロイすることができるようになってとても開発が捗ります。
（結構複雑なアプリだとデグレたりするかもしれないですし、新しいバージョンのパッケージにあげたら書き方古くて動かなくなったりとかしそうなので…そこはちゃんとテストしろよという話ではあるのですが、Streamlitにそこまで複雑な品質管理プロセスを設けたいかというと…どうかな？と思ってしまう今日この頃なのです）
現時点での使い所
将来的にバージョン管理機能が有効になってくれそうな仕込みが垣間見れた（そもそもBCRのドキュメント上はそれを匂わせまくっていた）のですが、現状はまだ利用できないです。ただ、専用領域（仮）ができてGit Repositoryとの統合が正式サポートされたので、これだけでもだいぶ運用が楽になります。
つまり現状でも以下のようなパターンは簡単に作れるようになったのです。
- 安定バージョンのStreamlitアプリ
- 最新のコミットをバンバン取り込むStreamlitアプリ
この二つのアプリを用意して提供することが比較的複雑なことをせずに実現することができるようになります。
つまりこうするのです。
- GitHub Actionsで以下の2つのワークフロー（もしくは一つにまとめてもいい）を作る
- Git Repositoryをfetchする処理（Snowflake CLIで一発なので楽）
- 特定のStreamlitアプリをpullする処理（alter stramlitコマンドで一発）
- mainブランチにマージされたのをトリガーにして上記のワークフローを順に実行していく（適宜パスのフィルターを入れる）
これで最新コミットをバンバン取り込むStreamlitアプリがガンガン更新されます。
（実際には初回の場合はcreate streamlitアプリを実行するようにしたり工夫が必要だとは思いますが細かいところは触れません）
安定バージョンは好きな時に手動でpullすればいいのです（雑）
そして手動のやつはいつかVersionの機能が開放されたあかつきにはdropしてしまえばいいのです！！（知らんけど）
Git Repositoryに連携している場合にSnowSightで編集することの是非に関して
今回の変更においてはpushもできたり、マルチファイルエディターも使えるようになっていたりします。
ただし、これは慎重に使った方がいいと思います。特にGit repositoryと連携して別のローカルのdockerなどで開発する仕組みを持っていたりする場合は気をつけた方がいいです。
というのも、コンフリクトの解消がややめんどくさくなるので、基本ブランチ切ったりしないといけないと思うのですが、ややその辺りがまだUIが洗練されていないので結局VSCodeやらCursorとかで管理した方がやりやすかったりするのです。
あと、コンフリクト起きるとSnowSight上では何にもできないので正直開発者体験が辛いので、ここは慣れたコードエディタでやるのがベストでしょう。
（一方通行の方が頭も整理しやすいですし）
最後に
SiSって気づくとあれ、こんなことできるようになってたんだ、ってなること多いので変化の激しい領域だと思います。
今後のStreamlitのバージョン管理問題に新しい選択肢を用意してくれそうな結構大きめのアーキテクチャの変更が届いたんだなと感慨にふけると共に、今後の進化にも期待しちゃいます。
最後まで読んでいただきありがとうございました！
よきSiSライフをお過ごしましょう！！
Discussion