GitHubは、開発者がプラットフォーム上で頻繁に行うアクションの一つであるコードプッシュの信頼性と効率性を高めるために、いくつかの技術的なアップグレードを実施した。これは、潜在的な問題に対処し、GitHubに定期的にコードをプッシュするユーザーによりスムーズな体験の提供を目的としている。
GitHubのソフトウェア・エンジニアであるWilliam Haltom氏は、この技術的なアップグレードの背景について詳しく説明した。GitHubにコードをプッシュすると、プルリクエストの同期、Webhookのディスパッチ、ワークフローのトリガー、アプリのインストール、GitHub Pagesの公開、Codespacesの設定更新といった一連のアクションが発生する。さらに、GitHub内にはプッシュごとに起動される60以上の内部プロセスがアクティブ化され、開発者向けのさまざまな機能や自動化ツールが有効になる。
以前は、コードプッシュによって引き起こされるすべてのアクションの処理は、RepositoryPushJobとして知られるモノリシックなバックグラウンドジョブを通して行われていた。このジョブはGitHubのRuby on Railsモノリス内で、すべてのプッシュ処理ロジックを順次実行していた。しかし、そのサイズと複雑さのために問題があった。ジョブ内の個々のタスクの再試行は難しく、ほとんどのステップは全く再試行されなかった。
この信頼できるリトライメカニズムの欠如は、ジョブの初期段階でのエラーが連鎖して後続のステップに影響を及ぼし、潜在的な問題を幅広く引き起こす可能性があることを意味した。
GitHubは、長く連続的なジョブを複数の独立した並列プロセスに分割することで、コードのプッシュ処理を刷新した。これを実現するために、プッシュイベントをブロードキャストする新しいKafkaトピックを実装した。そして、所有するサービスや、依存関係や再試行要件などの論理的関係に基づいて、多数のプッシュ処理タスクを分析・分類した。
タスクの各グループは、指定された所有者と適切なリトライ設定を持つ新しいバックグラウンドジョブに割り当てられた。これらのジョブは、新しいKafkaイベントによってトリガーされる設定をされた。
このアーキテクチャでは、GitHubはKafkaイベントに応じてバックグラウンドジョブを列に入れる内部システムを利用していた。Kafkaイベント用の信頼できるパブリッシャーの開発、増加したジョブを管理するための専用ワーカープールの設定、プッシュイベントフローを監視するための可観測性の強化、新システムの安全かつ制御されたロールアウトを保証するための一貫した機能フラグ付けシステムの確立など、いくつかの改善がされた。
GitHubは最近、GitHub ActionsでArm64サポートを導入し、開発者にArmアーキテクチャ上でソフトウェアをリリースするためのArmビルドイメージを提供した。この発表は、Hacker News上の技術コミュニティで話題を呼んだ。GitHubとHNのユーザーであるObviyusは、Arm64サポートの導入に刺激を得ていて、自分たちのプロジェクトではセルフホストされたArmランナーに頼っていたと述べた。彼らは、小さなArm VPS上でコードをコンパイルすることが、他の作業を著しく遅らせる可能性があることを指摘し、Arm64の公式サポートが追加されたことは、待望の改善であると歓迎した。
今年初めにHacker Newsに投稿された記事の1つでは、開発者が自然言語を使用してブレーンストーミング、計画、コーディング、テスト、プロジェクトの実行をすることで、開発プロセスを合理化する設計をされたツールであるCopilot Workspaceについても取り上げられている。
Haltom氏はさらに、アーキテクチャーを刷新した結果について説明し、プロセスをより小さく切り離したことで、問題の爆発半径が小さくなったと述べた。プッシュ処理ロジックの一部分の問題が連鎖して他の部分に影響を及ぼすことがなくなり、安定性と信頼性が向上した。この分離により、依存関係も減少した。
さらに、新しいアーキテクチャは所有権を明確にし、プッシュ処理コードの責任を15以上のサービス所有者に分散させた。これにより、各チームは他のチームに意図しない影響を与えることなく、プッシュ機能を追加し、反復できる。最後に、ジョブが小さく、複雑でなくなったため、より信頼性の高いプッシュ処理が可能になる。