RHELはどのようにして作られるか

この記事は Brendan Conoboy による How RHEL is Made の翻訳です。

今週、Red HatはCentOS Stream 8に全力を注ぐ計画を発表し、その結果、1年後にはCentOS Linux 8が廃止されることになりました。 CentOS Streamはもともと2019年9月に発表されたもので、開発や検証が進むとすぐにアップデートを提供するRHELの継続的なリリースです。 現在CentOS Linuxを使用している多くの人は、CentOS Stream 8が自分の使用に適したディストリビューションになるのかどうか、テストされているのか、安定しているのか、などを疑問に思っています。 CentOS Stream に何が期待できるかを知るには、Red Hat Enterprise Linux がどのように構築されているかを知ることが一番の出発点となります。 それでは、さっそく始めましょう!

Red Hatは長い間Linuxのリリースを行っており、そのオリジナルの開発方法はアジャイルマニフェストよりも前から行われています。 歴史的に、RHELは閉鎖されたグループにより構築されており、その計画はクローズドでした。RHEL 8のローンチ時に発表された、予測可能な6ヶ月毎のマイナーリリース/3年毎のメジャーリリースの発表でさえ記念碑的な情報公開と思えるほどでした。 幸いRed HatのLinuxディストリビューション開発方法は、 前世紀に始まった時から進化したというだけでなく、ちょうど18ヶ月前にRHEL 8が発表されて以来、既に複数世代のプロセス改善が行われています。 アップストリーム・ファースト、莫大な品質エンジニアリング、エコシステムパートナーシップ、カスタマーケアなどの基本的なことは変わりませんが、これらの基本的なことがらの実装を改善するために継続的に取り組んでいます。

基本からはじめましょう。すべてのRHELマイナーリリースは、前のリリースをベースにして、アップストリーム開発のバックポートを追加します。 しばしば、Red Hatter自身がこれらのパッチのオリジナルの作成者ですが、近道はありません。最終的なリリースへパッチの統合作業を開始する前に、すべてのパッチがアップストリームに受け入れられる必要があり、これは最初のテストになります。 しかし、アップストリームにパッチが存在するだけでは製品へのパッチの組み込みは保証されません。

RHELにアップストリームの変更を導入する決定は、チームの決定であり、チームは大規模です:開発者、品質エンジニア、サポート担当者、プロダクトオーナー、および様々なパートナーが、優先順位と実現可能性について一緒に作業します。 一旦、決定に達し、コミットメントがなされると、開発者と品質エンジニアはコードを書き始めます。 ご存知のように、最も和気藹々としたライバル関係の中で、開発者は誰にも壊すことのできないコードを書こうとし、品質エンジニアは開発者の書いたコードを壊す一連の方法を作成します。 ここで Red Hat が投資している 2 番目の重要な領域は、テストです。

ユニットテスト、システムテスト、カーネルとユーザースペースの ABI 適合性テスト、パフォーマンステスト、依存関係テスト、アーキテクチャテスト、ドライバーテスト、負荷テストなど、多数のテストを行っています。 テストを持つことは基本的なことですが、応用することで意味をもたらします。 ここで、Red Hat が投資する 3 番目の重要な領域、プロセスインフラストラクチャについて説明します。

Red Hat は過去数年間、一連の「Always Ready」オペレーティングシステムに取り組んできました。 その目標は、名前の通り「いつでもOSをリリースする準備ができている」ということです。 これは、言うは易し行うは難しです。複雑なシステムでは、多くのことが意図しない結果をもたらす可能性があります。 この問題を処理するために、私たちは自動化のレイヤーを使用し、変更への信頼性を徐々に高め、それらが統合されてディストリビューションにリリースされるようにしています。 ここでは、RHELのすべての変更がRHELに含まれる前に通過する必要があるプロセスについて、ハイレベルな概要を示します。

変更がRHELを対象としている場合、実際にRHELに含まれる前に、複数の段階的なステップが発生します。 変更はビルドされますが、唯一の確かな結果は、CIシステムがそのビルドで一連のテストを実行することです(ビルドは、まだ一般には利用できません)。 これらのテストに合格した場合、コード変更に特化した事前検証の第二ラウンドが行われます (まだ十分ではありません)。 そして、これらのテストに合格した場合、その変更は暫定的にエラッタシステムに含まれ、さらなる検証の対象となります (まだ公開する準備はできていません)。 体系的なテストスイートが、全体的な機能検証をするため、結合された全体に対して実行されます。 そして、これらのテストに合格した場合にやっと、CentOS Stream システムから利用可能なアップデートとして認識される場所へ、このビルドが組み込まれることになります。 これは長いパイプラインであり、毎日多くの変更が行われています。 このシステムのビジョンやアーキテクチャに興味のある方は、「CentOS Streamは継続的デリバリーです」を読んでください。

このシステムの説明はエレガントで安心感があるように見えるかもしれませんが、実際に動いているのを見ていると全く逆のことを感じるかもしれません。テストが行われれば行われるほど、より多くのバグが発見され、Red Hatは大量のテストを行います。 歴史的に、RHELの開発は、閉鎖されたグループで行われ、人々を日常的なバグの特定と修正プロセスから隔離し、最終的な結果だけを世間に見せるようにしてきました。 将来的には、RHEL 9に近づくにつれてRHELの開発がより透明性を増して、このプロセスが不安を覚えるほどに可視化されてくるでしょう。 テストシステムは、そのような失敗がエンドユーザに届かないように構築されていますが、より深く覗き込むと、オペレーティングシステムの開発が非常に厄介なことに驚くかもしれません。

最後に、これらすべてのことがどれくらいでCentOS Streamに反映されるのか疑問に思っている人に、良いニュースがあります:それは、RHEL 8.4とCentOS Stream 8ですでに今日行われています。 RHELのビルドが検証されると同時に、CentOS Streamにも配信されます。 もちろん、まだ完全ではありません。CentOS StreamはRHELの周りに開発者コミュニティを創るという、そのミッションをまだ実現していません。Red Hatと関わり、将来のRHELを形作るためのより多くの選択肢がある目標へ向かっている途中です。 より良いテストから将来のコラボレーションにおける多くの側面まで、常に改善の余地があります。RHELの構築を共有することで、あなたとともに、そしてあなたのためにより良いOSを構築していきます。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。