build - 发布构建与夜间构建

Question

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

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

现在，问题：

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

你在公司里用什么？

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

Answer 1

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

您不想每晚进行 QA 测试，然后当他们认为这很好时，再构建一个，您说的也是一样的。你永远不知道，它们可能是不同的。操作系统补丁可能已应用于您的构建机器，第三方工具可能已更新等。您不想让您的 QA 团队工作两次来测试“完全相同的构建”。它可能来自同一来源，但不能保证它是完全相同的版本。

Answer 2

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

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

我从从事大型遗留项目的工作中知道，有很多累积的问题会减慢速度，以至于它可能不可行。至少至少不是直接目标。在大型遗留项目中，编译和链接通常需要很长时间，测试（如果存在）也可能运行时间过长，并且生成部署所需的所有信息也可能很慢，甚至是手动的。此外，构建硬件可能还不够。在这个不完整的列表中还有许多其他内容要添加。

在从事这样的项目时，我尝试让单独的周期来做事。

第一个周期，一个可靠的CI 服务器，它构建、运行自动化单元测试、打包和归档构建。这必须很快，以便对所做更改的开发提供快速反馈。如果这很慢，请使用更好的硬件来构建，理清依赖关系并修复缓慢的单元测试等。您希望它尽可能快。这些构建都是可部署的构建。

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

如果您还需要运行性能测试，您可能需要第三个循环，它与第二个循环的构建一起作为输入。

对此进行了简要描述，但这里的重点是将事物分开，这样您就可以拥有链中的所有内容，同时比一个循环更快地获得反馈。我发现这是一个很好的方法，因为它可以获得速度（反馈）的好处以及做事的自然场所。

最后，我想提一下，解决这个问题的方法也会因项目而异，尤其是在你改造 CI 的情况下。您甚至可能希望有一个单独的持续构建，只包含构建和单元测试，并且每天（或其他）构建一个用于发布和测试的构建。这当然意味着只有开发使用快速 CI 构建，因为它们不完整且不适合部署。尽管如此，从长远来看，这不是你想要的。你想让整个链条自动化。

Answer 3

多年来，我已经通过多种方式做到了这一点。第一个是如果并且仅当调试版本的“健全性测试”通过时，发布版本才会发生。它还将自动部署到我们的预生产环境以进行用户驱动的验证。

我也看到过这样的做法，其中发布版本几乎被视为神圣，并且只有在被认为是“准备真正部署的时候”时才会制作它们。随之而来的是一些“文书工作”和批准，然后（手动）制作发布版本，然后对其进行健全性检查，然后进行部署。

根据我的经验，只要你保持一致并且它与公司/团队理解它应该工作的方式一起工作，这并不重要。一开始很容易违背规律，但随后导致一个客户发生了什么事，他们实际上完全放弃了结构化的构建/部署方法（一家价值 1 亿美元的公司这样做了，想象一下，但他们确实做到了）。