3月7日から9日にかけて、グローバルOpenStack Bug Smash Mitakaが開催されました。 ミランティスはこのイベントのために2つの会場を主催しました。そのうちの1つは会社のモスクワ事務所にありました。 ロシアが初めてBugSmashに参加しました。 そして、これが私たちの直接参加で起こったことを嬉しく思います。
Intel、Rackspace、Mirantis、IBM、HPE、Huawei、CESI、SUSEなどの大規模市場のプレーヤーがコードの品質を確認および改善する作業をサポートするのは、コミュニティにとってなぜそれほど重要なのですか？ このイベントは、OpenStackプラットフォームの作成プロセスでどのような場所を占めますか？
機能開発と修正のバグは、2つの異なるプロセスですが、相互接続性が高くなっています。 このような声明は、どのソフトウェア製品にも当てはまります。 しかし、オープンコードの場合、ニュアンスがあります。何か新しいものを作成できる人は誰でも、他の誰かのコードを見て修正するよりも、それを行う方を好むでしょう。
文学、音楽、または視覚芸術においてさえ、作品を作成する人とそれらを分析する人がいます（すべてのストライプの批評家）。 しかし、作家、作曲家、アーティストの生産性が常に批評家の精査の恩恵を受けるとは限らない場合、ソフトウェア製品は常に改善され、新鮮な外観で見るとよりクリーンで安定したものになります。 OpenStack開発プロセスの本質は、それがオープンに行われ、すべての変更が常に複数の人によってチェックされることです。
さらに、各リリースサイクルには、新しい機能の開発を妨げる技術的な義務があります。 Mirantisの内部キッチンの簡単な例：MOS 7.0のリリース前のマスターノードは、CentOSの古いバージョンに基づいていました。 これにより、製品の改善プロセスが遅くなり、いくつかの興味深い機能を実装する機会が与えられませんでした。 しかし、MOS 8.0のリリースでは、マスターノードを更新することでこの技術的負債を精力的に支払い、開発者がライブラリとユーザーの最新バージョンを使用して更新を時間通りに受信できるようにしました。
ただし、リリースからリリースにかけて技術的な負債が蓄積することを経験が示しています。 そして、開発者は、新しい機能の作成と借金の部分的な清算の間で時間を分けることを余儀なくされています。 そのため、製品管理からのプレッシャーは常に、販売済みの古い退屈なバグの修正ではなく、販売可能な新しいクールな機能の開発に向けられているため、「ノミを捕まえる」ために時間は残りの原則に従って割り当てられます。
重大なバグが最初に除去されます。 これらはそのようなバグであり、機能がまったく機能しない場合です。 実質的なエラー（大きなバグ）が発生します。 このようなバグが存在する場合、この機能は機能しますが、本来の機能ではなく、「松葉杖を使用して」-このエラーの存在を補う大幅な改善が行われます。 たとえば、ユーザーはサービスを再起動して、正常に機能し続ける必要があります。
「高い」以下のバグは、常に新しいリリースの厳しいスケジュールの範囲内にいる開発者の注意を引くことはほとんどありませんが、以前のリリースでは重大で重大なバグを修正します。 そのため、優先度の低いバグは何年もハングアップし、リリースからリリースへと移行する可能性があります。 彼らはぶら下がっています。 そして、リリースからリリースへと移行しました。 問題は、中程度のバグはユーザビリティに関連していることであり、多くの場合、ユーザー自身によって引き起こされます。 それらの存在は、生態系プロジェクト（顧客体験）で働く印象を台無しにすると言うことができます。 4年間の履歴を持つこのようなバグの例を次に示します （ dhcpサーバーは、未設定の場合、フィルタリングのためにデフォルトでゲートウェイになります ）。 ここに、より「若い」バグがあります-それはわずか2年前です（ サーバーグループの作成時にメタデータを有効にします ）。 両方のバグはNovaプロジェクトに関連しています（プロジェクトの正式名称はOpenStack Computeです）。 全体として、この生態系にとって非常に重要なプロジェクトでは、さまざまな「重大度」の483個のバグ （執筆時点）です。 したがって、すべての希望は、リリースサイクルでバグを探すために開発者が作業を延期することです。 そして、コードはよりクリーンになります。
品質管理（QA）のプロセスにおけるBug Smashの場所を決定します。 QAはテストのみであるという意見があります。 ただし、経験豊富な開発者（ Ciscoなどのプロプライエタリ製品会社に勤務する開発者を含む）は、テストがQAの一部にすぎないことを知っています。 他の開発者がコードの品質をチェックする段階で、多数のバグを検出できます（コードレビュー）。 通常、コードレビューはテストの前に行われます。 そのため、レビュープロセスで見つかったエラーの価格は低くなります。
問題が早く発見されると、それを修正するのが安くなることは広く知られています。 たとえば、 McConnellの著書「Perfect Code」に記載されているデータによると、テスト段階での間違いの修正には、コード開発段階の10倍の費用がかかります。 テストは労働集約的な手順であるため、安価ではありません。 適切な特性を備えたラボを立ち上げ、テストスクリプトを作成し、テストを実施し、テストプロセス中に特定された問題を排除する必要があります。
最も高価な間違いは、ユーザーが見つけたものです。 レビュアーが見落としたもので、テスターは捕まえませんでした。 この場合、修正チェーンはサポートから始まります。 サポートサービスのスペシャリストは、クライアントのリクエストを受け取り、問題を診断します。そのために、テスト手順を繰り返す可能性があります。つまり、ラボを終了します-以下（上記を参照）。
チームにOpenStackコミュニティの人々がいる最も上級のユーザーは、バグを検出し、コミュニティにバグについて通知します。 ただし、これらのバグは重大でも重大でもないため、開発者がバグを操作する機会はほとんどありません。 円は閉じています。
したがって、OpenStackの各リリースサイクル内で行われるマラソンであるOpenStack Bug Smashの重要性を過大評価することは困難であり、開発者は通常、視野外に残るバグを処理する時間を割り当てることができます。
誰もがこの恩恵を受けます。そして、最終的に問題の解決策を受け取ったユーザー。 また、貢献企業は、コードのエラーを早期に検出して修正することで費用を節約します。 そして、顧客満足度のレベルが高まるにつれて、エコシステム全体、つまり、OpenStackに基づくソリューションの作成と実装に基づいて構築された、ビジネス成長の新しい機会があることを意味します。
さて、このイベントのもう1つの重要な結果は、新しい貢献者を引き付けることと、世界中のOpenStackに関する知識の一般的な普及です。 ニューヨークでは、同様のイベントで、彼らはOpenStackの操作方法を学ぶために来た新人のトレーニングに1日目を費やし、2日目にだけバグの修正を始めました。 モスクワでは、OpenStackに没頭し始めたばかりの人々と仕事をするために1日もかかりました。 幸運と安定したコード！
