この記事はStef Walterによる CentOS Stream is Continuous Delivery の翻訳です。
継続的デリバリーの基礎：難しいことを継続的に行い、簡単になるようにする。
外から見ると、RHEL（そしてCentOS Linuxコンテンツ）を構築する方法は、この10年間で変わっていないように見えるかもしれません。しかし、その内部ではRHELを開発する方法について、顧客に影響を与えることなく記念碑的な変革を成し遂げようとしています。
私は様々なカンファレンスでこの話をしてきましたが、CentOS Linux 8とCentOS Streamについての発表は、ここで話をするきっかけを与えてくれました。
3年前、RHELエンジニアリングで働いている私たちの何人かはアイデアを持っていました：継続的インテグレーション、継続的デリバリー、予測可能なリリース頻度などの現代的な開発プラクティスを、早期リリースの頻繁なリリース、プルリクエスト、フォーク、コードレビューなどのオープンソース開発プラクティスと組みあわせてRHELに適用したらどうだろうか……。
明白でしょう? ……いえいえ。
Linuxディストリビューションは継続的インテグレーションとデリバリの壮大な挑戦
私をオープンソースに引き込んだのは、常にこのインテグレーションの課題でした。連携の取れていないプロジェクトが無限にあります。これは本当に驚くべき進化の例です。目を凝らしてみつめれば、奇妙な生物、突然変異、小宇宙、自然淘汰のすべてが目の前で起こっているのがよくわかります。
過去20年間、私は100以上の異なるプロジェクトに貢献してきました。私の貢献は、ユーザーが首尾一貫した体験を持てるように、プロジェクトをシームレスに機能させることに重点を置いていました。
Cockpit プロジェクトはその最も目に見える例です。私たちは、それぞれが別々に開発され、10以上の異なるディストロで異なるスケジュールでリリースされた約95のLinux APIとコンポーネントを、首尾一貫したユーザーエクスペリエンスに統合し、6年以上にわたって隔週で安定したリリースを提供してきました。
Linuxが継続的インテグレーションとデリバリーの壮大な挑戦であるとすると、私はRHELを他に類を見ない絶対的な挑戦として見ています: 1万の調整されていないプロジェクト、数千人の貢献者、追加の構造（kABIのような）と追加の保証（10+3年間のハードウェアイネーブルメントのような）を加えて、それらを継続的にインテグレーションし、毎日安定したリリースを配信するということです。
夢見るような目(まあ、涙目)で、私たちはその活動を「Always Ready RHEL」と呼びました。
この取り組みは、何千ものパッケージを継続的インテグレーションに丹念に組み込むことから始まりました。2017年の時点で、すべてのRHELコンポーネントのCIがまだなかったことに、多くの人がショックを受けました。しかし、もし簡単なことであれば、はるかに早くに実現していたでしょう。
今日では、RHELに入るすべての更新は、継続的インテグレーションのゲーティングを通過しなければ、コンポーネントの自動テストを実行するナイトリー構成に組み込まれません。そして、各変更は、RHELのナイトリービルドに含まれる前に、（主に品質エンジニアリングによって）RHEL品質であることを明示的に検証される必要があります。
「Always Ready RHEL」の取り組みは、今ではCentOS Streamとして知られている継続的デリバリーで続いています。RHELのナイトリー構成は、すでにCentOS Streamで配信されています。継続的デリバリーの全体的なポイントは、各リリースを前のリリースと同じように安定したものにすることです。私たちは毎日配信しています。
もう十分ですか?……いえいえ。
素人目には、CentOS Streamはすでに RHEL と同じくらい安定しています。
しかし、この挑戦は他に類を見ないものであり、RHELエンジニアはそのことを認識しています。それぞれのチームが作業をRHELへ統合する方法は、上流のコミュニティと同じくらい多様です。しかし、非常に多くの人々がこの目標の異なる側面について一緒に活動しているので、継続的デリバリーを現実のものにすることができると確信しています。
8と9のデリバリーの流れはこのようになっています: 左側にFedoraのリリースを見ることができます。この図は、CentOS StreamがRHEL X.Yリリースの作業と同義であることを示しています。技術的に言えば、CentOS StreamとRHELのアップデートは、同じソースからビルドされた2つのバイナリパッケージです。更新は、RHELのナイトリービルドに公開される場合に限り、CentOS Streamに公開されます。したがって、RHEL のナイトリービルドは、あなたが取得する CentOS Stream アップデートそのものです。いったんFedoraから分岐すると、私たちは、それぞれの変更が以前に行ったすべてのものの上にきれいに統合されるように開発を進めます。更新は、RHELの未発表のマイナーアップデートに公開された場合にのみ、CentOS Streamにプッシュされます。RHELの顧客は、後にこれらのそれぞれをRHEL Errataアップデートとして見ることになります。
これらの変更のそれぞれは、バグ修正であれ、機能拡張であれ、CentOS Streamに到着する前に、自動テストでテストされ、品質エンジニアリングのプロセスで検証されます。
Streamで直接、そしてすぐに見えない唯一の作業は、すでにリリースされているRHELのマイナーバージョンに対する作業です（図では「errata」と表示されています）。多くの場合、この作業は、NDAの下で行われたり、(未公開の脆弱性のため)公開が禁止されていたり、あるいは、既にCentOS Streamに含まれている変更点のバックポートとなっています。
CentOS Stream は、RHEL と同程度の安定性を意図しています。継続的デリバリーの基本ですね。
しかし、RHELとしてリリースされた製品でさえ、完全に安定しているわけではありません。7月に、RHEL (およびCentOS) の「boot hole」脆弱性の修正は、CVEそのものよりもはるかに悪い結果となりました: 多くのシステムが起動しない原因となりました。酷いことです。
結果として、私たちは上流のコンポーネントの再構築に時間を投資しているだけでなく、このようなことが二度と起こらないようにプロセスを適応させています。直して、繰り返します。
私はCentOS Linux 8のEOLの決定には参加していませんでしたが、CentOS Streamの実現に向けて努力しています。これは、RHELをオープンソースにするためです。エコシステム全体と協力して、このエキサイティングな継続的インテグレーションとデリバリーの課題に取り組むことができる場とするためです。
製品をオープンソース化するのは難しいことですが、私たちは驚くべき進歩を遂げてきました。これまでのところ、RHELの開発プロセスをFedoraと連携させ、RHELのすべての実際のソースを読みとり可能な場所に配置し、貢献者がRHELのどの部分に対してもプルリクエストを開くことができるようにし、早期かつ頻繁にリリースしました……
そして、これはほんの始まりに過ぎません。期待どおりのタイミングでRHELのリリースを提供し続けつつ、何百人もの人がこのCentOS Streamという変化に取り組んでいます。
CentOSストリームは、安定した、信頼性の高い、RHELの継続的デリバリーです。
