自己ホスト型Gitランナーが開発者の日常のワークフローに組み込まれると、何が変わるのか？

セルフホスト型Gitランナーが日常のワークフローに組み込まれると、それは本番環境の依存関係になります。開発者はそのキュー、ツールチェーン、ネットワークアクセス、シークレット、キャッシュ、復旧時間に依存するようになります。

したがって、トポロジーでは制御と実行を分離し、ジョブを使い捨て可能にし、意図的に共有する状態だけを保持する必要があります。高速な永続ランナーは便利ですが、見えない環境差異や広範な認証情報によって、その利便性が脆弱な信頼境界に変わる可能性があります。

ランナーをリモートコード実行として扱う

受け入れたすべてのジョブは、リポジトリで管理されるコードを、所有するインフラ上で実行します。デプロイ用またはパッケージ用の認証情報を接続する前に、どのリポジトリ、ブランチ、コントリビューター、プルリクエストイベントがランナーに到達できるかを定義してください。

MicroVMベースのランナー設計では、使い捨ての仮想マシンを使用し、セルフホストの性能を維持しながら、あるジョブから次のジョブへ持ち越される状態を減らします。

信頼できるリリースジョブと通常のテストには、別々のランナーグループを使用してください。公開ワークフローやフォークからトリガーされたワークフローは、本番デプロイ用シークレットと同じ実行環境を共有すべきではありません。

高速な1台のマシンからキューの契約へ移行する

日常的に使用すると、処理開始までの時間、同時実行数、キャンセル、優先度に対する期待が生まれます。テストの遅さをランナー容量の不足と混同しないよう、キュー待ち時間とジョブ実行時間を分けて計測してください。

同時ビルドによってメモリ、ストレージ、Dockerイメージのプルが飽和する前の水準に、同時実行数を設定します。長時間のテストマトリクスの後ろで待たせてはならない対話的なジョブやリリースジョブがある場合は、そのための容量を確保してください。

ランナーがオフラインのときに開発者が利用できる代替手段を文書化します。ホスト型実行、ローカルコマンド、または遅延させても問題のないジョブなどです。代替手段がなければ、メンテナンスが計画外の開発停止につながります。

再構築可能なキャッシュと永続状態を分離する

キャッシュは日々の開発サイクルを改善しますが、サイズ上限、所有者モデル、削除ルールが必要です。ビルド成果物とリリースの証跡は、上限のないワークスペースフォルダーではなく、保持期間を明示した外部の保存先に置きます。

イメージまたはプロビジョニングスクリプトからランナーを置き換えられるようにします。ホストを再構築すると唯一の署名キーやテスト結果が失われるなら、それらの資産は誤った役割に保存されています。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

パッチ適用、可観測性、障害対応の責任を追加する

ランナーのバージョン、オペレーティングシステムのパッチ、Dockerまたはツールチェーンのバージョン、ディスク使用量、ジョブ失敗率、キューのレイテンシ、キャッシュの増加を追跡します。ランナーが個人用サーバーであっても、メンテナンス時間枠と担当者をそれぞれ1つずつ決めてください。

実証的なワークフローのメンテナンスに関する研究では、自動化そのものが継続的なバグ修正とCI改善の作業を生み出すことが示されています。セルフホストでは、ホストのライフサイクルもそのメンテナンス負担に加わります。

オフライン状態、繰り返されるジョブ失敗、ディスク容量の枯渇、通常より長いキューに対してアラートを設定します。ログから、失敗がリポジトリのコード、ランナーイメージ、ネットワークアクセス、ホストのどこに起因するのかを特定できなければなりません。

日常のワークフロー対応準備テストを行う

ランナーを再構築し、デプロイ用認証情報をローテーションし、2つのビルドを同時実行し、キャッシュをいっぱいにしてから削除し、ジョブの実行中に意図的にホストをオフラインにします。開発者が障害を確認し、代替経路を利用できることを確認してください。

停止時間を許容でき、ジョブが信頼できる場合は、ランナーを1台のホストに置きます。異なる認証情報やメンテナンス時間枠が必要なリリース、信頼できない処理、ハードウェア固有のワークロードは分離してください。ホームサーバーOSガイドは、ランナーのホストを再現可能な更新と復旧に適合させるのに役立ちます。

ジョブの欠落がリリースや顧客対応を妨げるようになったら、ランナーを趣味のサービスとして扱うのをやめます。その時点で、他の開発依存関係と同様に、サービスの所有者、余剰容量、テスト済みの置き換え手順を定義してください。

最終セットアップルール

すべてのサービスに明確な役割、保護された状態、管理されたアクセス経路、テスト済みの復元手順、そしてトポロジーを分割または拡張するための測定可能なトリガーがある場合に、セットアップは合格です。