当前情况： 我们有一个用C++编写的应用程序，用cmake构建，使用googletest进行单元测试。C++应用程序在不同环境下自动构建
我们有两种环境：
我们测试本地计算机上，当我们发布时，我们在生产机器上签出代码，构建它并运行。
现在公司正在用自动化构建工具（如Jenkins）来推广CI。 尽管我们可以自动化构建过程，但有些人建议不建议直接在生产机器上构建。
但在我看来，不像Java程序可以运行，只要有JRE，C++应用程序就非常依赖于机器。
大多数情况下，Docker可能是银色的子弹，但不幸的是，我们的应用程序无法放入docker中，因为它需要在一组真正的机器上运行。
行业中是否存在处理这类问题的一般/常用方式？
你可以使用相同的类服务器作为Production的CI系统，但不与Production服务器干扰添加Staging（你的愿望或Pre-production或任何名称）的环境。
一旦您对Staging结果感到满意，您就可以安全地在Production上进行部署。
运行CI系统本身可能会干扰同一服务器上测试的观点仍然适用于Staging环境（我不确定是否正确理解这是关注的一部分）。唯一的解决办法就是专门用于CI系统操作的CI环境（运行CI基础设施，建筑物等）。此CI环境中的服务器级别仅对CI系统性能很重要。 CI系统应能够处理不受CI操作影响的远程环境（如Staging或Production）的测试验证。
我不想猜测为什么你的应用程序有硬件/服务器的真正需求，但我的第一个赌注是泊坞窗，而且很棒。我们做了类似的工作，并与github，竹子，藏匿处和码头工作者很好地结合在一起。最好的部分是可扩展性和依赖关系很好地包含并迅速识别构建破坏。
我在过去看到过的另一种方法是，您拥有各种搭建公用文件服务器的构建机器/服务器，并且每当在git中发生推送时，就会调用一个本地服务来选择CPU负载最低的服务器，在该机器上构建代码（尽管代码位于通用文件服务器中）
恕我直言只要图像相同，应用程序就会表现相同。所以我会设置一个具有相同映像的本地虚拟机，并首先对其进行测试和/或创建另一个亚马逊实例（不是很强大），并在那里测试并构建它，然后将二进制文件移动到生产系统。直接在生产环境中构建可能会破坏服务，并可能使用大量资源。 – knightrider