【MSR2017】 Continuous Defect Prediction: The Idea and a Related Dataset
著者 Lech Maydeyski , Marcin Kawalerowicz
Abstract---
私たちは継続的バグ予測(Continuous Defect Prediction)研究のアイデアと私たちが作成したその研究に関連したデータセットを紹介しようと思う。私たちのデータセットは現在1100万行もあり、それらには継続的グレーション結果に私たちが持つソフトウェアリポジトリからマイニングしたデータを結合したビルド結果のファイルを含んでいる。私たちのデータセットには1265もの software projects を含み、それらには、30022 人もの commit authers や、以前からの研究で有効的であると判明したソフトウェアバグ予測の研究結果をもとにいくつかの software process metrix (ソフトウェア開発過程における基準)を採用したものが含まれている。この特定のデータセットの中で、継続的インテグレーションデータのソースとして TravisTorrent を使用した。TravisTorrent はTravis CI server と Github のオープンソースリポジトリから commit level information を提供してくれる。私たちはこのデータを file change level と software process metirix の計算ができるよう拡張した。この拡張により、例えば、もし継続的インテグレーションを有効にした repository に commit するとビルドを壊してしまいかねないような危険性の高い software change を予測するための性質、特徴として使用できる。
Introduction---
欠陥を起こしやすいモジュールやパッケージ、ファイルの定義付けは多くの研究者の興味をそそってきた。しかしながら、制限された資源やソフトウェア開発環境におけるタイトなスケジュールが研究者の興味をファイルやパッケージの定義付けから欠陥を起こす危険性の高いソフトウェアの変更の定義付けへと移行させる。私たちの長期間に及ぶ研究の目的は、欠陥を起こしやすいソフトウェアの変更(今のところは継続的インテグレーション結果を成功 / 失敗に制限している)を予測するために、機械学習(Machine leaning) ベースの予測モデルと大きなデータセット(オープンソースと、商業プロジェクトの両者から集めたもの)を用いたツールの支援によって Continuous Defect Prediction の実行(Practice) の提案することである。私たちは私たちの品質保証経験を継続的バグ予測の参考にしている。開発者たちは最新のコード変更が危険かどうか、また、もし 継続的インテグレーションを有効にしているリポジトリに commited/pushed/checked-in するとビルドを破壊してしまうかどうかを知らせるツールから継続的な feedback を受け取ることができるように。私たちは以前からのソフトウェア変更が問題ないかバグが存在しているかの分類という取り組み、仕事、研究(work)の上から(続きから？)ビルドをしている。←(このあたり曖昧なので詳しく訳していない)
しかし、すぐに知らせること(feedback)と、継続的に開発者に最も最新のコード変更がどれだけ危険性があるかfeedback することを心がけており、そして、このfeedbackのメカニズムをソフトウェア開発実践に埋め込んでいる。実はこのことは私たちの以前までの"Continuous Test-Driven Development" と”Agile Experimentation”の研究の延長である。これゆえ、私たちは今までの経験とこれまでの開発してきたツールの上でビルドを行っている。この論文では私たちは、欠陥を起こしやすいソフトウェア変更を定義するための、私たちの予測モデルを用いた大きなデータセットを共有する。
ビルドサーバ上での全てのビルドはたった1つまたは、1セットの commit (中央のリポジトリへの複数同時の commit and push)が引き金になりかねない。まず第一に私たちはそういった commit と、継続的インテグレーションのビルドに参加している全てのファイルの変更ごとに私たちが計算した測定項目のくくり(a set of metrics)を集めた。それらの測定項目(metrics)には、例えば、最後のビルドからの多数の修正コード数(a number of modified line(NML)) や、ビルドを commit した際のその日の現地時間(build commit local time of day(BCDTL)), そのビルドに含まれている多数の commiters (a number of distinct commiters(NDC)), 与えられたファイルに対する多数の訂正(改定?)(a number of revisions(NR)), ファイルがどこに含まれているかという最後のビルド結果の状態(last build status(LBS)),などが含まれている。私たちはそれらの測定項目を予測モデルをつくるための推測変数/独立変数などの特徴として使用した。
私たちは商業的な環境の中で実際にプロジェクトとして継続的バグ予測(CDP)に取り組んでいる。そこではビルドの成功/失敗の指標として、自社備え付けの Bitbucket から Jenkins CI build 結果を使用している。私たちはこの情報をGit repository から集めたデータと組み合わせている。しかし、秘密保持契約のため、私たちの含まれている商業プロジェクト以外の、多数のオープンソースプロジェクトから集めたデータのみを共有することができる。私たちは TravisTirrent のオープンデータベースプロジェクトの支援を受け集めたデータについて共有しようとおもう。TravisTorrent はTravis CI build server と GHTorrent から収集したデータを結合する。(GHTorrent--github のバージョン管理ホスティングサービスの API により供給されるオフラインのデータミラー)
TravisTorrent 上のデータは JRuby や Rails といった有名なオープンソースプロジェクトから集められている。TravisTorrent は commit はもっともきめ細かいデータの一部であり、commit level を蓄積している。順番に、私たちはファイル変更レベルに取り組んでいる。私たちにとって全ての CI build に参加している commit によるファイル変更は 重要な情報を私たちに知らせている。この情報を使用することで私たちは分類モデルをつくり、データをリポジトリにコミットする前に、build の出力結果を予測するために使用する。これに基づいて構築された予測モデルデータセットはこのデータペーパーの対象外である。
私たちは 30000 人以上の開発者が携わった 1265のGithub project の1100万行以上のデータを集めた。私たちは欠陥を起こしやすいソフトウェア変更予測や、ソフトウェア開発者の振る舞い、また、その他のソフトウェアエンジニアリング研究の分野に興味を持つ研究者の助けになることを願い、このデータを広く一般に利用できるようにした。
Data Collection and Storage---
私たちは以下に示す2つのソースからCDPに関連したデータを集めている。継続的インテグレーションプロセスと、バージョン管理システム(ソフトウェアリポジトリ)。継続的インテグレーションプロセスからのデータは CI server から集められている。CI server から提供される情報の中に、２つの興味深い情報があった。ビルド結果とそのビルド結果に含まれる commit または複数の commits のマークである。この情報は CI server の API を通して、または関連するデータベースをソースとしてなどで取得することができる。データベースを使用することは一時的なCI情報を処理することを助けている。関連するデータベースからのデータは、CIビルド情報の場合と同様に、通常はクリーニングされません。 最後のn個のビルド情報（例えば、ビルドの日時、その結果、ビルドログ）のみを保存して、CIサーバー上の記憶スペースに保存することが一般的である。
TravisTorrentデータベースを使用して、ビルド結果に関するデータを取得し、それらに含まれるビルドやコミット情報を取得します。 TravisTorrentは、オフラインミラー（GHTorrent）から取得したGitHubリポジトリデータと、APIを使用して取得した TravisCI server からの情報を合成します。 私たちは、travistorrent_11_1_2017テーブルへの問い合わせを、次のようにおこないます。
1) git trigger commit (hash of the commit which triggered the build),
2) gh project name (project name on GitHub),
3) gh pushed at (time of the push that triggered the build),
4) tr status (build result).
私たちは商業プロジェクトでのCDP研究で使用しているBitbucketデータベースに格納されたJenkins CIビルド結果にアクセスしています。 JenkinsとBitbucketはともに、銀行ソフトウェアを構築する会社に前もってインストールされています。 Jenkins CIとは別に、TeamCity CIサーバーAPIを使用してビルド結果を収集することも可能にしました。 私たちはGitのソース管理システムをサポートしていますが、このアプローチでは、この特定のシステムには何ら制限されません。 このアプローチをSubversion、Mercurial、その他のソース管理システムにまで拡張することが可能です。
選択されたCIサーバーによっては、ビルド結果の列挙が異なることに注意する必要があります。 表Iに示すように、成功、失敗、未知の3つの状態（例：ビルドが中断された場合、警告付きで終了した場合、またはCIサーバーによって不安定とマークされた場合）にマッピングします。
1つの特定のコミットまたは任意の数の異なるコミットに対して、CIサーバー上で1つのビルドを行うことができます。CIビルドに関わるコミットに関する情報は、CIサーバーAPIまたはデータベースから取得できます。 TravisTorrentデータベースに問い合わせて、私たちに必要な情報を取得します（前述のgit_trigger_commitカラムを使用）。
ビルドに関わる特定のコミットは、ソフトウェアリポジトリのブランチトポロジーツリーに基づいて計算されます。
次に、ソフトウェアリポジトリは、CDP用に収集された file level metrics のソースとして利用されます。これらの metrics は、予測モデルの項目です。その点で、データが収穫されたソフトウェアリポジトリのタイプ（Git、Subversion、Mercurialなど）は無関係です。現在、Gitリポジトリからデータを取得しています（具体的にはGitHub）。 TravisTorrentの場合のように、GitHub APIを使用しないことで、[10]で報告された帯域幅スロットリングに関する問題を回避しています。代わりに、すべてのGitHubリポジトリをローカルディスクに複製しています。データのソースとして、ローカルに格納されたコミット履歴を使用しています。結論から言うと、これはGitHubには何の問題もなく、必要な領域に関しても問題ではありません。私たちは、43GBを少し上回るディスク容量を占める1265のプロジェクトを複製しました。 Gitリポジトリ操作（クローン作成、コミット履歴の読み込み）を容易にするために、LibGit2Sharp1ライブラリを使用しています。
表IIは、ソフトウェアリポジトリから収集している metrics と、それらの取得方法に関する情報を示しています。 我々が使用しているソフトウェアプロセスメトリクスは、メディスキーとジュレチコ[11]が、いくつかのプロセスメトリック（NDCとNMLといいったもの）が製品メトリクスに基づいてソフトウェアの欠陥予測モデルを大幅に改善できることを発見したことからインスピレーションを受けています。 これらのメトリックと合わせて、データセットには以下も含まれます。
1) Project name
2) File path
3) Commit hash
4) Build commit hash
5) Export date (time stamp of the moment the data were collected)
データは、単純なMicrosoft SQL Serverデータベースに格納されます。メトリックを格納するデータベースの一部（表メトリック）を表IIIに示します。 データベースにある欠陥予測要求および分類モデルのためのテーブルの残りの部分は、このペーパーの範囲外のため提示しない。
Description of Dataset---
この記事の執筆時点では、メトリックデータベーステーブルに11,464,816行（CIビルドを行ったファイルをはじめとする）を含むデータセットを収集しました。 metrics は、TravisTorrentデータベースに集められた1265件のプロジェクトで収集されました。 異なるプロジェクトの行数(取得したデータセットのもの)は大幅に異なります（最小値は1、最大値は2706617、第1四分位数は405、第3四分位値は2876、中央値は938、平均値は9063）。 図1は、プロジェクトの行数のヒストグラムを対数スケールでプロットしたものです。 私たちのデータベースには30,022人の異なるコミット者がいます。 興味深いことに、私たちのデータベースには少数のデータ行しか持たない多数のプロジェクトがあります。たとえば、データレコードが1000件未満の657件のプロジェクトがあります（図1の1e + 03マーク）。 これらのプロジェクトのすべてのコミットが1000未満のファイルを変更したことを意味します。
私たちは、データベース内の最大の10個のプロジェクト（最も行が多いもの）と無作為に選ばれた10個のデータベース（以下のSQLコマンドを使用して。)
select top 10 ... order by newid（）
行数がデータベースの平均よりも大きいプロジェクト。
図2には選択したプロジェクトの名前が、表4にはこれらのプロジェクトのメトリックの要約データが示されています。
私たちのCDP研究では、オープンソースリポジトリとクローズドソースレポジトリの両方で作業しています。 ここでは、商業/非公開ソースソフトウェアプロジェクトなどの他の環境(context)には一般化できない脅威をもたらすデータセットを除いたオープンソースベースの部分のみを共有します。 我々が構築したTravisTorrentデータセットは、TRAVIS CI使用の履歴(50ビルドより大きいもの)を持つRubyやJavaの非フォーク、非おもちゃ、いくらか有名な（GITHUB上の10人より大勢のウォッチャーの存在）などをプロジェクトにフィルタリング基準を設けてプロジェクト空間を制限したことにも言及する価値があります。
この論文の目的は、私たちが共有したデータセットを簡単に説明することです。しかし、研究者としての私たちの役割は、一般にこのデータペーパーの範囲を超えていても、データを収集するだけでなく、それらを理解に変換することです。興味深い洞察やアイデアの例として、提供されたデータセットで今後の研究の質問に答えることができるようにするため、10の大きな大規模プロジェクトと10のランダムに選択されたプロジェクトのビルドコミット時間のボックスプロットを示します。これらの小さなサンプルがある程度代表的であると仮定すると、このプロットから2つの興味深い仮説を立てることができます。図2と表4から得られた最初のものは、大規模なプロジェクトの場合、CIビルドをトリガするコミットは昼間の後半で行われますが、それは平均ではより早く行われます。 2つ目は、オープンソースプロジェクトの統合(integration)は一般的に午後8時より前に行われるため、平均的なオープンソース開発者は、通常思われているようなナイトフクロウではないということです。実際には、ビルドは通常のbusiness時間内（午前9時から午後5時）に行われたコミットに基づいて行われます。
Future Work and Conclusions---
この論文で紹介したデータセットを使用して、成功/失敗継続的な統合の継続的な予測のための予測モデルを作成しています。 私たちは現在、この論文の著者の一人が管理する企業の商用ソフトウェア開発環境で指導者(pilot)としてCDPプロジェクトに取り組んでいますが、CDPプロジェクト全体をデュアルオープンソースと商用ライセンスを使用してデータを収集するためのツールとともにリリースします。我々は、収集したデータセットを、他の研究者による既存の研究結果をもとに、我々の予測モデルの特徴として使用することができる、より多くの metrics で豊かにするつもりである。 クラウドプロバイダーの協力を得て、オープンソースプロジェクトの開発を支援するために、Web上で予測モデルをすぐに利用できるように公開することも可能です。
データベースを公開することで、プロジェクトへの聴衆やフィードバックを引き付けるとともに、新しいメトリクスや新しい種類のメトリックによってデータセットを強化し、より多くのデータセットからのデータセットに基づいて予測モデルを構築する 1000人のソフトウェアプロジェクト、さらには独自の開発者、または実務者に有用な他の従属変数を予測することができます。 当社のデータが将来の研究に役立つ可能性がある分野には、ソフトウェア変更レベルの欠陥予測、長年にわたるソフトウェアプロジェクトの安定性と成熟度調査、開発者の活動と結果の調査、または一定期間にわたる継続的な統合の傾向の調査が含まれます。
このデータベースは、figshare2とMicrosoft SQL Server 2012ダンプファイルのCSVファイルとして利用できます。
Acknowladgment---
TravisTorrent [7]の著者たちに感謝したいと思います。TravisTorrent [7]は、私たちが目的に使用できるように拡張できる一連のデータを提供しました。 CODEFUSION社の従業員に貴重な情報とツール開発の助けをしてくれたことに感謝したいと思います。
