Build 发布版本与夜间版本

典型的解决方案是在构建服务器上运行一个CI（持续集成）构建：它将分析源代码，进行构建（调试）并运行测试，测量测试覆盖率，等等

现在，另一种构建类型通常被称为“夜间构建”：做一些缓慢的事情，比如创建代码文档、制作安装包、部署到测试环境、针对测试环境运行自动（冒烟或验收）测试等等

现在，问题是：

• 有第三个单独的“发布版本”作为发布版本更好吗
• 还是在发布模式下“夜间构建”并将其用作发布

你在公司里用什么

---

（发布版本还应该为潜在产品版本的源代码控制添加某种标签。）

多年来，我通过多种方式实现了这一点。第一个问题是，只有在调试版本的“健全性测试”通过时，发布版本才会发生。它还将自动部署到我们的预生产环境中，用于用户驱动的验证

我也看到过这样的情况，发布版本几乎被视为神圣的，只有在“准备好真正部署”的时候，才进行发布。随之而来的是一些“文书工作”和批准，然后发布构建（手动）完成，然后进行健全性检查，然后部署

---

根据我的经验，只要你始终如一，并且按照公司/团队理解的方式工作，这并不重要。一开始违背规则很容易，但后来导致了一个客户的情况，他们实际上放弃了一种结构化的构建/部署方法（想象一下，一家价值1亿美元的公司这样做了，但他们做到了）。

通常我这样做的方式是将我的夜间构建升级为发布构建。您通常不希望创建单独的发布版本。大多数QA团队应该每晚测试构建（希望他们不是从您的CI构建进行测试）。一旦他们认为它可以发布，你就把它提升到发布状态。你决定这意味着什么。将其移动到其他位置、重命名、标记、标记、刻录等

---

你不想让QA每夜测试一次，然后当他们认为不错的时候，再做一次，你说是一样的。你永远不知道，他们可能会不同。操作系统补丁可能已经应用到您的构建机器上，第三方工具可能已经更新，等等。您不想让QA团队两次工作来测试“相同的精确构建”。它可能来自同一个来源，但不能保证它是相同的确切版本。

您的问题的答案在很大程度上取决于您正在进行的项目和您想要设定的目标

一般来说，（对于小项目来说，这一点非常正确）构建应该非常快，并且应该包括部署所需的一切。这对我来说永远是目标，即使我没有达到它-至少不是一次。这让我一直在寻找可以改进的地方

我从从事大型遗留项目的工作中了解到，有太多的累积问题拖慢了进度，这可能是不可行的。至少不是直接的目标。在大型遗留项目中，编译和链接通常需要很长时间，测试（如果存在）也可能运行得太长，生成部署所需的所有信息也可能很慢，甚至是手动的。此外，构建硬件可能不足。在这个不完整的列表中还有许多其他的东西需要添加

在处理这样的项目时，我尝试让单独的周期做事情

第一个周期，一个可靠的CI服务器，用于构建、运行自动单元测试、打包和归档构建。此必须快速，以便就所做的更改向开发人员提供快速反馈。如果这是缓慢的，得到更好的硬件建设，整理依赖关系和修复缓慢的单元测试等。你希望这是尽可能快。构建都是可部署的构建

第二个周期将是一个较慢的周期，仅拾取CI系统生成的版本。它不使用源代码作为输入，而是发布版本。这些将根据您的需要（生成的每个构建）拾取，或者在准备执行另一个周期时获取最新版本。这个较长的周期将包括将构建部署到测试服务器上、运行自动功能测试以及执行其他“太慢”、“还不快”或其他需要花费很长时间的事情。根据您的组织，您现在可以添加到可部署包（文档等），根据客户端可见的内容或类似的内容重命名版本。经过这里的建筑可以很好地投入使用

如果还需要运行性能测试，则可能需要第三个周期，该周期将第二个周期的构建作为输入

这是一个简单的描述，但这里的要点是将事物分开，这样你可以在链中拥有所有的东西，同时比一个周期更快地获得反馈。我发现这是一个很好的方法，因为它有可能获得速度（反馈）的好处，同时也是一个自然的做事场所

---

最后，我想提到的是，实现这一点的方法也会因项目而异，特别是如果您改装CI。您甚至可能希望有一个单独的连续构建，只包含构建和单元测试，并且每天有一个（或其他什么）构建，用于发布和测试。这当然意味着只有开发使用快速CI构建，因为它们不完整，不适合部署。但从长远来看，这并不是你想要的你想让整个链条自动化

编辑：也许这个问题的更好论坛是：