CI/CD 実践ガイド｜iOS開発チーム向け安定・効率化の秘訣と最適ツール選定

閲覧数: 7,584+

正體中文 简体中文 English 日本語

本記事は AI による翻訳をもとに作成されています。表現が不自然な箇所がありましたら、ぜひコメントでお知らせください。

記事一覧

---

CI/CD 実践ガイド（1）：CI/CD とは何か？CI/CD を活用して安定かつ効率的な開発チームを作るには？ツールの選び方は？

App（iOS）チームを例に、ゼロからCI/CDの基本と導入後に得られる実質的な価値をご紹介します。

Photo by Leif Christoph Gottwald

2026年アップデート — GitHub Actions（Self-hosted Runner含む）の価格変更

TLDR — 2026年1月1日よりホスト型ランナーの料金を引き下げ、2026年3月1日よりセルフホスト型ランナーは1分あたり0.002ドルの課金を開始します。ほとんどのお客様の請求額に変化はありません。パブリックリポジトリでのActionsは引き続き無料です。

GitHub 2025/12/14 最新のお知らせ ：

• 2026年1月1日：GitHub-hosted Runnerの料金が最大39%割引され、より安くなりました。

• 2026年3月1日：Self-hosted Runnerの利用にはサービス維持費が追加で必要で、1分あたり0.002ドル（OS問わず）、つまり500分で1ドルかかりますが、現時点では依然としてお得です。 ️

• Publicリポジトリは引き続き同じ無料枠が維持されます。

GitHub もGitHub Actionsの機能強化により多くのリソースを投入します：

• Scale Set Client： Self-hosted Runner の オートスケーリング を簡素化。

• multi-label：再起動をサポート、Runnerのラベル体験を改善。

• Actions Runner Controller (ARC) の更新：設定、可観測性、バージョン管理の向上。

• Actions Data Stream： ワークフローやランナーのイベントデータをほぼリアルタイムでストリーミング提供し、監視や分析に利用します。

公式の価格計算ツールも更新されました ：

• GitHub Hosted Runner — macOS 3コア(M1): $0.062 USD/分、1,000分で $62 USD

• Self-Hosted Runner — $0.002 USD/分、1,000分で$2 USD

最新モデルのMac Mini 10-core(M4)を約600ドルUSDで購入し、オフィスにSelf-hosted Runnerとして設置すれば、約1年で元が取れます。性能が高く速い上に、使用量はほぼ無制限で（運用コストはほとんどかかりません）。

古いM1 MacBook ProをRunnerとして利用でき、コストは0円です。

*上記は電気代やインターネット料金を考慮していません。

はじめに

二つの異なる開発チームでのApp CI/CD構築経験を経て、最近ようやく「なぜ行うのか」から「どう行うのか」までの過程を整理する時間ができました。最も標準的なCI/CDワークフローとは限りませんが、チームが導入を始め、製品の安定性と開発効率を向上させるための参考になる出発点であることは間違いありません。

章節

本シリーズ記事は「CI/CDとは何か、どんな価値をもたらすか」から始め、次に「GitHub Actions + self-hosted Runnerを使ったCI/CD環境の構築」を手順を追って解説し、「App開発を例にCIとCDの実際の導入」を行います。最後に「Google Apps Script Web AppとGitHub Actionsを組み合わせて、チーム間で使いやすいAppパッケージングプラットフォームを作る方法」も紹介します。このシリーズが皆さんのお役に立てれば幸いです。

• CI/CD 実践ガイド（1）：CI/CD とは？CI/CD を活用して安定かつ効率的な開発チームを作るには？ツールの選び方は？

• CI/CD 実践ガイド（二）：GitHub Actions と self-hosted Runner の使用と構築完全版

• CI/CD 実践ガイド（3）：GitHub Actions を使ったアプリプロジェクトの CI と CD ワークフローの実装

• CI/CD 実践ガイド（4）：Google Apps Script Web App を使って GitHub Actions と連携し、無料で使いやすいパッケージングツールプラットフォームを構築する

最終成果

無駄な話は抜きにして、まずは最終結果をお見せします。

Demo PR

Demo Web App (初めてご利用の方は下記のチュートリアルをご参照ください)

CI/CD — すべてGitHub Actionsで開発、メンテナンスしやすく拡張も簡単。

CI:

• PRを送ると自動でユニットテストが実行される

• 変更されたファイル範囲に応じて対応するテストを実行する

• テストが通過した後にのみPRをマージ可能

CD:

• Google Apps Script Web App（CDパッケージングインターフェース）は、エンジニア、QA、PMがパソコンやスマホからアプリをパッケージングできるサイトです。

• GitHub Actions Self-hosted Runner は自分のマシンで CI/CD を実行し、使用量無制限です。

• Firebase App Distribution APIを連携して、ビルドしたテスト版のダウンロードリンクを直接取得します。

自動化 :

• PRを作成すると自動で自分に割り当てる

• PRを作成するときにレビュアーをランダムに自動割り当てる

• PRサイズラベルの付与

デモWebアプリ/プロジェクト

• Online Demo 初めてご利用の方は、下記の図の認証方法をご参照ください（デモアプリ専用）：

CI/CD とは何ですか？

ストーリー — CI/CDなしの開発プロセス

CI/CDとは何かを語る前に、「CI/CD」という言葉を一旦置いておき、何のワークフローも導入していないスタートアップの開発チームがどのように働いているかを振り返ってみましょう。大まかな流れは以下の図の通りです：

1. 製品にバグがあり、Developer T は main ブランチから fix/bug-c ブランチを切って修正し、修正後に main ブランチへマージしました。

2. 続いて Developer Z は main ブランチから feature/a ブランチを切り、要件Aに取り組みましたが、途中で機能がおかしいことに気づき、調べたところ現在の機能が壊れており、テストも失敗していることが判明しました。そこで Developer T に修正を依頼しました。

3. すべての開発が完了した後、Developer Z は 自分のパソコンでビルドしたバージョンをQAに渡し、テストを行い、修正とビルドを何度も繰り返す。最終的に問題がなければ、機能を main ブランチにマージします。

4. すぐにスプリントの終わりが来て、ユーザーにリリースするためのパッケージ作成が必要になります。Developer Z は 手元の作業を一旦中断し、main ブランチからパッケージを作成してQAに回帰テストを依頼します。同様に 問題の修正と再パッケージ作成を繰り返し、完了後にパッケージを審査に提出します。

5. Apple/Googleの審査が完了した後、ユーザーにリリースされます。

問題

以上のストーリーから、二つの大きな問題点をまとめることができます。

Question 1: 現在の正しい機能変更に対して統一された検査メカニズムがありません。

• コーディングスタイルに合わないコードでもマージ可能

• ビルドが通らなくてもマージできる

• 変更後、基本的なユニットテストや重要なチェック項目が通らなくてもマージできる

• 私の環境では動作していますが、他の人の環境では必ずしも正しく動作しない場合があります。

• 他の開発中のメンバーに影響を与える

Question 2: パッケージング作業に多くの人手と時間を費やしている。

• パッケージングはエンジニアの手作業で行うため、現在の開発作業が中断される。

• パッケージングと開発を往復する際、フローの切り替えコストが非常に高い。

• パッケージングの待ち時間中は他の開発作業ができない。

• エンジニアの時間コストはつまりお金です。

• 手動操作はミスが発生する可能性があります。

• QAはエンジニアにパッケージングを依頼する（やり取りが発生）。

CI — Continuous Integration 継続的インテグレーション

対応する Question 1「継続的インテグレーション」は、すべての変更が統一された環境で自動的にビルド＆テストされることを目的とし、本番環境に入る前にすべてのテストケースを通過し、チームの規範に合致していることを保証します — 「継続的に正しいコードが本番環境に統合されることを自動的に確保する」ことです。

また、Nightly Buildやより多くの自動テスト工程を追加して、安定性を確保することもできます。

CD — Continuous Delivery / Deployment 継続的デリバリー/デプロイメント

Question 2「継続的デプロイメント」は、CIプロセスで異常がなかったコード変更を、自動的にパッケージ化して内部テスト（QA、デバッグ、ステージング、ベータなど）や外部リリース（本番、リリースなど）へ展開する煩雑な作業を完了させることを目的としています。

• Continuous Deployment: 本番環境への完全自動デプロイ

• Continuous Delivery: ステージング/デバッグ環境への自動デプロイのみ行い、問題がないことを手動で確認してから本番環境へデプロイする方式

App開発のシナリオに応じて、よりContinuous Delivery（継続的デリバリー）に近いです。私たちは、Appが最終的にリリースされる前に、人の手で問題が完全にないことを確認してから公開し、リリースのタイミングと機能の正確性を確保したいと考えています。

ストーリー — CI/CDを通じて安定かつ効率的な開発チームを作る

振り返って私たちのストーリー、CI/CD導入後：

• CI
  全員の変更は自動テストの検証を通過してからメインブランチにマージされる必要があり、Nightly Buildによる定期的な自動テストを追加して安定性を向上させています。

• CD
  統一してCDパッケージングを使用することで、Developer TとDeveloper Zは業務開発に完全に集中でき、手動でのコミュニケーションや操作ミスを減らせます。

チームの作業効率と製品の安定性 🚀🚀🚀🚀🚀

CI/CD の価値

アジャイル開発の核心理念である「小さなステップで素早く進み、迅速に反復する」ことに対して、CI/CDは「頻繁で継続的な機能の反復」の安定性と作業効率の基盤を提供します。

自動で統一された検証の反復結果

• すべての調整が正しい期待結果に合致し、他の機能やメンバーに影響を与えないことを確認する

面倒なデプロイ作業の自動化

• チームメンバーが主要な業務開発に集中できるようにし、手動操作のミスを減らす

CI/CD の効果

2021年にPinkoiで行った講演「2021 Pinkoi Tech Career Talk — 高効率エンジニアチーム大解密」を振り返ると、内容はほぼ同じで、「自動化、人と人の依存を減らす、主要業務に集中する」という点に尽きます。CI/CDの導入もまさにこの三つの方向に合致しており、同じ方法で効果を見積もることができます。

もう一つ再度強調したいのは、心の切り替えコストです：

私たちが一定時間作業を続けると「フロー」状態に入ります。この時、思考や生産性がピークに達し、最も効果的な成果を出せます。しかし中断されると、再びフローに戻るまでに時間がかかります。ここでは30分を例とします。

CI/CDがない場合のシナリオは以下のようになります： 多くの時間を費やして問題の原因を特定し、修正のためにコミュニケーションを取る（CI）、QAやPMがエンジニアにテスト版アプリのビルドを依頼する（CD）。

CI/CD 効果の見積もり

チーム人数 6人 / 1ヶ月単位で計算

ここでは月単位を基準とし、CI/CDプロセスがない場合、毎月4回主ブランチが誤って壊れる問題が発生し、その後の修正やコミュニケーションに約720分を要すると仮定します。さらに、毎月のテスト版や正式版のビルド、および手動操作によるミスの可能性を含めると、合計で約1,010分かかります。エンジニアの月給を8万円とすると、毎月約1万3千円のコストが無駄になっています。

ここで見落としていたのは、2026–03–01以降、Self-hostedランナーに毎分0.002ドルの維持費が発生することで、500分実行すると1ドルの支払いが必要になることです。

CI/CD 構築コスト

• 人件費用：
  本シリーズ記事に基づく構築では、約1人が10日間 = 4,800分 を投入する必要があります。(~= NT$36,384)

• 設備と実行コスト：
  GitHub Actionsのself-hosted Runnerを使用する場合、初期に1〜2台のMac Miniを購入するか、既存の古くなったMacBook ProをCI/CD Runnerとして利用できます。
  6人チームで新品のMac Miniを1台購入する場合の例：32G RAM M4 Mini（= NT$40,900）

総費用は約 NT$80,000 で構築でき、約半年後に効果を享受し始めます。

声明： ここでは一つの効果計算方法を示しただけで、必ずしも最も正確なものではありません；あくまで管理層がCI/CDの効果を理解し、意思決定と推進の許可を得るための概念提供です。

CI/CD のツール選択

クラウドサービス Bitrise / XCode Cloud

• Bitrise： 初期はAppのCI/CDを提供するクラウドサービスとして有名で、私が初めてCI/CDを触ったのもBitriseでした。直感的に操作できるステップ編集ツールがあり、AppのCI/CDプロセスを素早く設定できます。
  欠点： 初期は月額99ドルの定額制でしたが、AppleのMシリーズプロセッサーが登場した頃に従量課金制（養套殺）に変更されました。その時はチームの利用量で月に最低500ドルかかる見込みだったため、GitHub Actionsに移行しました。
  しかし最近公式サイトを見ると、現在は1アプリ／1同時実行／定額制／月額89ドルのプランが提供されています。

• XCode Cloud： 100時間 / 1ヶ月 / $50ドル、利点はXCodeやApp開発と高度に統合されていること；しかし欠点としては、Androidには対応しておらず、一部のカスタマイズが難しい点があります；ただし、純粋なiOSの小規模Appであれば再度直接利用を検討します。

クラウドサービスの「囲い込み」が怖いため、制御を自分で持ちたいので、オンプレミスサービスを検討しています。

ローカルサービス Jenkins / GitHub Actions / Gitlab CI/CD

• Gitlab CI/CD：
  GitHub Actions よりも早くリリースされ、機能もより充実していますが、私たちのプロジェクトは GitHub 上でホスティングされているため、Gitlab CI/CD は検討しません。ただし、両者の機能は似ているため、本シリーズ記事では GitHub Actions を例に説明します。

• GitHub Actions
  GitHubが2018年にリリースしたCI/CDサービスで、GitHubプロジェクトと直接連携しています。ここ数年で機能が継続的に改善され、多くのパッケージ化されたステップ（Marketplace）がすぐに利用可能です。self-hosted runnerにも対応しており、自分のマシンを使って無制限に実行できます。（いわばハイブリッドクラウドです）

• Jenkins：
  CI/CD 専用のオープンソース無料ツールで、古いですが機能は強力です。アプリケーション層のタスク設計や権限管理から、基盤サービスの実行までJenkinsが全てカバーします。同様にPluginsが利用でき、初期のDevOps CI/CDには必須のツールです。

Jenkins v.s. GitHub Actions

TL;DR

専任のDevOps担当者がいないAppチームでは、App開発者がゼロからJenkins環境を構築・運用するのは難しく、扱える人も少ないためネットワークセキュリティの問題も起こりやすいです。GitHub Actionsを直接選ぶことで、App開発者はCI/CDのフロー設計に専念でき、公式ドキュメントを軽く確認しRunnerの起動方法を覚えるだけで、無料で安定かつ安全なCI/CDサービスを素早く構築できます。

以下はAppのCI/CD構築を出発点とした比較であり、すべての技術シーンに適用されるわけではありません。

構築と保守の難易度 Jenkins »> GitHub Actions

ここでは、あまり専門的でない構造の階層図を使って両者の違いを説明します。Jenkinsは前述の通り、上から下まで全機能を包含しているため、自分で構築すると非常に複雑になります。一方、GitHub ActionsはGitHub上でYAMLのワークフローを書くだけで済みます。ローカルマシンにはGitHub self-hosted Runnerを登録するだけ（5つのコマンドで完了）で、GitHubが自動的にタスクをローカルマシンに割り当てます。GitHub ActionsやRunnerのバージョンアップやタスクの割り当て問題はすべてGitHubが管理するため、私たちは対応不要です。

もう一つ厄介な点は、JenkinsがGitとは独立したサービスであり、API（例：GitHub API/WebHook）を介して連携する必要があるため、設定がさらに複雑になることです。

以前も身近なiOS開発者（約30名）に調査を行ったところ、Jenkinsを理解しているのはごくわずか（2名）で、GitHub Actionsを使っている人はそれ以上（10名以上）でした。やはりYAMLを書くだけでCI/CDのタスクが完了するのが理由です。

学習難易度 Jenkins »> GitHub Actions

同様に、公式ドキュメントを参照してGitHub Actionsで使えるYAMLコマンドとローカルで自分のRunnerを起動する方法を学ぶだけで十分です。

安定性 GitHub Actions > Jenkins

この点については、GitHub ActionsがJenkinsよりやや優れていると感じます。

Jekninsはシステムのアップグレードや競合するプラグインのインストールによってサービスがクラッシュする可能性があります（ただし、問題なく動作している場合は基本的に触らなければ問題ありません）。

GitHub Actions は GitHub サービスステータス に依存しているため（GitHub がダウンすると連動してダウンします）が、発生頻度は低く、平均稼働率は99.9%を維持しています。問題が発生しても対応せずに修復を待てばよいです。

セキュリティ GitHub Actions > Jenkins

GitHub Actions/Runner サービス自体は GitHub がメンテナンスと自動更新を行っているため、Jenkins のように手動で更新する必要があるよりも安全であると考えられます。

また、JenkinsとGitHubの間でAPI/WebHookのポートを開く必要があり、比較的リスクがあります。GitHubとGitHub Actionsの間はシームレスに統合されており、GitHub Actionsとself-hosted Runnerの間はオブザーバーモードです。self-hosted RunnerはGitHubからタスクを取得して実行するため、Runner自体が外部向けのポートを開く必要はありません。

しかし、完全に閉じたネットワーク環境の場合、Jenkinsの方がGitHub Actionsより安全です。

権限管理 Jenkins »> GitHub Actions

この点は特に比較する必要があります。Jenkins は別途アカウントのログイン権限を設定して管理できますが、GitHub Actions は直接 GitHub リポジトリと連携しているため、リポジトリの権限を持つ人のみが使用可能です。

そのため、後半の記事ではGAS Web Appを使ってチーム間の操作プラットフォームを構築しています。

JenkinsよりGitHub Actionsのほうが広く使われている

完全な DevOps チームがある場合、間違いなく Jenkins を選ぶでしょう。なぜなら、他の分野（例えば Web、バックエンド、Java など）では、Jenkins が最も長く運用され、多くのプラグインが使いやすく、すべてのチームが利用できる統一された CI/CD サービスを構築して管理しやすいからです。また、バックエンドのデプロイ完了後にフロントエンドを自動デプロイするような複雑な CI/CD シナリオにも対応可能です。

GitHub Actions は後にリポジトリ間での Actions/Runner もサポートするようになりました。

サードパーティ製プラグインの豊富さ Jenkins > GitHub Actions

数の面ではGitHub ActionsがJenkinsより多いですが、JenkinsのCI/CD機能はより深く強力であり、GitHub Actionsは多くが単なる自動化機能に過ぎません。

機能の深さ Jenkins »> GitHub Actions

この点は比較できません。Jenkinsはほぼ20年の実績がありますが、GitHub Actionsはまだ多くの機能を補う必要があります。例えば、権限管理、Secret管理（現状はテキストのみ対応で、鍵ファイルは先にテキスト化が必要）、Cache/Artifactは現在クラウドのみ対応、などです。

さらに、GitHub Self-hosted Runner は Docker or k8s もサポートしています。

カスタマイズの深い Jenkins »> GitHub Actions

Jenkinsは最初から最後まで自分たちで管理するため、カスタマイズの自由度が高く、システム全体に影響を与えることができます。一方、GitHub Actionsはアプリケーション層でのステップごとのカスタマイズに限られます。

例えば、現在の GitHub Actions に内蔵されている Artifacts は self-hosted をサポートしていないため、ステップ内で sh を使って別のディレクトリにコピーするしかなく、Artifacts を自由にカスタマイズして実装することはできません。

App CI/CD の場面では、高度な機能はあまり必要ありません。

使いやすさ GitHub Actions »> Jenkins

インターフェース上、GitHub Actionsは新しいツールであり、Jenkinsよりも使いやすいです。スクリプト設定では、JenkinsはPipeline ScriptをJenkins上に保存しますが、GitHub ActionsはYAMLファイルをプロジェクトのGitで管理するため、Jenkinsより設定が簡単です。

費用リスク Jenkins > GitHub Actions

Jenkinsは完全にオープンソースで無料で利用可能ですが、GitHub Actionsは一部オープンソースであるものの、ジョブの割り当てと実行はGitHubのクローズドなSaaSサービスです。現在の方針では、GitHub Actions自体は完全無料で、GitHub Runnerの利用にのみ料金が発生します。self-hosted Runnerの利用は【2026年3月1日以降、1分あたり0.002米ドルの維持費用が必要】です(https://resources.github.com/actions/2026-pricing-changes-for-github-actions/){:target=”_blank”}。なお、Publicリポジトリには無料枠があります。

Google Apps Script Web App の用途と選択理由

もう一つのツールの選択肢は Google Apps Script Web App です。これは、GitHub Actions に標準搭載されているフォーム機能があまりにもシンプル（エンジニア向けのインターフェースで静的のみ）であり、実行権限が GitHub リポジトリに結びついているため、他の職能パートナーに提供する際に非常に面倒になるからです。

以下の通り：

CDのパッケージングでは、操作担当者にリリースノートなどの情報を入力してもらいたい。

そのため、他のメンバーやエンジニア自身がより使いやすいように、「インターフェース」ツールが必要です。

必要な状況：

この使いやすい「インターフェース」で必要な情報を入力し、プロジェクト管理ツール（例：Jira、Asana）からタスクを取得したり、GitHubから直接PRリストを取得して、プルダウンメニューで選択後に送信します。さらにGitHub APIを通じてGitHub Actionsをトリガーし、ビルドを実行します。

Slack

初めてCI/CDを導入した際、Slack APIを連携して以下のような効果を実現しました：

https://slack.com/intl/zh-tw/blog/productivity/workflow-builder-tools-automation-examples

• パートナーはSlack内のフォームに情報を入力し、CDパッケージのトリガーを実行し、Slack通知を受け取ることができます。

操作が非常にスムーズで、日常のオフィスツール上で統一されている（SSOT）ため再学習は不要です。しかし、その裏には 開発と保守のコストが非常に高い という問題があります。その一因として、Slack Outgoing-Webhook APIが非常に厳しい応答時間（3秒以内）を要求しているため、基本的にFAASサービスを使った簡単な連携（例：Cloud Functions、GAS、Lambdaなど）は除外されます。

以前の方法は、自動化とバックエンドに興味があるメンバーがKotlin+ktorで一式のバックエンドサービスを開発し、GCP上にサーバーを立ててSlackと連携させていました。

開発と保守のコストが非常に高く、引き継ぎも難しい。

Google Apps Script — Web アプリ

以前に「 Google Apps Script Web App フォームで Github Action CI/CD を連携する方法 」を紹介しました:

Demo Web App Form URL

Google Apps Script — Web App を使う利点は：

• ウェブサイト Web

• Google Workspace 企業アカウントの権限管理と同様に、組織内の Google アカウントのみがアクセス可能に設定できます。

• 完全無料

• Function as a Service は自分でサーバーを構築・維持する必要がありません

• 保守と引き継ぎが簡単

• 携帯電話で操作可能

• AIがサポート！
  ChatGPTやその他のAIツールはGASに非常に詳しく、直接依頼すればパッケージフォームの作成やGitHub APIの連携を手伝ってくれます

• Jira、Asana、Slack 通知 API と連携可能です

第二のプロモーションでは、GAS Web Appを使ってメンバーに提供しました。同様に良い反響があり、Slackとの違いはブックマークにもう一つURLを登録するだけです。パッケージングが必要な時は、そのURLを開いてウェブフォームから操作します。

App CI/CD 完全なツールフロー

こちらに全体のワークフローを添付します。次回からは各ツールの使い方と連携方法を順に紹介していきます。

ツールの役割：

• GitHub Actions : CI/CDのロジックを記述するスクリプトコード

• GitHub Actions — Self-hosted Runner : CI/CDを実際に実行する環境で、自分で設置したRunnerを使って実行します。機器の購入費用のみ負担すれば、使用量制限なくタスクを実行可能です。

• Google Apps Script Web App : パッケージングは必ずしもエンジニアが担当するわけではないため、異なる職種のメンバーが使えるプラットフォームが必要です。GAS Web Appはウェブツールを素早く作成し、URLを共有して他の人が操作できるようにします。

• Asana/Jira : プロジェクト管理ツールで、GAS Web Appと連携しQAやPMが直接パッケージ化したいタスクを選択できます。

• Slack : 実行結果の通知を受け取る担当

シナリオ：

• End-User (QA/PM/PD/Developer): GAS Web App を使ってパッケージングフォームを送信（Jira または Asana のタスクに対応するブランチを取得）-> GAS が GitHub API を呼び出し -> CD パッケージングをトリガーする GitHub Actions <- GitHub self-hosted runner がタスクを受け取りマシンで実行 -> 実行完了後に Slack 通知、GAS Web App のパッケージング状態を更新。

• End-User (Developer): PRを作成し、新しいコミットをPRにプッシュ -> CIテストプロセスをトリガー <- GitHub self-hosted runnerがジョブを検知してマシンで実行 -> 実行完了後、テスト結果をコメントし、Checksを更新。

まとめ

本記事では、まずCI/CDとは何か、そのメリットについて初歩的に解説します。次回からは技術面に入り、GitHub ActionsによるCI/CDの理解と実装を手取り足取りご紹介し、前回の最終成果物の完成までを目指します。

シリーズ記事：

• CI/CD 実践ガイド（1）：CI/CDとは？CI/CDで安定かつ効率的な開発チームを作る方法は？ツールの選び方は？

• CI/CD 実践ガイド（二）：GitHub Actions と self-hosted Runner の使用と構築大全

• CI/CD 実践ガイド（三）：GitHub Actions を使ったアプリプロジェクトの CI と CD ワークフローの実装

• CI/CD 実践ガイド（4）：Google Apps Script Web App を使って GitHub Actions と連携し、無料で使いやすいパッケージングツールプラットフォームを構築する

🍺 Buy me a beer on PayPal

本シリーズの記事は多くの時間と労力をかけて執筆しました。内容があなたのお役に立ち、チームの作業効率や製品品質の向上に貢献できたなら、ぜひコーヒーをご馳走してください。ご支援ありがとうございます！

🍺 Buy me a beer on PayPal

🍺 Buy me a beer on PayPal

ご質問やご意見がありましたら、こちらからご連絡ください 。

Post Mediumから変換 by ZMediumToMarkdown.

---

🍺 Buy me a beer on PayPal

👉👉👉 Follow Me On Medium! (1,053+ Followers) 👈👈👈

本記事は Medium にて初公開されました（こちらからオリジナル版を確認）。ZMediumToMarkdown による自動変換・同期技術を使用しています。

Improve this page on Github.