David Taylor
Nov 18, 2025 • 4 min read
2013年当時、DiscourseはRails 3とEmber 1.0でローンチしました。長年にわたり、私たちはこれらのフレームワークおよび多くの依存ライブラリと共に進化し、新機能・パフォーマンス改善・モダンなベストプラクティスが登場するたびに最大限活用してきました。
10年以上にわたり、完全な書き直しが必要になったことは一度もありません。すべてのメジャーアップグレードはインクリメンタルに採用され、テーマやプラグインのエコシステムもその流れに乗ってきました。このインクリメンタルな考え方こそが、Discourseを大規模に持続可能な状態に保つための最も重要な要素の一つです。
近年、私たちはこの考え方を専任の「Developer Experience Team（開発者体験チーム）」という形で公式化しました。このチームのミッションは、Discourseエコシステム全体の開発体験をできる限りスムーズに保つことです。その活動の中核をなすのが、フレームワークのリリースへの追従と、アップグレードを予測可能・信頼性高く・迅速に行うためのワークフローおよびツールの構築です。
素晴らしいことです！しかし、実際にどのように取り組んでいるのでしょうか？
Discourseの拡張性をざっくりと見る
Discourseはテーマとプラグインによって拡張できます。大まかには以下のとおりです：
- テーマはフロントエンドをカスタマイズします
- プラグインはフロントエンドとバックエンドの両方をカスタマイズできます
フロントエンドおよびバックエンドのカスタマイズはRailsとEmberのフルパワーにアクセスできます。これにより、開発者には非常に大きな柔軟性が与えられると同時に、ベストプラクティスが進化するにつれてコードを最新の状態に保つという同等の責任も生じます。この開放性と責任のバランスは、文明的な議論のためのオープンソース構築キットとしての私たちの精神の根幹をなしています。
インクリメンタルな改善を推進する
Discourseに新しいAPIやパターンを導入する際、私たちの目標は新旧のアプローチが共存できるようにすることです。これにより、コードを段階的に移行できます。まずDiscourseコアで、次に公式テーマやプラグインで対応し、最終的に古いパターンを非推奨にして削除するという流れです。
広いエコシステムに向けては、プラグインやテーマの作者が単一の「ビッグバン」リリースに合わせて調整することなく、自分のペースで更新できることを意味します。
Discourseのカスタマイズのほとんどはフロントエンドに触れるため、変更の慎重な展開はとりわけ重要です。Emberのバージョニングへのアプローチは非常に貴重です。新しいAPIは既存のアプリを壊すことなく追加され、非推奨となったAPIもしばらくの間は相互運用可能な状態が維持されます。その思想は、私たち自身の変更推進のためのワークフローと完全に一致しています。
私たちはプラットフォームの変更を4つの意図的なフェーズを経て進めます：
- 非推奨が導入されるが、ほとんどの環境ではサイレント化されます。この初期段階では、「オオカミが来た」と叫ぶように開発者全員のコンソールを警告メッセージで埋め尽くしたくはありません。アップグレードプロジェクトに携わるエンジニアはローカル環境でメッセージを有効にし、Discourseコアおよび公式テーマ・プラグインの関連コードのモダナイズに取り組みます。
- 非推奨のサイレント化が解除され、ブラウザの開発者コンソールに表示され、テーマ・プラグインのテストスイートにも現れます。
- 管理者向け警告バナーへのエスカレーションとして、本番環境に残っている使用箇所に対する最後のリマインダーとなります。
- 非推奨のAPIが削除されます。
非推奨が未解決の場合の最終警告
このプロセス全体を通じて、ホスティングプロバイダーがdiscourse-deprecation-collectorを通じて実際のテレメトリを収集するためのツールを提供しています。これにより、タイムラインを調整し、ドキュメントを改善し、顧客がサポートを必要としている箇所を特定するのに役立てています。
非推奨が解消されていく様子を示す本番テレメトリ
アップグレード作業の自動化
私たちは500以上のテーマとプラグインを管理しています（そのうち半数以上はオープンソースです）。この作業をスケールさせるには、自動化とツールへの信頼の両方が必要です。
最初の防衛ラインは常にリンティングです。非推奨のパターンを検出してモダナイズするためのカスタムlintルール（多くの場合、自動修正機能付き）を提供しています。フロントエンドにはESLintを、バックエンドにはRuboCopを使用しています。eslint-plugin-emberのようなアップストリームのライブラリが必要なルールを含んでいる場合もありますが、含まれていない場合は独自のDiscourse固有のルールを構築して配布します。
一見すると、カスタムlintルールを書くことは、コードを手動で修正するよりも手間がかかるように見えるかもしれません。しかし、数百ものリポジトリ全体では、その投資はすぐに元が取れます。ルールが洗練されテストされると、高い信頼性と最小限のリスクでエコシステム全体に適用できます。
個別ファイルの静的解析では対応できないより大規模な変更には、codemodsも活用しています。例えば、discourse-gjs-codemodは、Emberチームのtemplate-tag-codemodを軽くカスタマイズしたものです。
discourse-gjs-codemodのアナウンスとドキュメント
codemodsとlint修正を500以上のリポジトリに適用するために、mass-prを使用しています。このツールにより、数百のリポジトリを順番に処理し、アップグレードを適用し、変更のプルリクエストを作成できます。また、必要に応じて人間による介入のために一時停止する機能もサポートしています。
機械的でリスクの低い変更については、mass-mergeツールを使用して安全に大規模マージを行います。
今後の展望
継続的かつインクリメンタルなモダナイゼーションにより、Discourseは破壊的な書き直しなしに進化し続けることができています。品質を高く保ち、APIを安定させ、チームの生産性を維持しながらです。
私たちが構築したツールとワークフローは、大規模なアップグレードプロジェクトを、日常的な機能開発と並行して実施できる、繰り返し可能でよく理解されたプロセスへと変えています。また、オープンソースエコシステムがカスタマイズを健全かつ互換性のある状態に保ちやすくもしています。
フレームワークとベストプラクティスが進化し続ける中でも、インクリメンタルな改善への私たちのコミットメントは変わりません。必ずしも華やかな作業ではありませんが、それこそがDiscourseを前進させ続けるものです。
原文はこちら：
Good Loopでは、Discourseのセルフホスティングを安価で提供しています。開発元であるCDCK社の協力のもと、公式ブログ記事の翻訳・公開など、日本での普及にも努めています。