ぼくのかんがえたさいきょうのGAS運用手法2023
前提
- ある程度以上の期間に渡ってある程度以上の人数（もちろん引き継ぎアリ、専門知識ナシ）で利用するものを対象とする
- ごく小さなGASまですべて管理対象にしようとしない
- コードの管理についてはビルドプロセスが必要なものは VCS で行えばよいが、すべて VCS に集約しようとしなくてよい（依存がなく、シンプルに function を実行してテストしやすいものであれば GAS だけで完結していてよい）
個人開発のものを個人で利用している分にはこの運用方法にこだわる必要はないが、それはその GAS を使った業務の成果が他の人にたいして影響しない場合なら問題ないという条件付きの話になる。例えば Script へのアクセス権や Script そのものを失ってもちょっと作業時間が伸びる程度、みたいなものは問題ない。
そうでないなら、どう運用していくのか、どう改善していくのか、どう引き継いでいくのかは考えなくてはいけない。もし自分の想定以上に複雑になって引き継げる気がしないという状態になってしまうのであれば、GAS 以外の手法に切り替えることも含めてより専門知識のある人にしっかり相談した方がよい。
10行程度の GAS を書いて「できたー！ わーい！」みたいな行為を咎めるつもりは毛頭ないし、そういうチャレンジ自体は賞賛されるべきと思うが、個人的にはあまり「GAS を書いて組織の業務を改善しよう」みたいなことをオススメしたいとは思っていない。自分が自分のために開発の最初の一歩を踏み出すことと組織での運用は考慮すべきことがかなり違う。
開発手法
データ構造の変更、コードの変更を加えていく際に以下のようにアプリケーション本体をGASライブラリとして管理するものとする。
ぼくのかんがえたさいきょうのGAS開発手法2023 (2023-08-21) | あーありがち
共有（管理）方法
以下のように Google Drive 上で共有、整理する。
- ライブラリ（アプリケーション）
- Google Drive 上で共有に利用するフォルダを組織で決める（Workspace全体で統一できるなら話はシンプルだが、部署内のルールなどでもよい）
- そこにライブラリ（アプリケーション）を納める ← 共有範囲に応じて閲覧権限を設定1
- 開発に関わる人に書き込み権限を渡す
- Container（データ）
- 実データに関するアクセス権限に応じて必要な人に共有する
まぁ普通の Google Drive の運用方法です。基本的に Google Drive そのもので頑張る。
組織の Google Workspace での利用であれば、組織の管理者とは話を付けておく。例えば GAS のデプロイで rollback することは可能だが、誤ってスクリプトそのものを消してしまったような場合でも30日以内なら管理者が復活できるなど、もしもへの備えのレベルが変わってくる。
ここでライブラリの Drive 内に Docs という文字が見えるが、これについては後述する。
考え方、工夫点
claspの管理機能、Script APIに期待せず、Driveで管理する
これはあくまで2023年夏時点での話だけど、Script API および clasp での GAS プロジェクト管理は以下のようにあまり現実的でない。
- GAS プロジェクトにはプロジェクトに関するメタデータを書く場所がない
- script.google.com 以下にはプロジェクトを整理するための支援機能がない（例えばフォルダ分けなど）
- clasp list には Script Editor から作った container-bound script が現れない
- clasp から create している場合は見える
- clasp list は逆に不要な Project も見える
- Drive の trash に入れても見えてしまう（どうして？）
ということで clasp は使うのであれば push / pull のみに割り切る。
https://script.google.com/ 以下で頑張ろうとするより Drive でフォルダを切って整理する、分かりやすい名前を付ける、で頑張る方がよほど管理しやすい。
Docsのcontainer-bound scriptとしてプロジェクトを作る
上にも書いたが Google Apps Script はプロジェクトそのものについて情報を書き添えておく方法がなく、管理対象としては割と扱いにくい。
- Project にはメモ蘭のようなものはない
- Drive の機能で File にメタデータを付与することは可能だが、ワンアクション余計に要求するし、シンプルに情報を見つけにくい
特に Drive API 時代のクセで standalone project にしてしまうともう最悪である。しかしライブラリとしての Apps Script は別に standalone である必要はない。これを
Docsのcontainer-boundで作ると決める
と諸々解決できる。
- Docs 側に名前、作者、狙い、使い方など自由にドキュメントを書ける
- 仮に依存ライブラリなどの関係で VCS 管理している場合はその URL にもリンクできる
- ドキュメントの編集は権限さえあれば誰でもできる2のでドキュメントそのものを改善しやすい
かなりよいことずくめだと思う。問題は Drive 上の存在としては GAS ではなく Docs であり、アイコンも Docs になるため、ライブラリ専用のフォルダに入れておかないと GAS であることが分かりにくくなる 点である。
これもあって、まずはアプリケーションそのものをライブラリとして分離し、専用の場所に置く ことが重要になってくる。
プロジェクトテンプレートサンプル
Docs の container-bound として作った GAS プロジェクトのドキュメントにはどんな内容を書いてもよいが、できるだけユーザー側の視点に立って書いてあげるとよさそう。
もしプロジェクトのコードで npm などを利用して VCS で管理せざるを得なくなっている規模なら、開発者向けの情報はこの Docs ではなく VCS に入る README.md などに書いておくので十分だろう。
<title>
# 目的
# 責任者、問い合わせ先
# 使い方
# 必要なライブラリなど
運用とは言ったが監視などの話はここでは触れていない
真面目に考えると
- Bootstrap + Library 方式である今回のベースの開発手法の場合、Bootstrap 側を GCP プロジェクトにし、Cloud Logging へ情報が流れるようにする、適切にストック（Sink）の設定をする
- そのうえでアプリケーション ( Library ) で何らかの不具合があった際に console へ warn や error などの severity で情報を吐く、その際 Boostrap がどのファイル（container）にあるのか、できれば誰が操作していたのかの情報も欲しくなる
みたいな話になってくるんだけど、これはもう普通にアプリケーションの保守、SRE などの領域の話であって、GAS 固有の話はあまりないと思う。