2

背景: C/C++ コード用のビルド サーバー (重要な場合は Jenkins) として機能する 2 つのサーバーがあるとします。両方のサーバーは、同一のキックスタート、OS バージョン、ライブラリなどで構築されています。コードは、開発とリリース候補の 2 つのブランチで Git に保持されています。開発中のコードは権限があり、RC に昇格されています。Git ハッシュが一致します。開発インフラストラクチャ上に構築されたコードは、機能するバイナリを生成します。RC インフラストラクチャで生成されたコードはそうではありません (または、少なくともテストでは、Dev では見られないバグがあるようです)。Dev のビルドと RC のビルドが同一であることをどのように証明しますか。どのようなツールを使用しますか? 何をチェックしますか？どの指標を取得しますか? 他のソフトウェア会社はどのようにこれを行っていますか? これは理論的な演習ではありません - 私はこれを証明することを余儀なくされています. 読んだ2 つの異なるビルド アーキテクチャ (一方は他方を書き換えたもの) が機能的に同等であることを確認します。OSはRHEL6.2です。

4

2 に答える 2

1

これらは 2 つの異なるビルドであり、おそらくコンパイラ オプションと定義が異なるため、同じである可能性はほとんどありません。

ただし、ステップ 1 では、RC ビルド構成を変更して開発構成と一致させます。結果のバイナリが同じでない場合は、ビルド環境の違いに関する洞察が得られる場合があります。ほとんどの人は、この構成を「ベータ」と呼んでいます。

ステップ 2 は、Dev ビルド構成を持つが RC が定義する中間ビルドを作成することです。バイナリが異なることを確認してください - RC の下で異なる動作をする #ifdef されたコードがある可能性があります。

アイデアは、両方のマシンに移動して、次と同等のことを行うことです。

cd $BUILD
mkdir dev-bin beta-bin prerc-bin
make dev && mv $BINARIES dev-bin
make beta && mv $BINARIES beta-bin
make prerc && mv $BINARIES prerc-bin

差分と利益。ビルド ボックス全体で繰り返すことができます。

ステージごとに別々のビルド環境を用意している理由がわかりません。それは定期的に失敗することが保証されているようです。

私の最も成功した経験は、常に、特定のビルド ディレクトリで特定のビルドをその範囲の反復にわたって開発することです。

  1. ソース管理から作業コピーを作成し、
  2. ビルド開発 -> テスト、
  3. 修正された場合: 適用し、手順 2 に進みます。
  4. RC のビルド -> テスト、
  5. 修正された場合: 適用し、手順 2 に進みます。
  6. ビルド関係

明らかに、これはある程度手動のワークフロー制御によってバックアップする必要があるため、新しい機能が頻繁に追加されてステップ 2 にリセットされないようにする必要があります (なに? その男は午前 5 時まで働いていました。もちろん、彼はそれを運用ブランチにチェックインしました)。テストせずに）

于 2013-10-28T15:42:47.167 に答える
0

異なるプリプロセッサ ディレクティブと異なるコンパイル オプションがある場合、ほとんどの場合、それらは同一ではありません。
異なる環境自体が、異なる動作に寄与する別の要因である可能性があります。

申し訳ありませんが、これとは異なる動作が見られる場合は、おそらくバグがあり、解決する必要があります。

誰かが、バグがあるとは思わないという理由だけで同一であることを証明するように言っている場合は、間違っていると伝えてください。事実はそうではありません。

于 2013-10-28T15:29:41.380 に答える