后台：假设您有两台服务器充当C / C ++代码的构建服务器（如果重要的话，则为Jenkins）。两个服务器都使用相同的kickstart，OS版本，库等构建。代码在Git上的两个分支上保存 - 开发和候选发布。开发中的代码是权威的，并提升为RC。 Git哈希匹配。构建在dev基础结构上的代码可生成功能二进制在RC基础设施上生成的代码没有（或至少在测试中，似乎在Dev上没有见到的错误）。您将如何证明Dev的构建和RC的构建是相同的。你会用什么工具？你会检查什么？您会捕获哪些指标？其他软件公司如何做？这不是理论上的练习 - 我被迫证明了这一点。已阅读Verifying two different build architectures (one a re-write of the other) are functionally equivalent。操作系统是RHEL 6.2。
答案 0 :(得分：1)
由于它们是两个不同的版本，可能具有不同的编译器选项和定义，因此它们不太可能相同。
但是，第1步是更改RC构建配置以匹配dev配置。如果生成的二进制文件不相同，则可以提供有关构建环境差异的一些见解。大多数人将此配置称为“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
Diff和proffit。您可以在构建框中重复。
我很困惑为什么你为每个阶段都有一个单独的构建环境。这似乎保证会定期让你失望。
我最成功的经验一直是在给定的构建目录中开发特定的构建范围。
显然，这必须通过一定程度的手动工作流程控制来支持，以便新功能不会继续下降并将您重置为第2步（什么？这个人工作到凌晨5点，当然他已经检查过了没有测试的生产部门）
答案 1 :(得分：0)
如果存在不同的预处理器指令和不同的编译选项，则很可能它们不相同 不同的环境本身可能是导致不同行为的另一个因素。
如果您发现不同的行为，我很遗憾地告诉您，可能存在错误，您需要解决它。
如果有人告诉你只是因为他们不相信有错误而证明他们是完全相同的，那就告诉他们他们错了，事实证明不然。