(プラットフォームAPI＋GAS開発番外編)claspで多人数開発する際の注意点
こんにちは！株式会社スマレジ、開発部のmasaです！
コロナの勢いがまた増してきた今日この頃ですが、皆様はいかがお過ごしですか？ スマレジでも徐々にリモートの日数を増やして、完全自粛になっても業務を止めないように、取り組みを強化しています。 今回はclaspを使った開発を行う際に、masaが苦労したことや僕らは大丈夫だったけどこれやばいなー」と感じたことをお伝えしようと思います。
claspってなんだっけという方は、過去記事をご覧ください！
claspを用いた多人数開発の注意点
1. clasp pushは全更新であることに注意する
例えば、gitを導入して、AさんとBさんが同時に別々のツールを開発していたとします。 Aさんが動作確認のために１度ソースをGASにpushした際、下記のようなことが発生します。
- Bさんのソースがpushするディレクトリになかった場合
- 環境にBさんのソースがあった場合、消えてしまいます。
- Bさんのソースはあるけど、古かった場合
- Bさんのソースは古いソースに置き換えられます。
clasp pushはバージョン管理ツールとは異なり、.clasp.jsonで指定されたpush対象のフォルダで、プロジェクトを完全上書きしてしまうため、
ツールのデプロイ時には、それぞれの開発者ごとに申し合わせをする必要があります。
頻度が少ない・ローカルでスプレッドシートのデータを取得できる環境ならいいですが、 そうでない場合は悲惨です。
回避策 clasp pushを直接使うのではなく、デプロイバッチを作成する。
デプロイバッチと言っても、最低限のことは下記の内容だけです。
clasp pull # 自分の変更分だけをビルドする clasp push
要は「pushする前にその環境の最新ソースを取ってきて、自分の変更分だけをビルドすればいい」だけです。 ただ、GASのローカル開発は、AltJS系やWebpackの利用があるため、ビルド自体もバッチ化して、 自分のプロジェクト分だけ、ビルドできるように切り分けしてあげる必要があります。
また、もしgitlabを使っている場合、１ツールごとにプロジェクトを分けられたらある程度回避できるのですが、 ツール類は１つにまとめておきたいですし、プロジェクト数が増えるとgitlabも重くなっちゃうので、 バッチ対応が良いのかなと思っています。
2.マニフェストファイルの管理
claspに複数ツールを載せる場合、マニフェストファイルと呼ばれるサービスの設定ファイルをツール間で共有することになります。
これが曲者なのが、マニフェストファイルを更新すると、ユーザのOAuth承認がクリアされ、再承認が必要になるのです。 スマレジのようにGSuiteを入れている場合は良い（普通の承認画面が出るだけ）のですが、それ以外の場合、下記のブログで紹介されているように、 「まるで怪しいアプリであるかのような警告」が出てしまうんですね...
これ、開発者間で事前に「マニフェストファイル変えるよー」というやりとりがあった場合は、 利用者からの問い合わせもすぐに回答できますが、 編集した人が、この現象を把握していない場合、問い合わせはあがるし、でも自分は知らないし...といったことになることが予想されます。
回避策はなし 報連相を徹底するよう、リリースフローを最初に決めて、リリース前に通知しておくこと
GASを使うケースの多くは会社内でのツール開発や、僕の作っている売り上げ通知アプリのように、外部APIとスプレッドシート連携（これも広い意味では、社内ツール）なので、問い合わせ元は自身の所属・受注している会社内になります。
なので、逆に言えば開発側で音頭をとって、お知らせフローを作ってしまうこともできるわけです。 マニフェストファイルの変更自体は避けて通れませんし、毎度同じ質問を受けるのは非生産的なので、リリースフローを明確化しておきましょう。 （社内ツールだと、この辺りがおざなりになりがちですが、全体業務の最適化のために社内ツールを作っているわけなので、逆に問い合わせを増やしたら本末転倒です）
3. プロパティサービスの管理
2と似ていますが、プロパティサービスもツール横断で使用するわけなので注意が必要です。 ※ プロパティサービスについては過去記事をご覧ください。
個人的に今までひやっとしたのは、下記の事象です。
- 相談なく汎用的な隠蔽したい値（パスワード）を各々が勝手に入れて、同じ意味合いのプロパティサービスが多発...
- 変数名が衝突し、特定のタイミングだけ中身の値が、別ツールのものになってしまう。
1の回避策 ダイレクトにプロパティサービスへアクセスするのではなく、共通のgetter,setterを作成し、衝突しないようにする
例えば、プロパティサービスにプログラムから値をセットする(この場合は変数名nameにvalueをセット）場合は、下記のようなソースでできます。
PropertiesService.getScriptProperties().setProperties({"name":"value"});
ただ、これを直接使うのではなく、
// 例として記載しています。 function setProp(name, value, toolName) { /************************ 値のチェック処理 *************************/ PropertiesService.getScriptProperties().setProperties({toolName + "_" + name:value}); }
こんな感じで、ツール名を変数名につけて、衝突を避けるようにしてあげることができます。
2の回避策 共通のプロパティサービス設定ファイルを作成する
ドキュメント管理でもいいですが、ツールにそんなに工数は使いたくないので、 パスワードのような長期的に保存したい値については、ツールごとに決まった名前のjsonファイルなどに書き出しておいて、 ビルド時に抽出&１の回避策で書いたような、衝突回避処理を入れてあげてgetterで撮るようにしてあげるなどの方法があり得ます。
１つのファイルにみんなでガンガン追加していく方法もありますが、それだとgit側がコンフリクト祭りになるので、 名前を決めたファイルに各々が描き出すのがおすすめです。
以上、 clasp開発で気がついた・困った点についてまとめてみました。 皆様もclaspでのツール作成時には、お気をつけください。
