H2: はじめに
私は 2012 年から CI/CD パイプラインに取り組んでおり、低俗な新興企業から大規模なエンタープライズ プラットフォームに至るまで、あらゆるもの向けの自動配信ワークフローを構築および改良してきました。ソフトウェア配信のボトルネックとなる展開パイプラインの遅さ、エラーが発生しやすい、または一貫性のない問題に直面したことがあるのは、あなただけではありません。私は、非効率なパイプラインがどのように遅延、フラストレーション、完全な障害を引き起こし、時にはデバッグやロールバックでチームに何日も費やすことがあるのをこの目で見てきました。
私の経験では、CI/CD パイプラインのベスト プラクティスを適用すると、複数のプロジェクト全体で平均デプロイ時間が約 40% 短縮され、ロールバック インシデントが半分に削減されました。これらは単なる虚栄的な指標ではありません。これらは、機能の提供の高速化、安定性の向上、顧客の満足度の向上に直接つながります。
今日は、2026 年に信頼性の高い CI/CD パイプラインを構築、改善、維持するのに役立つ実践的なテクニックを共有したいと思います。主要なアーキテクチャに関する洞察、パイプライン スクリプトのコード例、セキュリティに関する考慮事項、避けるべき一般的な落とし穴について説明します。あなたが開発者、DevOps エンジニア、または IT 意思決定者のいずれであっても、このガイドは、曖昧な理論ではなく、実践的で導入テスト済みのアドバイスを基に基礎を築くことを目的としています。パイプラインをスムーズかつ安全に稼働させるための実行可能な次のステップに進みます。
H2: CI/CD とは何ですか?中心となる概念の説明
H3: CI/CD は何の略ですか?
継続的インテグレーション (CI) は、コードの変更を頻繁に (理想的には 1 日に複数回) 自動的にマージして検証する手法です。目標は、共有リポジトリ内のすべてのコミットを構築してテストすることで、統合の問題を早期に発見することです。これにより、「私のマシンでは動作する」という問題が最小限に抑えられ、フィードバック ループが加速されます。
継続的デリバリー (CD) は、コードの変更を自動的に準備することで CI に基づいて構築されており、いつでも安全に運用環境にデプロイできます。デプロイメント自体は手動またはスケジュールされたものである可能性がありますが、パイプラインにより、コードが常にリリース可能な状態にあり、すべてのテストと検証に合格することが保証されます。
継続的デプロイメントではさらに一歩進んで、テストに合格したすべての変更が手動介入なしで自動的に実稼働環境にデプロイされます。このアプローチは、迅速な反復リリースを目的とした SaaS 環境で一般的です。
H3: CI/CD パイプラインの主要コンポーネント
一般的なパイプラインは、次のコア部分で構成されます。
- バージョン管理システム (VCS): コードが存在する Git リポジトリ。分岐戦略はパイプラインのトリガーに影響します。
- ビルド自動化: ソース コードのコンパイルまたはアーティファクトのパッケージ化。
- 自動テスト: コードの変更を検証するための単体テスト、統合テスト、および場合によっては受け入れテスト。
- デプロイの自動化: コードまたはコンテナをターゲット環境にプッシュするスクリプトまたはツール。
- モニタリングとフィードバック: パイプラインの健全性と生産ステータスを追跡するアラートまたはダッシュボード。
H3: CI と CD の違い
CI はコードの統合と検証に重点を置き、コード変更ごとにビルドとテストを実行します。 CD は、検証された変更が実稼働環境に準備完了 (および必要に応じてデプロイ) されていることを確認します。たとえば、典型的な GitHub Actions ワークフローでは、コミットごとに CI を実行しますが、リリース前に手動による承認が必要になります。これは、継続的デリバリーと継続的デプロイメントを示しています。
以下は、プッシュごとにトリガーされる CI ステップを示す最小限の GitHub Actions YAML スニペットです。
[コード: GitHub Actions を使用したビルドとテストのための最小限の CI パイプライン YAML スニペット]
名前：CI
に:
プッシュ：
支店:
- メイン
プルリクエスト:
支店:
- メイン
仕事:
ビルドとテスト:
実行: ubuntu-最新
手順:
- 名前: チェックアウト ソース コード
使用: アクション/checkout@v3
- 名前: Node.js 18.x のセットアップ
使用:actions/setup-node@v3
と:
ノードバージョン: 18
- 名前: 依存関係をインストールします。
実行: npm ci
- 名前: テストの実行
実行：npmテスト
このパイプラインはビルドとテストのみに焦点を当てており、コード変更の迅速な検証を提供します。
H2: 2026 年に CI/CD が重要となる理由: ビジネス価値とユースケース
H3: 市場投入までの時間を短縮する
CI/CD の中心的な価値の 1 つは、フィードバック ループを劇的に短縮することです。コードが変更されるたびに機能を迅速に検証するパイプラインがトリガーされると、開発者は何時間も何日も待つことなく、すぐにフィードバックを得ることができます。この高速化は、企業が機能、バグ修正、セキュリティ パッチをより迅速に出荷できることを意味します。これは、遅さが顧客の喪失につながる競争市場において極めて重要です。
H3: ソフトウェアの品質の向上
CI パイプラインに組み込まれた自動テストは、展開前の早い段階で回帰を検出します。これにより、本番環境にバグが紛れ込む可能性が減ります。 2026 年のスタック オーバーフロー DevOps レポートによると、成熟した CI/CD パイプラインを備えた組織は、運用インシデントが 25% ～ 40% 少ないと報告しています。防御の第一線として自動検証に勝るものはありません。
H3: DevOps とアジャイル実践の実現
CI/CD ワークフローは、最新の DevOps およびアジャイル手法のバックボーンを形成します。これらにより、大がかりな手動作業を行わずに、頻繁な統合と展開が可能になります。 CI/CD の実装に成功したチームは、多くの場合、より高度なコラボレーション、より迅速なイテレーション、および開発と運用の間のより良い連携を報告しています。
H3: ユースケース: SaaS スタートアップのスケーリング、ラピッド リリース
私が協力した SaaS スタートアップ企業は、手動リリースに苦労していました。デプロイメントには数時間かかり、2 週間に 1 回のペースで行われ、構成の問題により頻繁にダウンタイムが発生していました。自動テストと Blue-Green デプロイメントを備えた CI/CD を実装した後、ほぼゼロのダウンタイムで毎日デプロイしました。導入頻度は隔週から毎日に増加し、変更の失敗率は 3 か月で 50% 減少しました。
ここで重要となる一般的な主要な指標には、展開の頻度、変更のリードタイム、変更の失敗率 (ロールバックまたはホットフィックスの数で測定) などがあります。
H2: CI/CD パイプラインの技術アーキテクチャ: 詳細
H3: ソース管理リポジトリと分岐戦略
ソース管理はパイプラインの基礎です。ブランチを整理する方法は、パイプラインのトリガーと複雑さに大きく影響します。一般的な戦略には次のようなものがあります。
- 機能ブランチ: 開発者は、レビュー後にマージされた機能ブランチに取り組みます。分離は簡単ですが、統合が遅れる可能性があります。
- トランクベースの開発: 開発者は、メイン ブランチまたは短期間にマージされた機能ブランチに直接コミットします。迅速な統合が可能ですが、規律が必要です。
- Gitflow: 複数のブランチ (機能、開発、リリース、マスター) を含むワークフローは人気がありますが、複雑さが増し、マージが遅くなる可能性があります。
分岐戦略の選択は、チームの規模、リリース頻度、リスク許容度によって異なります。
H3: サーバーと自動化ツールを構築する
パイプラインの中心となるのは、Jenkins、GitLab CI/CD、GitHub Actions、CircleCI などのビルド サーバーまたは自動化プラットフォームです。それぞれに異なるアーキテクチャがあります。
- Jenkins にはマスター エージェント モデルがあります。拡張性は高いですが、大規模に維持するのは複雑です。
- GitLab CI は GitLab リポジトリに統合されています。明確に定義されたパイプラインによる優れたオールインワン エクスペリエンス。
- GitHub Actions は、GitHub でホストされるワークフローに優れています。緊密に統合されていますが、同時実行クォータによって制限される場合があります。
- CircleCI は、高速並列処理を備えたコンテナベースのビルドに重点を置いています。
現実のトレードオフ: Jenkins は企業のニーズに最大限の柔軟性を提供しますが、継続的なメンテナンスが必要です。 GitLab や GitHub Actions などのマネージド プラットフォームはオーバーヘッドを削減しますが、カスタム ワークフローを制限したり、大規模にコストが増加したりする可能性があります。
H3: テスト自動化の統合
テストは、ビルドが成功した後の次の門番です。パイプラインでは、最初に単体テストを調整し、次に統合テスト、その後にオプションのエンドツーエンド (E2E) テストとパフォーマンス テストを行う必要があります。これらをパイプライン ステージに分割すると、障害を迅速に診断するのに役立ちます。
例: 高速単体テストを並行して実行し、その後 E2E を順次実行して速度と信頼性のバランスをとります。テストの不安定性検出ツールを組み込むことで、誤った障害による遅延の発生を防ぐことができます。
H3: 導入戦略
デプロイメントは、リスクを最小限に抑えながら、変更が本番環境にどのように到達するかを定義します。
- ブルーグリーン展開: 2 つの同一の環境 (ブルー/グリーン)。新しいバージョンはアイドル環境に展開され、その後トラフィックがカットオーバーされます。ダウンタイムを削減します。
- Canary リリース: 問題を早期に発見するために、トラフィックのごく一部を新しいバージョンに徐々にルーティングします。
- ローリング更新: インスタンスのサブセットを順次更新して、展開中の可用性を維持します。
導入スタイルの選択は、インフラストラクチャ、リスク選好度、およびユーザーの負荷パターンに関係します。
H2: はじめに: 最初の CI/CD パイプラインのステップバイステップ実装ガイド
H3: 技術スタックに適したツールを選択する
CI/CD ツールの選択は、スタックと組織のニーズに大きく依存します。たとえば:
- GitHub を使用するクラウドネイティブ チームは、緊密な統合とパブリック リポジトリの無料分により、GitHub Actions の恩恵を受けます。
- オンプレミスに懸念を持つ企業は、多くの場合、Jenkins または自己ホスト型 GitLab に傾きます。
- 軽量プロジェクトでは、迅速なセットアップのために CircleCI または Travis CI を使用する場合があります。
同時実行の制限、コンテナー レジストリまたはクラウド プロバイダーとの統合、およびスケーラビリティを考慮してください。
H3: インストールとセットアップのベスト プラクティス
自己ホスト型のランナーまたはエージェントの場合、認証情報の保護は重要です。ボールトベースのシークレット マネージャーまたはエージェントごとにスコープ指定された環境変数を使用します。最小特権の原則に従います。
- パイプラインアクションの API トークンを必要なものだけに制限する
- パスワードなしの SSH キーは慎重に使用してください。可能な限り一時的な認証情報を好む
- 定期的にアクセス ログを監査し、半年ごとまたは侵害に応じてシークレットをローテーションします。
通常は Webhook またはネイティブ プラットフォーム サポートを介して、パイプラインをリポジトリ トリガーと統合します。
H3: 最初のパイプライン スクリプトを作成する
以下は、Node.js アプリのビルド、テスト、および単純なデプロイ段階を示す最小限の GitLab CI YAML です。
[コード: GitLab CI でのビルド、テスト、デプロイの各ステージを含むパイプラインの例]
段階:
- 構築する
- テスト
- デプロイ
ビルドジョブ:
ステージ: ビルド
画像: ノード:18
スクリプト:
- npm ci
- npm ビルドを実行する
アーティファクト:
パス:
- 距離/
テストジョブ:
ステージ: テスト
画像: ノード:18
スクリプト:
- npmテスト
デプロイジョブ:
ステージ: デプロイ
画像: アルパイン
スクリプト:
- echo "運用サーバーにデプロイ中..."
- ./deploy.sh
いつ: 手動
のみ:
- メイン
デプロイ段階は手動であり、デプロイメントではなく継続的デリバリーを示していることに注意してください。
H3: 最初にローカルでテストする
パイプラインの変更をプッシュする前に、ローカルでテストすると時間を節約できます。 GitLab のローカル ランナーや GitHub Actions Runner などのツールを使用すると、マシン上でパイプラインの実行をシミュレートできます。パイプライン環境を模倣する Docker コンテナーを使用すると、依存関係や権限の問題を早期に発見するのに役立ちます。
H3: 実践的なヒント
基本的なパイプラインから始めます。プッシュごとに構築してテストします。安定したら、展開ゲートと品質ゲートを段階的に追加します。これにより、複雑さが軽減され、デバッグが管理しやすくなります。
H2: CI/CD パイプラインのベスト プラクティスと制作のヒント
H3: パイプラインを高速かつ効率的に維持する
長時間実行されるパイプラインは生産性を低下させます。独立したジョブ (パッケージごとに分割された単体テストなど) を並列化し、依存関係 (npm/yarn キャッシュ、Docker レイヤー) をキャッシュし、冗長なタスクを回避します。
あるプロジェクトでは、node_modules キャッシュと並列テスト シャードを実装することで、ビルド時間を 15 分から 10 分に短縮しました。パイプライン時間が短縮されると、フィードバックが高速化されます。
H3: 不変のアーティファクトとバージョン管理を使用する
Nexus、Artifactory、S3 などのアーティファクト リポジトリに保存されるバージョン管理されたアーティファクトを常に生成します。 「最新」ではなくタグ付けされたバージョンをデプロイして、ドリフトを防止し、ロールバックを有効にします。
たとえば、Docker イメージにセマンティック バージョンと Git コミット SHA をタグ付けしてから、正確なタグをデプロイします。
H3: パイプラインを保護する
HashiCorp Vault やクラウド プロバイダーのシークレット マネージャーなどのツールを使用してシークレット管理を実装します。スクリプトや構成ファイルにパスワードやキーをハードコーディングしないでください。
パイプライン ツールでロールベースのアクセス制御 (RBAC) を使用して、パイプラインのデプロイまたは変更をトリガーできるユーザーを制限します。監査ログを有効にして、変更を追跡し、イベントをトリガーします。
H3: パイプラインの健全性の監視とアラート
CI ダッシュボードや Datadog や Prometheus などの外部ツールを介して、パイプラインの成功/失敗率、平均実行時間、不安定性メトリクスを追跡します。
パイプラインの劣化を早期に検出するために、繰り返される障害や長時間の実行に関するアラートを設定します。早期発見は、下流でのより大きな問題を回避するのに役立ちます。
H3: 制限とトレードオフ
パイプラインが複雑になると制御不能になり、メンテナンスコストが増加する可能性があります。ツールのロックインにより、移行が困難になる可能性があります。さらに、CI/CD リソースの消費は大量になる可能性があるため、ランナーの弾力性と予算の制約を考慮してください。
H2: よくある落とし穴とその回避方法
H3: 多すぎる責任によるパイプラインの過負荷
パイプラインが構築、テスト、デプロイ、コード スキャン、パフォーマンス ベンチマークなど、すべてを一度に実行しようとしすぎているのを見てきました。これにより、長くて脆弱なパイプラインが予期せずに失敗することになります。 「ビルドとテスト」と「デプロイと監視」を別々のパイプラインまたはワークフロー ステージに分割し、懸念事項を分離することをお勧めします。
H3: テストの無視または不安定なテストの実行
不安定なテストはパイプラインの信頼を損ないます。あるプロジェクトでは、不安定な統合テストにより偽陰性が発生し、手動によるオーバーライドとリリースの遅延につながりました。解決策: 不安定なテストを隔離し、修正または書き直し、テストの安定性を継続的に監視します。
H3: パイプラインのセキュリティを無視する
秘密の漏洩や古い認証情報は、高額な損害をもたらす侵害を引き起こしています。 CI/CD パイプラインを第一級のセキュリティ資産として扱います。トークンをローテーションし、環境変数を暗号化し、ユーザーの権限を制限します。
H3: パイプライン メトリクスを監視しない
メトリクスがなければ、パイプラインの劣化は配信に影響を与えるまで気づかれません。クライアント プロジェクトでは、チームが監視を設定してランナーを拡張するまで、気付かないうちにパイプライン キューのバックログが発生し、待ち時間が 2 倍になっていました。
H3: 実践的なアドバイス
定期的なパイプライン監査を四半期または半年ごとにスケジュールします。未使用のジョブをクリーンアップし、依存関係を定期的に更新し、非推奨のスクリプトを削除します。
H2: 実際の例とケーススタディ
H3: ケーススタディ: 電子商取引プラットフォームの CI/CD 変革
私が担当した電子商取引クライアントは、ほとんどが手動で行われるエラーが発生しやすいリリースに苦労していました。私たちは、ビルド/テストを自動化するために GitLab CI パイプラインを導入し、Kubernetes クラスターに Blue-Green デプロイメントを採用しました。
6 か月以内の結果:
- 導入頻度が 2 週間に 1 回から 1 日 2 回に増加しました
- ロールバックが 70% 以上減少しました
- 平均導入時間は 20 分から 5 分未満に短縮されました
H3: オープンソース プロジェクトのパイプラインからの教訓
Kubernetes や React などのプロジェクトを見てください。 Kubernetes は、並列 E2E テストに重点を置き、Prow で調整された数百のジョブを含む複雑なパイプラインを使用します。 React の CI は増分ビルドを重視し、キャッシュを積極的に使用します。
これらの成熟したプロジェクトは、モジュール性、可観測性、拡張性を念頭に置いてパイプラインを設計していることがわかります。
H3: マイクロサービスがパイプライン設計に与える影響
マイクロサービス アーキテクチャでは、各サービスが独立したビルド、テスト、デプロイのプロセスを必要とするため、パイプラインが複雑になります。依存関係とバージョンの互換性を調整するには、慎重なバージョン管理が必要であり、場合によっては GitOps ワークフロー用の ArgoCD や Flux などの複雑なオーケストレーション ツールが必要です。
H2: ツール、ライブラリ、リソースのエコシステムの概要
H3: 主流の CI/CD ツール
- Jenkins: 高度にカスタマイズ可能な巨大なプラグイン エコシステム。メンテナンスが必要です。
- GitLab CI/CD: GitLab と統合され、多言語パイプラインと Kubernetes をサポートします。
- CircleCI: コンテナネイティブ、並列処理、優れたクラウドおよびオンプレミスのオプションをサポートします。
- Travis CI: スタートアップは簡単ですが、エンタープライズ規模では柔軟性が低くなります。
- GitHub Actions: GitHub との緊密な統合により、コミュニティ マーケットプレイスのアクションが増加します。
H3: シームレスに統合されるテスト フレームワーク
パイプラインに適合するテストを選択することが重要です。
- JUnit/TestNG (Java)
- pytest (Python)
- ジェスト/モカ (JavaScript)
- E2E ブラウザ自動化のための Selenium と Cypress
H3: コードとしてのインフラストラクチャ ツール
ビルド/デプロイを超えて自動化を拡張するには、Terraform、Ansible、または Helm チャートを使用したインフラストラクチャのプロビジョニングが一般的です。これらのツールはパイプラインに接続して、再現可能な環境を強制します。
H3: シークレット管理ツール
- HashiCorp Vault: 動的なシークレット、堅牢な API。
- AWS Secrets Manager: フルマネージド型の AWS 統合。
- Azure Key Vault、Google Secret Manager も同様にクラウドにサービスを提供します。
H3: リソース
公式ドキュメントについては、GitLab CI ドキュメントがよく書かれており、最新です。 GitHub Actions ドキュメントでは、ワークフロー構文とベスト プラクティスについて詳しく説明しています。 DevOps Stack Exchange と Reddit の r/devops のコミュニティ フォーラムは、現実世界のエクスペリエンスを提供します。
H2: 比較: CI/CD パイプラインと従来のデプロイメント方法
H3: 手動導入のリスクと制限
手動デプロイメントでは、手順の欠落や間違った構成パスなどの人的エラーが発生し、ダウンタイムや不整合が発生することがよくあります。フィードバック ループが遅くなり、数分で済む作業が 1 日かかることもあります。
H3: スクリプト化されたパイプラインと完全に自動化されたパイプライン
一部のチームはスクリプト化された展開ツールを使用していますが、それでも手動による承認や介入が必要です。このハイブリッド アプローチではエラーは軽減されますが、継続的な展開などの完全自動化の利点の一部が失われます。トレードオフ: コントロールとスピード。
H3: クラウドネイティブ CI/CD とオンプレミス ソリューションの比較
クラウドネイティブ プラットフォームは、迅速なセットアップ、スケーラビリティ、マネージド ランナーを提供しますが、場合によっては深い統合やコスト管理が欠けています。オンプレミス ソリューションは、より高度な制御とセキュリティを提供しますが、メンテナンスが必要であり、簡単に拡張できない場合があります。
選択は、組織のコンプライアンス要件、予算、社内の専門知識によって異なります。
H2: FAQ: よくある技術的な質問への対処
H3: CI/CD パイプラインのシークレットを安全に処理するにはどうすればよいですか?
CI/CD プラットフォームに統合されたシークレット管理ツールを使用するか、実行時にシークレットを環境変数として挿入します。プレーンテキストのシークレットをリポジトリやパイプライン スクリプトに保存しないでください。定期的にローテーションしてアクセスを監査します。
H3: デプロイメントのバージョンを管理する最良の方法は何ですか?
トレーサビリティのためにコミット SHA と組み合わせたセマンティック バージョニングを使用して、ビルドとアーティファクトにタグを付けます。バージョン管理されたコンテナー イメージを使用し、アーティファクトをレジストリまたはアーティファクト リポジトリに保存して、正確なロールバックを可能にします。
H3: パイプラインの実行時間を改善するにはどうすればよいですか?
独立したジョブを並列化し、依存関係をキャッシュし、パイプラインをより小さな増分ステージに分割します。遅いステップを監視し、ログを分析してボトルネックを特定します。
H3: 継続的デリバリーと継続的デプロイメントのどちらを選択すべきですか?
継続的デリバリーは、自動化されたビルド/テスト パイプラインの恩恵を受けながら、リリースを手動で制御したいチームにとってより安全です。継続的デプロイメントは、検証後すぐにデプロイメントを行いたい、包括的なテストを行う成熟したチームに適しています。
H3: 失敗した展開から回復するにはどうすればよいですか?
不変のアーティファクトを使用して自動ロールバックを実装します。ブルーグリーンまたはカナリア展開を使用して、爆発範囲を最小限に抑えます。予期せぬ事態を避けるために、ロールバック手順を定期的にテストしてください。
H3: 自動パイプラインに手動承認を統合できますか?
はい、最新の CI/CD ツールは手動ゲートまたは承認ステップをサポートしており、自動化と人間によるチェックのバランスをとったハイブリッド ワークフローを実現します。
H3: パイプラインのパフォーマンスを監視するにはどうすればよいですか?
GitLab や Jenkins などのツールのネイティブ ダッシュボードを活用します。エクスポーターを使用して Prometheus/Grafana などの監視システムにメトリクスをプッシュするか、サードパーティの SaaS 監視を使用します。成功率、期間、失敗の原因、不安定さを追跡します。
H2: 結論と次のステップ
要約すると、2026 年の CI/CD パイプラインのベスト プラクティスは、自動化されたビルドとテストによる高速で信頼性の高い統合という強固な基本原則を中心に展開します。自動化されているが制御された展開。厳格なセキュリティと秘密管理。そして継続的な監視と改善。
段階的かつ思慮深く構築すると、パイプラインがボトルネックからイネーブラーに変わるのを見てきました。 CI/CD は 1 回限りのセットアップではなく、継続的な改良と適応が必要な進化するシステムであることに注意してください。
始めたばかりの場合は、まずビルドとテストの自動化に重点を置き、次に慎重なロールアウト戦略を使用してデプロイメント段階を追加します。自信が高まってきたら、慎重にパイプラインの複雑さを拡張してください。
自分で試してみてください。上記のサンプル スクリプトと技術スタックを使用して、最小限のパイプラインを草案してください。次に、実際の結果に基づいて反復、測定、改良を行います。
CI/CD パイプラインは、チームの規模、リスク許容度、テクノロジー スタックに合わせて調整すると、最も効果的に機能します。うまく適用すると、配信が加速され、ソフトウェアの品質が向上し、チームのコラボレーションが向上します。
役立つと思われた場合は、このようなより実践的なガイドを購読してください。パイプラインは練習すれば完璧になるということを覚えておいてください。安全に実験することを恐れないでください。
[コマンド: Ubuntu 22.04 への GitLab Runner のインストール]
sudocurl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner 開始
[コマンド: GitHub Actions Runner を使用してローカルでテストを実行する]
CD マイレポ
git clone https://github.com/actions/runner.git
CDランナー
./config.sh --url https://github.com/myorg/myrepo --token
このトピックに興味がある場合は、こちらも役立つかもしれません: http://127.0.0.1:8000/blog/unlocking-the-secrets-of-performance-tuning-a-complete-guide