ZhgChg.Li
ZRealm開発

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

iOSアプリ開発チームが抱える効率化課題を解決。CI/CD導入で開発速度と品質を向上させる方法と具体的ツール選びを詳解し、実務での効果を最大化します。

ZhgChgLi by ZhgChgLi 37 分 6,194+ 閲覧
CI/CD 実践ガイド｜iOS開発チーム向け安定・効率化の秘訣と最適ツール選定
本記事は AI による翻訳です。お気づきの点があればお知らせください。

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

App（iOS）チームを例に、CI/CDの基本から導入後にもたらす実質的な価値までご紹介します。

Photo by Leif Christoph Gottwald

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 円です。

*上記には電気代とネット費用は含まれていません。

はじめに

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

章節

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

最終成果

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

Demo PR

Demo PR

Demo Web App（初回利用は下記のチュートリアルを参照してください）

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 の審査完了後、ユーザーにリリースされます。

問題

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

Question 1: 現在の正しい機能変更に対して統一された検査機構が全くありません。

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

  • ビルドに失敗してもマージできる

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

  • 私の環境では機能は正しく動作していますが、他の人の環境では必ずしも正しく動作するとは限りません。

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

質問2: パッケージ作業に多くの人手と時間がかかっている。

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

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

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

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

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

  • QAはエンジニアにパッケージングを依頼するため、やり取りが発生します。

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

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

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

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

Question 2「継続的デプロイメント」は、CI段階でコードに異常がないことを確認した後、変更内容を自動でパッケージ化し、社内テスト（QA、デバッグ、ステージング、ベータなど）や外部リリース（プロダクション、リリースなど）へ展開する煩雑な作業を自動化することを目的としています。

  • Continuous Deployment: 完全に自動で直接 Production 環境へデプロイすること

  • Continuous Delivery: Staging/Debug 環境への自動デプロイのみ行い、問題がないことを手動で確認してから Production 環境にデプロイする方式

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の導入もまさにこの3つの方向に合致しており、同じ方法で効果を見積もることができます。

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

私たちが一定時間継続して作業を行うと、「フロー」状態に入ります。この時、思考や生産性はピークに達し、最も効果的なアウトプットが可能になります。しかし、一度中断されると、再びフローに戻るまでに時間がかかります。ここでは30分を例とします。

CI/CD がない場合のシナリオは次のようになります： 問題が改悪されたことに気づくまでに多くの時間がかかり、その後コミュニケーションして修正する（CI）、QAやPMがエンジニアにテスト版アプリのビルドを依頼する（CD）。

CI/CD 効果の見積もり

チーム人数 6人 / 1ヶ月の計算

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

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

ここで見落としていたのは、2026–03–01 以降 Self-hosted は1分あたり0.002 USD の維持費が必要 という点で、500分実行すると1 USDの費用がかかることです。

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台購入する場合の例：32GB 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 サービスを素早く構築できます。

以下はアプリの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よりやや優れていると感じます。

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

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 は後にクロスリポジトリアクション/ランナーもサポートしました。

サードパーティ製パッケージの豊富さ 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 や 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ドルの維持費用が必要になります。なお、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/ja-jp/blog/productivity/workflow-builder-tools-automation-examples>

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 App

以前に「 Google Apps Script Web App フォームを使って Github Action CI/CD ワークフローを連携する 」を共有しました：

Demo Web App フォーム URL

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 は、Web ツールを素早く作成し、URL を共有して他の人に操作してもらえます。

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

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

シナリオ：

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

  • エンドユーザー（開発者）：PRを作成し、新しいコミットをPRにプッシュ -> CIテストプロセスをトリガー <- GitHub self-hosted runnerがジョブを検知してマシンで実行 -> 実行完了後、テスト結果をコメントし、Checksを更新。

まとめ

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

シリーズ記事：

🍺 Buy me a beer on PayPal

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

Buy me a coffee

🍺 Buy me a beer on PayPal

Post Mediumから変換： ZMediumToMarkdown より。

分類
#iosアプリ開発 #ci-cd #github-actions #jenkins #アジャイル #japanese #ai-translation
GitHub で編集
この記事を改善
本記事は Medium で初公開
オリジナルを読む
この記事をシェア
リンクをコピー · SNS でシェア
ZhgChgLi
著者

ZhgChgLi

An iOS, web, and automation developer from Taiwan 🇹🇼 who also loves sharing, traveling, and writing.

コメント

こちらもおすすめ

ZRealm開発 · 2026-05-10
AI 協作で資料構造RFC作成｜多言語実装と技術設計の深掘り
ZRealm開発 · 2026-05-03
AI AgentでGoogle Apps Script開発を効率化｜ゼロから始めずに自動化を実現
ZRealm開発 · 2026-01-04
iOS Certificates, Identifiers & Profilesの関係｜Fastlane Matchで憑證管理とCI/CDを効率化