GitHubActionsに対応し、ブログ記事の投稿負担をさらに減らしました！

こんにちは！LinkFarm Tech. の Shu MASUI です。

今回は、このHPに新たな技術として、GitHub Actions を導入し、ブログ記事の投稿負担を減らした取り組みについてご紹介させていただきます！

ぜひご覧ください！

サムネのロゴはGitHubの公式キャラクターのロゴです

ライセンスはこちら

目次
CI/CDの必要性
私たちが使っているActionsのWorkflow
- buildとdeployを分けることによって、どちらかが失敗した場合の無駄なActions消費を避ける
- FirebaseへのdeployをサービスアカウントとWorkloadIdentityProvider Pool, Providerを用いて行なっていること
これで、実際の開発フローはどうなった？
つまづいたポイントは？
- GCPへのサービスアカウントの登録
- permissionsの追加忘れ
でも逆にいうと『これぐらい』でした。
さいごに
今後のスケジュール

CI/CDの必要性

結論から言うと、

将来的にメンバー誰でも編集できるようにするとなった時に、絶対に必要

になるという必要性です。

現在、弊グループHPはAstroというフレームワークを利用しています。

AstroはSSRモードもありますが、いちばんの強みは 事前build です。これがあるおかげで、低コスト運営ができています。

そうなった時、必要になってくるのは build という作業と deploy という作業です。

いわゆる、CMSをこうやって実現しているわけです。

ですが、こんな難しい作業いちいち説明してられませんし、コード管理の点においても、非常に危険です。そのため、Keystaticという編集ツールを導入しています。

であれば、話は簡単で、あとは build & deploy 部分を自動化すれば、もっと安全い投稿フローが出来上がるというわけです。

このために必要な作業が CI/CD というわけですね。

捕捉： CI/CDについて知りたい方は以下のページがわかりやすいです！

CTCテクノロジー様の解説ページに飛びます

私たちが使っているActionsのWorkflow

まずは、どんなファイルを用いて管理しているかを紹介します。

name: CI/CD Pipeline
on:
    push: 
        branches: [main]
jobs:
    build:
        runs-on: ubuntu-latest
        steps:
            - name: Checkout Repository
              uses: actions/checkout@v4
            - name: Setup Node.js
              uses: actions/setup-node@v4
              with:
                node-version: 22
                cache: npm
            - name: Install Dependencies
              run: npm ci
            - name: Build Astro
              run: npm run build
            - name: Upload build artifacts
              uses: actions/upload-artifact@v4
              with: 
               name: dist-artifacts
               path: dist
    deploy:
        runs-on: ubuntu-latest
        needs: build
        permissions:
            contents: read
            id-token: write
        steps:
            - name: Chekout Repository
              uses: actions/checkout@v4
            - name: Download build artifacts
              uses: actions/download-artifact@v4
              with:
                name: dist-artifacts
                path: dist
            - name: Authentication for Google Cloud Platform
              id: auth
              uses: google-github-actions/auth@v2
              with:
                workload_identity_provider: '${{ secrets.WORKLOAD_IDENTITY_PROVIDER }}'
                service_account: '${{ secrets.SERVICE_ACCOUNT }}'
                create_credentials_file: true
                export_environment_variables: true
            - name: Deploy to Firebase Hosting
              run: npx firebase-tools deploy --only hosting

拘っているポイントとしては次の2点です。

buildとdeployを分けることによって、どちらかが失敗した場合の無駄なActions消費を避ける

これは、Actionsの Jobs の性質を活用して、処理を分離させるということにチャレンジしています。

Jobsは並列処理が基本ですが、needsを利用することでjobs間の依存関係を明記することができ、一列にすれば、逐次処理的なことになります。

この性質を利用して、buildが失敗すればdeployは挑戦しないというワークフローを実現しています。これは、 Actionsの実行時間が決まっている 、私たちのような開発者にとって、大切なコスト削減です！！

FirebaseへのdeployをサービスアカウントとWorkloadIdentityProvider Pool, Providerを用いて行なっていること

これは、GitHubActionsの実行環境上へ権限を与える仕組みを汎化しているということになります。

FirebaseExtended というFirebase専門のactionsを使えば、こんなことはしなくていいのです。ただし、Hostingのみを使うのであれば、です。しかし、将来的にStorageなどを活用する見込みを持っていますので、現時点から、拡張性を持たせたいと考えていました。

ですから、Firebaseサービス全体へのアクセスを OpenIDConnect を用いて行うために、登録が必要となったわけです。そこで、GCP自体へのサービスアカウント経由に絞って、そのサービスアカウントの認証をgoogle-github-actions/auth@v2によって、実現しています。

すると、 サインイントークン が自動的にJobsを行なっているプラットフォームに注入されるので、いわゆるgcloud auth loginを実行した後と同じ環境が整うわけです（正確には少し違います）。

そのため、デプロイ自体はnpx firebase-tools deploy --only hostingのみで完了しています（いつも通りのコードですね）！

補足

firebase-toolsは本来インストールしないと使えないプロダクトですが、npxを使えば、普通にインストール不要で使えます。

その代わり、ロード時間が増えます

ただ、Actionsは一回限りしか使わないので、npxで十分です。

これで、実際の開発フローはどうなった？

これまでの開発フローはこんな感じでした。

コードを書く
テストを通す
pushする
PRする
mainへマージする
pullする
buildする
deploy飛ばす

一応、mainからしかdeployしないという開発ルールを敷いていましたから、このようにめんどくさくなっていたわけです。 PRとか個人開発でしないでいい気はしますが、今後のため、していました。

それが、このようになりました。

コードを書く
テストを通す（ここは自動化していません、大変なので）
pushする
PRする
mainへマージする
Actionsがdeployまでしてくれる

めちゃ楽ですね。実は、コードを書く以外は、GUI上でできる作業なんです。なので、一気に作業負担が減りました。

また、実行時間としては平均してbuild: 20sでdeploy: 40sほどでした。もうちょっと早くしたいところではありますね（何かいい方法はないものか）…

つまづいたポイントは？

GCPへのサービスアカウントの登録

ここがいちばん難しいです。 ActionsのコードはDockerFileに近い ので、そんなに難しくないのです。

ですが、GCPは違います。 IAMとかOIDCとか、Provider とか色々理解していないと、かなり厳しかったです。 Webの理解がセキスペの合格止まりで、実装したことなかったので、かなり応えました…！！

permissionsの追加忘れ

なんか、deployだけ止まるなと思っていたら、

deploy:
    runs-on: ubuntu-latest
    needs: build
    # ここから下
    permissions:
        contents: read
        id-token: write

忘れてました！！一応意味としては、OICDトークンをGitHubActionsのWorkFlow上から作成して良いということを伝えるのがid-token: writeです。また、Jobsを分ける関係で、一時ディレクトリを使っていたので、そのディレクトリを読み取って良いということを伝えるのが、contents: readです。

参考にした記事

Qiita の記事に飛びます

でも逆にいうと『これぐらい』でした。

ものすごく簡単になったなとおもいます！

さいごに

CI/CD は小規模プロダクトほど導入するべきだと思います。開発のスピード感や品質を、一気に本番レベルまで押し上げることのできる、魔法のような技術だと感じていますし、 AI開発との親和性が高い のも魅力です。

今後は、テスト　などの体制を整え、他の　CI/CDパイプライン　構築にも手を出していきたいです。

本番環境のCI/CD構築は初めてでしたが、非常にいい経験でした！

皆さんもぜひお試しください！

今後のスケジュール

7月〜9月：準備期間・活動を一緒に支えてくれる協賛パートナーの募集
9月：現地での田植え・苗植えイベント（第1回）
10月〜：奈良の農業とスマート技術を学ぶ農業講座
翌年2月：みんなで収穫し、美味しい料理を作って食べる収穫祭

皆さんと一緒に、新しい農業の形を作っていけることを楽しみにしています！プロジェクトへの参加やご支援に興味がある方は、ぜひお気軽にお問い合わせください。

LinkFarm Tech. 一同

目次