Webkit、Linuxカーネルなどのプロジェクトは、フルビルドに数時間ではなくても10分以上かかります。これらの大規模プロジェクトの実際的な開発サイクルは何ですか?具体的には、開発者は特定されたバグをどのように修正してテストしますか?具体的な例を挙げていただけますか?
Webkit、Linuxカーネルなどのプロジェクトは、フルビルドに数時間ではなくても10分以上かかります。
10分または30分は、禁止されているビルド時間ではありません。
私がキャリアを始めたとき(1987年、Unix上のSun3/160ワークステーション)、自分で書いた200KLOCプログラムの完全な(コールド)ビルドは30分以上かかりました。
incremental builds (並列ビルドと組み合わせると、おそらく make -j
、または distcc 、 icecream のような並列および分散ビルド、さらに高速(マルチコア)デスクトップ、Linuxカーネル( 25MLOCのみ)ビルドは通常10分未満です(ほとんどの増分ビルドは1分未満で済みます。そのため、新しいカーネルの再起動には再構築よりも時間がかかる場合があります)。それは大丈夫です。 this ベンチマークを参照してください(強力なデスクトップでLinuxカーネルを15分未満でコールドビルドできることを示しています)
そして1970年代には、プログラマー(パンチされたカードで2KLOC未満のプログラムをコーディングする人)は、1日あたり1回または2〜3回のコンパイルしかできなかった。彼らは自分のコードをもっと注意深く考えただけです。彼らの態度は異なっていました(そのようなことを考えていません:私はそのための構文を忘れており、コンパイルするだけです)。
いい加減に聞こえます(しかし、私は1959年に生まれました)が、ビルドを10分(または30分でも)待つことができない場合、あなたは甘やかされて育った子供です。でも最近は甘やかされてます….
もちろん、ソフトウェアの構築と設計については、賢く考える必要があります。
いくつかのプロプライエタリ製品(Googleインデックスエンジンのようなもの)は、C++コードが5億億行以上あると噂されています(Cよりもはるかに低速で、単一の実行可能ファイルに組み込まれます)。その場合、リンク時間が問題になります。しかし、Googleは gold を設計および開発するためにIan Lance Taylorに資金を提供しました(正確にそれを加速するために)。そして、Googleは独自の ビルドオートメーション エンジンを開発し、そのためにハイエンドサーバーを使用しています。
現在のHPCコード(銀河の衝突のシミュレーションなど)には、今日数週間のCPU時間が必要です。バグが発生するのに丸一日かかる必要がある場合(そして数値的なバグである場合)、それらをデバッグすることはおそらくより困難です。ただし、コードは設計が異なります(たとえば、コード設計時に永続性について考えます)。
場合によっては、再現可能なバグに到達するのに30分CPU時間かかることがあります(これは、わずか2000行の小さな個人プロジェクトでも発生する可能性があります)。事情は異なりますが、既存のプログラムに persistence または checkpointing を追加することは、一般に非常に大きなアーキテクチャの変更であり、手に入れることができません)。
また、 modularity が広く使用されるようになりました(C++ 20でもモジュールがある場合があります)。最近のほとんどのプログラミング環境には libraries の概念があります。多くのソフトウェアプロジェクトでは PIMPLイディオム を使用しています。そして最近のプログラミング言語(Go、Rust、Ocaml)はモジュールについて知っています。また、巨大なソフトウェアシステムは、特に プロセスの分離 (これを定義する必要がある)を利用したいため、いくつかの実行可能ファイルに分散および分割される傾向があります(例 microservice アプローチ)。インターフェイスをより注意深くプログラムします)。
ついに、ソフトウェアの総量は、それが管理するデータよりもはるかに少なくなっています(手がかりについては sofwareheritage を調べてください。地球上のソースコードの合計サイズの推定は、おそらく数百テラバイトです。 、インターネット上のデータの総量よりも数桁少ない=多数 エクサバイト 、おそらく少数 ゼッタバイト )。 Linuxディストリビューション全体(約20GLOCのコード)でも、デスクトップ上で1週間未満でビルドできます。いくつかのソースコードを試してください Linuxディストリビューション (例 gentoo )。
いくつかの大規模なフリーソフトウェアプロジェクト(例:Qt、GTK、GCC、Libreoffice、Firefox、Linuxまたは* BSDカーネル、Java JRE、...)詳細はさまざまです(これらのソフトウェアのアーキテクチャと設計、プログラミング言語とビルド自動化ツールが異なるため)。
2018年とほとんどの先進国では、熟練労働者(有能な開発者)のコストが、ソフトウェアを構築するためのコンピューターのコストよりもはるかに高いことに注意してください。したがって、開発者に強力なビルドシステムを提供することは理にかなっています。
フルビルドに非常に長い時間がかかり、変更のたびにシステムをテストできない場合は、次の3つの方法があります。
実際のプロジェクトは、これら3つのいずれか(またはそれらの任意の組み合わせ)を実行します。
これらの大規模プロジェクトの実際的な開発サイクルは何ですか?
具体的には、開発者は特定されたバグをどのように修正してテストしますか?
前述のように、CIシステムから短時間の応答が得られるはずです。
もちろん、それらはすべての種類のコンパイラエラーとユニットテストケースの結果であり、開発環境を修正するか、デバッガを起動してユニットテストを再度グリーン化して、正確にどこを調査するかを示します。
具体的な例を挙げていただけますか?
もちろん可能ですが、このようなバグを修正する方法の例は非常に広範囲に及ぶ可能性があるため、ここでは少し無駄です。
理由は、ビルドサーバーによって検出された誤検知の失敗から、ソースコードに露骨にハードコードされた値までさまざまです。
大規模なプロジェクトでより多くの開発者グループを管理する上での主なポイントは、そのような失敗についてできるだけ早く通知する必要があるということです。
1)ただし、CIシステムから通知されるまで職場を使用不可にしないでください緑。
非常に効果的なアプローチは、コミット前の検証のために複数の候補チェンジセットをバンドルできるゲートCIシステムを使用することです。
開発者は、独自の環境/ワークスペースの増分ビルドで使用して、チェンジセットの準備をスピードアップできます。しかし、彼らはそれらを統合ブランチに直接コミットしません-彼らの私的な検証は十分に信頼できません。代わりに、最終検証のためにそれらをゲーティングCIシステムに送信し、(自動化!)統合ブランチにコミット/マージします。
(肯定的な私見)副作用としてそのようなプロセスは次のことができます:
私が以前の雇用主のために設計したそのようなCIシステムの1つは、メインブランチでトランクベースの開発を行う1000人を超える開発者にきちんとサービスを提供しており、4〜6時間のビルドと5〜12時間の煙テストを含むコミットゲーティング基準を、1日あたり平均60〜80コミットで実行していました。割合。
別の例は、 Zuul / Gerrit に基づく OpenStack のCIゲーティングシステムです。それに関するいくつかのプレゼンテーション: