Github Actionsで GASのデプロイを自動化した

Editor's Notes

• #2: github actionsでGASのデプロイを自動化した話をしていきたいと思います。
• #3: 澤田史織といいます。今はログラスという会社で働いています。
• #4: 今日は、 ログラスでGASをどう活用しているのか 今までどんな方法でデプロイシどんな課題があったのか、 そこから自動化しどう改善されたか のこの3つのtopiｃについて話していきます。
• #5: GASとはなにか？ Google Apps Scriptのことで略してGASですといいます。 使ったことある方もいるかたも結構いるかもしれませんが、 スクリプト言語でもあるため、比較的手軽な開発で向きかなと思います。 googleのサービスと連携し、拡張してくれるサービスです。
• #6: GASをログラスではどのように活用しているのか
• #8: loglassでは、事業や会社のデータを一括で管理しその進捗を可視化することで より良い経営判断を推進をすること可能にすることができるSaasプロダクトです。
• #9: その中でも 会社の予算を更新するときにログラスとGoogleスプレットシートを連携させる所で利用しています。 左の画像のGoogleスプレッドシートからアドオンタブからの更新申請ボタンを押してもらう裏でGASが動作し、更新すべき予算データをログラスへ送ってくれる仕組みです。
• #10: 重要機能のひとつなので、とにかくリリースによる事故をなくしたいというのとわすれ
• #11: コレまでのデプロイ方法と課題点
• #12: 一般的なアドオンのリリースについて紹介します。 ログラスでもおなじ手法です。 アドオンへのリリースでは3段階あります。まず ソースコードをGASへpuhsし、、pushした成果ぶつに対しversionをきります。versionをGCP画面から更新することでリリースが完了します。
• #13: 今回はこの赤枠の部分を自動化したので、この部分にフォーカスして話していきます。 まず①でソースコードをGASへpushですが、 こちらはGoogle公式のcliツールを使用ししてローカルからコマンドを実行することで対応していました。
• #14: ソースコードをGASへpushするのにcliを使っています。 Google公式が作っているcliツールなのでGAsの開発する人は大体コレを使うかと思います。
• #15: コマンド実行時にjsonファイルを設置するのですが、 ここにどのディレクトリ配下をpushするかの指定と、GASのプロジェクトのIDを設定します。 検証環境と本番環境でGASのプロジェクトを分けているため、ここの向き先を変えることによりわけてデプロいができます。 がドキュメントを見るかGASプロジェクトを見に行ってIDを書き換えてpushするのが毎回手間でした。
• #16: そいう事情からいくつか課題点がありました。 ローかる環境でソースコードをpushすると、ブランチの切り替え忘れによる中途半端なソースコードのpush。や最新化忘れ等があります。 また、先程の検証環境と本番環境のID切り替えを人力でやっていたこともあり、検証環境にpushするつもりが本番にpushしてしまったりヒヤリ・ハットは何回かありました。 ローカル環境のnode versionやnpｍ cliのversionによりリリース時の事故もありました。 コレは私が踏み抜いたのですが、ある設定が1年以上前から入っていたのに、私がローカルからリリースしたら正しく適用され動作しはじめてリリース失敗したことがありました。 知っているい人いないとリリースできないという属人化が起きていました・
• #17: コレをどのように自動化したのか
• #18: Github actionsへ移行しました!
• #19: GASのデプロイ自動化するのに気をつけた3点紹介します。
• #20: ①テストとデプロイのタイミングを制御しました。 デプロイは、developマージ時に検証環境へdeployする masterマージ時に本番環境へdeployする 仕組みにしています。
• #21: GASのテストはブランチ関係なく、pushされた場合にテスト実行するようにしています
• #22: ②つめは、検証環境へpushするのか本番環境にpushするのかでプロジェクトのIDが変わるので画像のように設定を入れています。 branchでの制御をしているためどちらか一方の設定が適用される様になっています。
• #23: ③ GASの認証です。 GASへソースコードをpushする時にまず、Googleアカウントでの認証が必要になります。 ローカルで実行するとブラウザに遷移しブラウザ上で アクセプトが必要になります。 これがCIで毎回動かすとなると一生終わらないjobに 1習慣でアクセストーくん期限が切れてしまうので、ただ、コマンドを動かしていればよいわけではないため、何かしら対応しなければ。、と
• #24: どうしよう・・・
• #25: GASは一度認証すればずっと使い続けられる仕様 認証するとローカルにjsonファイルが作成され、そこにトークンが書かれている。 仕組みとして、アクセストークンの期限が切れていたらリフレッシュトークンでアクセストークンを再取得する。リフレッシュトークンも期限がないようでした。 一度ローカルで認証して、 ローカルに作成された認証用のjsonファイルをCI上に設置し、トークンをgithubactionsのシークレットに設定しました。 他に人も悩んでいるようで、
• #26: 地味に大事だと思っています。slackの通知も追加しました。
• #27: ということで上記の問題は一通り解決でき、安心安心
• #28: まだやりきりれていないこととして、アドオンリリース。GCP画面から②のversionをコピペして保存するだけなのですが、自動反映して欲しいよねって声聞こえてきたので、対応しようと思っています。
• #29: おわり。