2

背景：假设您有两台服务器充当 C/C++ 代码的构建服务器（如果重要，则为 Jenkins）。两台服务器都使用相同的启动、操作系统版本、库等构建。代码在 Git 中的两个分支上维护 - 开发和发布候选。Development 中的代码是权威的，并提升到 RC。Git 哈希匹配。建立在开发基础设施上的代码会生成功能正常的二进制文件。在 RC 基础设施上生成的代码没有（或者至少在测试中，似乎没有在 Dev 上看到的错误）。您将如何证明 Dev 的构建和 RC 的构建是相同的。你会使用什么工具？你会检查什么？您将捕获哪些指标？其他软件公司是怎么做的？这不是一个理论练习——我被迫证明这一点。已阅读验证两种不同的构建架构（一种是对另一种的重写）在功能上是等效的。操作系统是 RHEL 6.2。

4

2 回答 2

1

由于它们是两个不同的版本，可能具有不同的编译器选项和定义，因此它们不太可能相同。

但是，第 1 步是更改 RC 构建配置以匹配开发配置。如果生成的二进制文件不同，则可能会提供一些关于构建环境差异的见解。大多数人称这种配置为“Beta”。

第 2 步是创建一个中间构建，它具有 Dev 构建配置但 RC 定义。确认二进制文件不同 - 可能有一些 #ifdef'd 代码在 RC 下表现不同。

这个想法是去两台机器上做相当于：

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 回答