翻訳者 |劉王洋

校正者 | Chonglou

リリースパイプラインの構築を開始する

グレプタイムDB  オープンソース実装の当初から、GitHub Actions を使用してソフトウェア ビルド プロセスを自動化し、最初のリリース パイプラインを作成しました。

オープンソース プロジェクトの場合、安定した一貫性のあるリリース パイプラインを構築すると、次のような主な利点があります。

1. すぐに利用できるソフトウェア コンポーネントの提供: ソフトウェア サプライ チェーンの上流プロデューサーとして、バイナリ ファイルやイメージなどの安全で信頼性が高く、すぐに利用できるソフトウェア コンポーネントをさまざまな下流ユーザーに提供する必要があります。
2. 開発者エクスペリエンスを最適化: ユーザーは、面倒な構成や最初からセットアップしてコンパイルすることなく、それぞれのプラットフォームに適した、すぐに使用できる実行可能ソフトウェア コンポーネントを入手できます。
3. リリース ワークフローの自動テスト: さまざまな種類の回帰テスト (パフォーマンス、安定性、統合テストなど) を自動リリース プロセスと組み合わせて、ソフトウェアの全体的な品質を向上させます。

他にも選択肢はありますが、   Circle CI、Travis CI、GitLab CI、または次のようなセルフホスト型オープンソースプロジェクト テクトン そして  Argo Workflow が選択されましたが、GitHub Actions を選択した理由は明白です。GitHub エコシステムと統合され、ユーザーにユーザーフレンドリーなインターフェースと広範なソフトウェア マーケットプレイスへのアクセスを提供するためです。

しかし、ユーザーフレンドリーだからといって、メンテナンスが容易というわけではありません。むしろ、GitHub Actions のメンテナンスは複雑になることがあります。GreptimeDB の最初のオープンソース版は…   release.yml ファイルは当初、わずか183行の簡潔なコードで構成されていました。しかし、多くの貢献者による修正により、このファイルは徐々に進化し、より包括的なものになりました。

• 多様なプラットフォーム上でコンポーネントを構築します。
• ソフトウェア コンポーネントをアクティブ化するためのさまざまな機能スイッチを構築します。
• 実際のビルドの前に統合テストを実行します。
• ソフトウェア コンポーネントをさまざまなリポジトリ (DockerHub、ACR、S3 など) にプッシュします。
• さまざまなリリース条件（手動トリガー、エラー許容度など）を制御します。
• 等

さらに、特定のニーズ (リリースのデバッグ、毎日のビルドなど) により、わずかな違いしかない類似のパイプライン ブランチがさまざまな内部リポジトリに多数生成され、メンテナンスの負担が増加しています。

ビルド要件が複雑化するにつれて、release.ymlファイルは急速に大きくなり、冗長な設定で埋め尽くされ、メンテナンスが困難になります。適切なタイミングでリファクタリングを行わないと、リリースパイプラインは急速な、あるいは完全な失敗に陥るリスクにさらされます。

生産ラインの劣化問題の分析

ビルド要件が複雑化するにつれて、release.ymlファイルは急速に大きくなり、冗長な設定で埋め尽くされ、メンテナンスが困難になります。適切なタイミングでリファクタリングを行わないと、リリースパイプラインは急速な、あるいは完全な失敗に陥るリスクにさらされます。

生産ラインの劣化問題の分析

release.yml ファイルをレビューした後、急速なパフォーマンス低下を引き起こした要因を特定する必要があります。問題の根本原因を理解することでのみ、適切なリファクタリング計画を策定できます。

1. 言語の制限：GitHub Actions の YAML ベースのドメイン固有言語 (DSL) は、汎用プログラミング言語よりも表現力が低いため、冗長で保守が難しいコードになる可能性があります。
2. デバッグの難しさ：GitHub Actionsはデバッグが難しいことで知られています。特にRust言語を使用するプロジェクトはコンパイルコストが高く、デバッグサイクルがさらに長くなります。しかし…  活動 このようなツールは GitHub Actions をローカルで実行できますが、実際の実行はまだ実行する必要があるため、書き込み、実行、デバッグのサイクルを効果的に短縮することはできません。
3. アクションの分離が不十分: GitHub Actions はこの問題に対処します。  複合 異なるアクションを組み合わせる。経験不足のため、ロジックを独立したアクションに分割せず、すべてのコンテンツを単一のYAMLファイルに集約したため、メンテナンスが困難になりました。
4. ビルドが重複する問題：GitHubにはARM64対応の仮想マシンインスタンスが不足しているため、コンパイルパフォーマンスを最適化するため、GitHubのx86_64仮想マシンインスタンス上でAMD64およびARM64ソフトウェアコンポーネントのクロスプラットフォームコンパイルを実行することにしました。Dockerは使用できますが…  ビルドx   ARM64プラットフォームのエミュレーションビルドでQEMUを有効にすると、パフォーマンスが低下しました。DockerfileではなくGitHub Runnerホスト環境に依存していたため、一貫性があり繰り返し可能なビルドを実現するのは困難でした。

初めての試みで GitHub Actions を正常に実行できる人は非常に稀です。

リファクタリングプロセスの初期段階では、パフォーマンス（ビルド速度）よりも保守性を優先する必要があります。リリースパイプラインはプロジェクトの拡大に​​伴って進化するため、保守性は極めて重要になります。保守性を軽視すると、問題が起こりやすく、最終的には開発効率が低下する可能性があります。保守性を確保した上で初めて、パフォーマンスの向上に着手できます。コンパイル／ビルドのシナリオでは、様々なキャッシュメカニズムと高品質なビルドマシンを効果的に活用することで、一般的にパフォーマンスを向上させることができます。

再編計画

YAMLファイルのリファクタリングは、通常のプログラミングプロジェクトとは異なり、設定プロセスの包括的な見直しと言えます。一見論理的ではないように思えるかもしれませんが、予測不可能なほど複雑な要素を伴います。このプロセスでは、些細な問題に遭遇しやすく、解決が困難になる可能性があります。以下では、このようなリファクタリングを行う方のために、実践的なアドバイスをまとめました。

1. Dockerfile を使用してビルド プロセスを標準化します。Dockerfile ベースのビルドはパフォーマンスに影響を与える可能性がありますが、このアプローチにより保守性が向上し、クロスプラットフォームのビルド プロセスが統合され、ビルドの再現性が確保されます。
2. 統合ビルドコマンドインターフェース：上記の考慮事項に基づき、様々なビルドコマンドを単一の「make」コマンドに統合する必要があります。コンパイルの複雑さはYAMLファイルの外部に限定され、リリースフェーズで詳細が過度に隠されることを避け、開発フェーズではMakefileまたはスクリプトで詳細を公開します。Makefileを通じて、ユーザーはリリースフェーズと一貫性のあるビルドプロセスを体験でき、開発効率が向上します。
3. AWS EC2 の使用：GitHub Actions には現在 ARM64 VM インスタンスが不足しているため、クロスコンパイルが必要です。AWS EC2 ARM64 インスタンスを使用して ARM64 プラットフォーム向けのソフトウェアをビルドすることで、すべてのプラットフォームでビルドプロセスを標準化できます。
4. モジュラーデカップリング：   `release.yml` ファイルを明確なタスクセットに分割します。`actions` ディレクトリ内の各 `action.yml` ファイルは簡潔かつ明確に記述する必要があります。これにより、同じ操作に基づいて様々なプロセスをカスタマイズでき、プロセス全体の柔軟性と効率性が向上します。GitHub Actions にはタスクをグループ化するメカニズムがないため、これが最適なアプローチです。
5. タスク実行の簡素化：各タスクは単一の特定の目的に集中することで、冪等性を高める必要があります。これにより、エラー発生時の再試行が容易になります。さらに、トップレベルの制御変数の抽出が効率化され、より正確な手動制御のトリガーが可能になります。
6. Actions でのシェルコマンドのオーバーロードを避ける：メンテナンスを容易にするため、単一の GitHub Actions ステップに過剰なシェルコマンドをパッケージ化しないでください。コマンドの数が多い場合は、それらを外部スクリプトに変換し、入力パラメータを簡素化して、スクリプトが独立して実行および検証されるようにすることを検討してください。
7. ジョブ実行前のランナー割り当て機能の導入：Allocate Runnersは、後続のジョブのランナーを割り当て、グローバルバージョンタグを作成するための主要なタスクです。例えばEC2を使用する場合、Allocate RunnersはEC2 API（ec2-github-runnerアクションによって実装）を介して適切なプラットフォームにEC2インスタンスを割り当てます。将来的には、ランナー割り当てコストを最適化するための、より正確な選択アルゴリズムを導入する予定です。
8. グローバルに一貫性のあるプロセスを実現するために、機能的に類似したGitHub Actionsブランチの作成を避け、メンテナンスの負担を軽減します。透明性のあるオープンソース開発を促進するため、社内で使用されているすべてのビルドプロセスは、メインのGreptimeDBリポジトリに統合されています。コードがオープンソースである場合は、ソフトウェア製品とビルドプロセスもオープンである必要があります。
9. GitHubリポジトリでは、変数とシークレットを慎重に使用してください。ほとんどの外部パラメータを機密情報として扱わないでください。機密情報ではない外部パラメータは、将来簡単に変更できるようにGitHub変数として設定する必要があります。頻繁に変更が必要となる変数をYAMLでハードコーディングすることは避けてください。

見通し

GreptimeDBのリリースパイプラインのリファクタリングは、成熟への道のりのほんの一歩に過ぎません。私たちは、より高品質で堅牢なCIの構築に取り組んでいます。

1. プラットフォーム エコシステムの拡張: Windows システム ソフトウェア製品がまもなくリリースされる予定ですので、ぜひテストして体験してください。
2. 自動テストの種類を増やす: 今後は、カオス テストやパフォーマンス テストなど、さまざまなテスト方法を CI プロセスに統合し、ソフトウェアの品質を継続的に向上させていきます。
3. CI 使用コストの最適化: さまざまなユースケースのニーズに合わせてさまざまなランナーを正確に割り当てることで、CI 運用全体をより経済的かつ効率的にする予定です。
4. ビルド パフォーマンスの向上: リリース パイプラインのリファクタリングによってビルド パフォーマンスに多少の影響が出ていますが (#2113)、よりスマートなビルド キャッシュ手法を採用することで、ビルド プロセスをさらに高速化する予定です。
5. ソフトウェアサプライチェーンのセキュリティ強化：現代のソフトウェア成果物管理において、ソフトウェアサプライチェーンのセキュリティはますます重要になっています。オープンソースプロジェクトとして、私たちはソフトウェア製品のセキュリティ、信頼性、透明性を確保します。SBOM管理、ソフトウェア署名、検証といった基本的なセキュリティ対策をリリースプロセスに組み込む予定です。

GitHub Actions を最大限に活用するには課題も伴いますが、私たちは継続的な改善に取り組んでいます。ご興味があり、さらに詳しく知りたい方は、ぜひご参加ください。  スラック コミュニティでの議論にぜひご参加ください！皆様からのご提案は、今後の改善活動において重要な役割を果たすことになるでしょう。

翻訳者紹介

51CTO のコミュニティ エディターである Liu Wangyang (ニックネームは Mingmingruyue) は、大手企業のシニア Java エンジニアであり、5 年間の開発経験を持ち、複数の主流のテクノロジー ブログ プラットフォームでブログ エキスパートの称号を保持しています。

タイトル: GitHub Actions を使用したリリース CI のリファクタリングに関する実践的なヒント、著者: Greptime