.NET Core のオープン ソース化に関する最新情報


本記事は、マイクロソフト本社の .NET Blog の記事を抄訳したものです。
【元記事】 .NET Core Open Source Update 2015/1/28 11:39 AM

この喜びをどう表現すれば皆様に伝わるでしょうか。オープン ソースは、私のチームがこれまで関わってきたプロジェクトの中で最も活発なものの 1 つと言えるかもしれません。現在、オープン ソースは大きなトレンドとなり、熱心な協力者や支援の手が絶え間なく集まっています。

この記事では、長らくお伝えしていなかった最新情報や、これまでの変更点、今後の概要についてお伝えします。皆様のお役に立つ記事となっていますので、ぜひ最後までお付き合いください。

 

嬉しい悲鳴: 画面に表示しきれないほどの数の協力者

オープン ソース化に関する初めての記事 (英語) の中で、私はマイクロソフトの複数のチームが外部から意見を収集していることについてお伝えしました。オープンソースへの取り組みを強化している理由は、リリース サイクルが数年程度から、ほぼリアルタイムへと変化していることにあります。サービスについては、恒常的にデプロイされることがごく一般的になっています。その結果、サービスの正常性を計測するさまざまなツールや指標が作成されました。それはなぜかと言えば、問題が発生した後に事態を把握するのではなく、問題が発生しようとしているまさにそのときに問題を検出することが重要になったからです。一度に大きな変更を実装するのではなく、少しずつ調整していくことで、リスクを大幅に減少させることができます。

オープン ソースはこの考え方に沿ったものです。チームでは、自分たちの現在の状況を把握すると同時に傾向をつかむことで、それがどのように変化していくかを多少なりとも予測したいと考えています。私たちが使用している指標は、管理職がチームや個人を評価するためのものではなく、自分たち自身を評価するためのものです (実際、エンジニアにとってはシステムを操作してごまかすことなど簡単であるため、指標によってエンジニアを評価することには意味がありません)。

ここで、私を幸せにしてくれたある指標をご紹介します。corefx のレポートのグラフ (英語) です。これを確認すると、GitHub では次のように表示されます (英語)

clip_image001

なんと、協力者の数が表示しきれません。1,000 人を超える方々が私たちに協力してくださっているのです。もちろんこの数字は延べ数で、現在協力をいただいている方の実際の数を表したものではありません。しかし、コミュニティのメンバーから大きな関心をお寄せいただいていることはたいへん貴重なことであり、また、非常に光栄です。

プル リクエストの総数も非常に多く、昨年 11 月以降 250 回のプル リクエスト (コミュニティとマイクロソフト両方の協力者からの合計) がありました。

clip_image002

(上のグラフの横ばいの期間については、こちらの仮説 (英語) もご参照ください)。

また嬉しいことに、チームの人数を超える数のコミュニティ メンバーにご協力いただいていることもわかりました。しかも、マイクロソフト社内の協力者よりもコミュニティの協力者のほうが多いのです。これはオープンソースでの活動の拡大が首尾よく進んでいる証拠であり、コミュニティが開発を進めるための大きな力となっています。

clip_image003

 

リアルタイムのコミュニケーション

.NET Core をオープン ソース化した理由の 1 つは、より強力なエコシステムを構築して活用するためです。このことについては昨年の記事でご説明しました。

.NET Core をオープン ソース化することにより、ユーザーの皆様とリアルタイムでコミュニケーションを取れるようになります。もちろん、それほど緊密なコミュニケーションをお望みでないユーザーもいらっしゃるでしょう。しかし、ご意見を迅速かつ恒常的にいただけることは製品の改良に役立ち、私たち全員の利益につながっています。

リアルタイムであることには 2 つの側面があります。リアルタイムにご意見をいただけることは大切ですが、それへの対応はどうでしょうか。Connect から不具合を報告した場合、Skype を除いては、ユーザーが知っているリアルタイムというコンセプトとは異なっているという印象を持つかもしれません。これについてはマイクロソフトの一員である私の責任でもあります。プロダクトチームのメンバーの意識は、積極的なユーザーとは数年程度の開きがあるため、迅速に対応することは非常に難しいのです。

応答の速さについては、次の 2 つの指標から判断しています。

  • 問題への応答の速さ: 最初のコメントを書き込むまでに要した時間を表します (下図の “Distribution of first response time for issues (問題への初回応答)” を参照)。
  • 問題の収束までの速さ: 解決したか破棄されたかを問わず、問題が収束するまでに要した時間を表します (下図の “Time to close an issue (問題の収束までの時間)” を参照)。

次の 2 つのグラフをご覧ください。

clip_image004

clip_image005

これまでのところ非常によい結果が得られており、リアルタイムの共同作業が実現されていると言っても差し支えないと思われます。しかし、改善の余地もあります。初回応答までの時間は 1 週間以内に短縮するべきであり、この点については改善に向けて取り組んでいます。

 

オープン ソースでの開発プロセス

これらの指標を公開する理由の 1 つに、チームがオープン ソースでの開発プロセスに全力で取り組んでいることを示す目的があります。

しかし、指標を公開してブログ記事に掲載するだけでは、オープン ソースでの開発プロセスを確立することにはなりません。重要なのは、オープンソースの世界のエンジニアリング プロセスについて見直すということです。Channel 9 のインタビュー (英語) では、オープン ソース化によりもたらされる新しい機会を意識することに触れているほか、ただ既存のエンジニアリング手法やプロセスを公開するだけではないことについてお話ししています。すべてを公開することをためらっているわけではなく、既存のプロセスは数年単位のリリースサイクルに最適化されているので、そのうちの一部はオープン ソース化や迅速な配信には役に立たないのです。これに対処するために、工程の少ないプロセスからスタートし、必要なものだけをそれに追加していこうと考えました。

この過程では、一部には既存のプロセスを採用し、そこに新しいプロセスを追加することになります。現在採用されているプロセス、およびどのような調整を行ったかについて簡単にご紹介します。

 

コード レビュー

私は、コード レビューがソフトウェア エンジニアリングの共同作業の中で間違いなく最も重要であると考えています。第三者がコードを確認することによって、どれだけの数のミスを事前に回避できるのかを知りました。また、コードレビューによって、チーム全体で知識を共有することも簡単にできます。コード レビューの経験がない方は、ぜひすぐにお試しください。一度経験すると、これなしでは成り立たないとおわかりいただけるはずです。

マイクロソフトへの GitHub のプル リクエスト (英語) を見ると、これがコミュニティからのものだけではなく、自社のコード レビューにもプルリクエストを活用していることがわかります。実際、.NET Core の一部では既に GitHub が活用されており、内部のみでのコード レビューは実施せずに、すべて GitHub で公開して行っています。

GitHub のプル リクエストの活用には次のようなメリットがあります。

  • 要望を共有できる: マイクロソフト社内の同僚に対するフィードバックを公開することによって、その進展を協力者の方々にも把握していただくことができます。
  • コミュニティに関与する: プル リクエストにはだれでもコメントできるため、コミュニティ全体のフィードバックがコミュニティ メンバーとマイクロソフトのスタッフの両方に役立つことになります。
  • プル リクエスト件数が伸びる: というのは冗談ですが、コード レビューにプル リクエストを利用することにより、すべての作業を 1 か所でできるという副次的なメリットがあります。この手法により、私が同僚のコードをレビューすることと、コミュニティのプル リクエストをレビューすることにまったく差がなくなりました。このため、コード レビューを公開して実施することによって作業が楽になることはあっても煩雑になることはありません。

 

API のレビュー

開発チームでは、API を使いやすくしたり、確立されているパターンを活用したり、わかりやすいようにバージョンを付けられるようにしたり、前のバージョンと互換性を確保したりするなど、API の設計に多くの時間を費やしています。

API の設計には下記のアプローチを採用しています。

  • ガイダンス: マイクロソフトでは、優れた .NET API を設計するために必要なものをドキュメント化しています。これに関しては、マイクロソフトでアーキテクトを務める Krzysztof Cwalina が『Framework Design Guidelines』 (邦訳『.NET のクラスライブラリ設計』) という本にまとめ、一般に公開しています。また、非常に簡単にまとめたものを Wiki (英語) でも公開しています。
  • 静的分析: 静的分析 (以前は FxCop と呼ばれていました) を実施して、不適切な命名や確立されているパターンへの非準拠などの一般的な違反を検出しています。
  • API レビュー: 上記に加えて、API レビュー担当者が個々の API をレビューし、それが公開されます。この作業は日常的に行っても効果的ではないため普段は実施していませんが、API 開発チームからプロトタイプや提案書が出されると、一般的な API 設計のレビューを行います。内容が複雑な場合は、必要なだけレビューを繰り返すこともあります。たとえば、Roslyn API の場合は API の数とコンセプトが非常に膨大であったため、レビューを何度も何度も実施しました。

ガイドライン自体も進化するため、この工程は非常に大切なものです。たとえば、新しい言語機能とパターンを追加した場合、優れた基準を定め、最終的にそれをガイドラインとして体系化することが重要です。しかし、最初からどのようなガイドラインが正しいかがわかっていることはほとんどなく、普通は経験に基づいてガイドラインを作成していきます。多数の API のレビューを専門的に行う小規模なグループを作成すると、集中して類似性やパターンを発見することができるため非常に有効です。

オープン ソース化においては、API レビューをどのようにしてオープン ソースでの開発プロセスに組み込むかについて知恵を絞りました。チームは GitHub で提案書を公開 (英語) し、皆様からいただいたフィードバックに基づいて運用を始めました。現在の API のレビュー手順は Wiki (英語) にまとめられています。

しかし、ドキュメント化されているプロセスは全体の中のごく一部でしかありません。多くの方がご指摘のとおり、レビューが非公開で実施される場合、その負担は非常に大きくなります。結局のところ、オープンソースでの開発プロセスを実現することの目的は、コミュニティを活性化し、皆様にうまくご協力いただくことです。そのためには、マイクロソフトのスタッフが持っている内部的な知識をコミュニティに浸透させる必要があります。そこで、開発チームではレビューのようすを録画して Channel 9 にアップロード (英語) するようにしました。また、ノートもアップロード (英語) して、対応するビデオへのリンクを提示しています。

もちろん、API の設計などの複雑な内容のものはレビューのようすを見ただけで理解できるものではありません。しかし、レビューのようすを見るだけでも、マイクロソフトが目指す方向や問題に対してどのように取り組んでいるかをご理解いただけると思います。

また、革新的な変更 (英語)BCL のパフォーマンスに関する考慮事項 (英語) など、これまであまりドキュメント化されていなかった分野のドキュメント化も開始しました。どちらのページも未完成ですが、皆様からご意見をいただけますと幸いです。

 

協力者とのライセンス契約 (CLA)

ほかに最近実施された変更として、Contributor License Agreement (CLA) (英語) への署名を協力者の方にお願いするようになりました。CLA のコピーは .NET Foundation (英語) でご確認いただけます。これは、.NET Foundation でプロジェクトにお寄せいただいたすべてのコードを適切なライセンスに基づいて配布できるようにするための措置です。

次に、協力者の方に CLA が提示されるときの流れを説明します。

  1. 協力者がプル リクエストを送信します。
  2. この変更に CLA が必要であるかどうかが自動的にチェックされます。たとえば、ちょっとしたタイポの修正などでは通常 CLA は不要です。CLA が必要ない場合、プル リクエストに cla-not-required というラベルが付与され、これで協力者の方の手続きは終了です。
  3. CLA が必要な変更の場合、署名をいただいているかどうかをシステムが確認します。既にいただいている場合、このプル リクエストに cla-signed というラベルが付与され、これで協力者による手続きは終了です。
  4. CLA に署名していただく必要がある場合は、ボットによりこのプル リクエストに cla-required というラベルが付与され、該当する協力者に宛てて CLA への署名を求めるコメントが Web サイトに投稿されます (完全に電子化されており、ファックスで送信していただく必要はありません)。CLA に署名いただくと、このプル リクエストに cla-signed というラベルが付与され、これで協力者による手続きは終了です。

その後の工程では、cla-not-required または cla-signed というラベルが付与されているプル リクエストのみが処理されます。

ここで強調したいことは、.NET Foundation 全体で単一の CLA を採用することを目指しているということです。このため、.NET Foundation のいずれかのプロジェクトで CLA に署名すると、他のプロジェクトでもこれが適用されます。つまり、corefx (英語) でプル リクエストを送信したときに CLA に署名した場合、roslyn (英語) で別の CLA に署名する必要はありません。

 

CI システムの自動化

チームでは常に自動のビルド システムを使用しています。トリガーはチームによって異なりますが、最も一般的な手法は、日常的なビルドと何らかの変更を行う前に検証するためのゲートを組み合わせる方法です。オープンソースの世界では、内部のビルド システムはあまり役には立ちません。

GitHub で最も一般的な手法は継続的インテグレーション (CI) システムで、この方法ではプルリクエストを含むプッシュごとにビルドを実行します。この場合、プル リクエストのレビュー担当者は、変更がビルドに合格するかどうかを気にする必要はありません。登録されている CI システムにより、対応する PR が更新されます。

GitHub 自体には CI システムの機能はないため、サードパーティのものを使用しています。当初は、オープン ソース プロジェクトでは無料で使用できる AppVeyor (英語) を採用していました。現在でも私はこの製品を個人的なプロジェクトのすべてで使用しています。まだご利用になったことがない方は、ぜひお試しください。残念ながら現在 AppVeyor のサポートは Windows でのビルドのみに制限されていますが、クロス プラットフォームで作業をできるように、他のシステム (特に Linux) でも実行できるようにしたいと考えています。そのため、現在はマイクロソフト独自に Jenkins サーバーをホストして CI サービスを運用しています。

 

今後の改良点

チームはまだ学ぶべき点も多く、得られたことについて積極的に公開するべきであると考えています。David Kean は、オープン ソースに関するインタビュー (英語) の中で次のように述べています。

遠慮なくご意見をお寄せください。誤っている点や行き過ぎている点、改善したほうがよい点などがありましたらご指摘いただきたいと考えています。

フィードバックはできるだけ早い時期にいただいたほうが有効に活用できます。そこで、私たちの考えや学んだことを、意思決定を行う前に皆様にお伝えしようと考えました。その一部をご紹介します。

  • ボット間でのやり取り: マイクロソフトが独自の CI システムを採用し CLA プロセスを導入したときに、コメントの自動投稿システムに不可欠であるボットを積極的に活用しました。その結果、PR の議論の中に不要なコメントが大量に入り、場合によってはそのようなコメントが過半数を占めることもありました。これは望ましい状況ではありませんでしたが、マイクロソフトはこれをそれほど深刻には考えていませんでした。しかし、あるお客様から「議論の内容を把握しづらいため興味を削がれる」という声をいただきました。このようなご意見は、潜在的な問題を認識するきっかけとなるため非常に貴重です。その後すぐに、かなりの方がこのことをわずらわしく思っていることがわかり、ボットの発言数を減らす作業を優先的に実施しました。おしゃべりな C-3PO から口数の少ない R2-D2 に配役が替わり、無駄な発言を控え、短く有意義なコメントを少数だけ投稿するようになりました。
  • Git の利用: チームのメンバーのほとんどは集約的なバージョン管理、特に Team Foundation バージョン管理 (TFVC) の経験が豊富です。Git の使用経験が豊富なメンバーもいますが、チームの中にはまだ、トピックのブランチの使用や、多数のリモート環境間でのコードの受け渡しなど、集約化されていないワークフローも残っています。先日、Andrew Arnott が .NET チーム向けに Git のトレーニングを実施しました。Arnott については、Immutable コレクションに関する Channel 9 のインタビュー (英語) でご存知の方もいらっしゃるかもしれません。この Git のトレーニングのようすは Channel 9 にアップロード (英語) されています。このようなビデオにご興味をお持ちの方は、ぜひご連絡ください。
  • "up-for-grabs": オープン ソース コミュニティでは、コミュニティがいつでも参加できるように、イシューをマークする方法がパターンとして確立されています。マイクロソフトではイシューに "up-for-grabs (英語)" というラベルを付けることにしました。これは、現時点ではマイクロソフトが自社内で取り組む予定のない、比較的取り組みやすいと思われる不具合や機能であることを表しています。Up For Grabs (英語) という Web サイトには、コミュニティにサポートを求めているオープン ソース プロジェクトがずらりと並んでいますが、corefx プロジェクトも、Brendan Forster (英語) の手により現在このサイトのリストに掲載されています。また、Brendan の質問に基づいて、"up-for-grabs" が何を意味しているかという議論も開始 (英語) されています。ご興味のある方はぜひご参加ください。

また、ほかにも関心のあるトピックがありましたら、ご連絡いただけますと幸いです。

 

使用可能なライブラリ

Connect() イベント (英語) を開催した時点では、ライブラリのごく一部のみが GitHub で利用可能な状態でした。

  • System.Collections.Immutable
  • System.Numerics.Vectors
  • System.Reflection.Metadata
  • System.Xml

上記の 4 つのライブラリのコードは、合計で 14 万 5,000 行でした。それ以降ライブラリが追加され、コードの量は 3 倍以上に増加し50 万行を超えました

  • Microsoft.Win32.Primitives
  • Microsoft.Win32.Registry
  • System.Collections.Concurrent
  • System.Collections.Immutable
  • System.Collections.NonGeneric
  • System.Collections.Specialized
  • System.Console
  • System.Diagnostics.FileVersionInfo
  • System.Diagnostics.Process
  • System.IO.FileSystem
  • System.IO.FileSystem.DriveInfo
  • System.IO.Pipes
  • System.IO.UnmanagedMemoryStream
  • System.Linq.Parallel
  • System.Numerics.Vectors
  • System.Reflection.Metadata
  • System.Text.RegularExpressions
  • System.Threading.Tasks.Dataflow
  • System.Xml

しかし、これで満足してはいられません。現状では、.NET Core で予定されているうちの約 25% にすぎないのです。詳細なリストはこちらの Excel スプレッド シート (英語) でご覧いただけます。

clip_image006

 

まとめ

マイクロソフトでは、11 月以来オープン ソースでの開発モデルの改善を進め、コードレビューに続いて API レビュー (英語) もオープン ソース化しました。そして何より、非常に活発なコミュニティの支えにより、チームのメンバー数を超える数の協力が得られています。これは願ってもない状況です。

しかし、オープン ソース化の取り組みはまだ始まったばかりであり、今後も積極的に .NET Core ライブラリを GitHub に公開していく予定です。これに加えて、ランタイム チームは CoreCLR リポジトリの準備を進めています。こちらも近いうちに最新情報をお伝えしますので、ご期待ください。

いつものお願いではありますが、皆様からのたくさんのご意見をお待ちしています。.NET Foundation のフォーラム (英語)、または @dotnet 宛てにお気軽にコメントをお寄せください。

Comments (0)

Skip to main content