典型的解决方案是在构建服务器上运行CI（持续集成）构建：它将分析源代码，进行构建（在调试中）并运行测试，测量测试覆盖率等。
现在，通常已知的另一种构建类型是“Nightly build”：执行缓慢的操作，例如创建代码文档，制作安装程序包，部署到测试环境，以及针对测试环境运行自动（冒烟或验收）测试等。
现在，问题是：
贵公司有什么用途？
（发布版本还应该为潜在产品版本的源代码控制添加某种标记。）
答案 0 :(得分：4)
通常我这样做的方式是我的夜间构建升级到发布版本。您通常不希望创建单独的发布版本。大多数QA团队应该测试夜间构建（希望它们不是从您的CI构建测试）。一旦他们认为它足以发布，您就可以将其推广到发布状态。你确定这意味着什么。将其移动到另一个位置，重命名，标记，标记，刻录等。
你不想每晚都进行QA测试，然后当他们认为它很好时，建立另一个，你说的是相同的。你永远不会知道，他们可能是不同的。操作系统补丁可能已应用于您的构建计算机，第三方工具可能已更新等。您不希望让您的QA团队工作两次来测试“相同的精确构建”。它可能来自同一个来源，但不能保证它是完全相同的构建。
答案 1 :(得分：2)
问题的答案在很大程度上取决于您正在处理的项目以及您要设置的目标。
一般来说，（对于小型项目来说非常正确），构建应该非常快，并且应该包括部署所需的一切。即使我没有达到这个目标，这对我来说也是我的目标 - 至少不是一次性的。它只是让我看着可以随时改进的东西。
我从大型遗留项目开始知道，有太多积累的问题导致事情变慢，这可能不太可行。至少不至少是一个直接的目标。在大型遗留项目中，编译和链接通常需要很长时间，测试（如果存在）也可能运行太长时间并且生成部署所需的所有信息也可能很慢甚至是手动的。另外，构建硬件可能还不够。还有许多其他内容要添加到这个不完整的列表中。
在处理这样的项目时，我尝试单独循环做事。
第一周期，一个可靠的 CI服务器，可构建，运行自动化单元测试，打包和存档构建。对于所做的更改，必须快速提供快速反馈。如果这很慢，可以获得更好的硬件来构建，整理依赖关系并修复慢速单元测试等。您希望尽可能快。构建都是可部署的构建。
第二周期将是较慢的周期，只能获取由CI系统构建的构建。它不能与源代码一起使用作为输入，而是发布版本。这些都可以根据您的需要（每个构建产生）或最新的准备好进行另一个循环。这个更长的周期包括将构建部署到测试服务器上，运行自动功能测试以及执行“太慢”，“还不快”或其他您需要的其他需要很长时间的事情。根据您的组织，您现在可以添加到可部署包（文档等），根据客户端或类似内容可见的内容重命名该版本。通过这里建设可以很好的生活。
如果您还要运行性能测试，则可能需要第三个周期，这可以将第二个周期的构建作为输入。
这是简要描述的，但主要观点是分开的东西，因此您可以拥有链中的所有内容，同时获得比一个周期更快的反馈。我发现这是一个很好的方法，因为它可以获得速度（反馈）的好处以及做事情的自然场所。
最后，我想提一下，实现这一目标的方式因项目而异，特别是如果您改造CI。您甚至可能希望仅使用构建和单元测试进行单独的连续构建，并且每天（或某事物）构建一次，以提供版本和测试。这当然意味着只有开发使用快速CI构建，因为它们不完整且不适合部署。不过，长期来看，这不是你想成为的地方。 您希望整个链自动化。
答案 2 :(得分：0)
多年来，我已经通过多种方式完成了这项工作。第一个是发布版本将发生在IF中，并且只有在调试版本的'完整性测试'时才会发生。它还会自动部署到我们的预生产环境，以进行用户驱动的验证。
我也已经看到了这样做，其中发布版本被视为几乎是神圣的，并且它们只有在被认为是“准备好真正部署的时候”时才会被创建。随之而来的是一些“文书工作”和批准，然后发布版本（手动），然后进行完整性检查然后进行部署。
根据我的经验，只要您保持一致并且它与公司/团队理解它应该工作的方式一起工作就没有关系。起初反对谷物很容易，但后来导致一个客户发生的事情，他们实际上放弃了一个结构化的构建/部署方法（一个价值1亿美元的公司做到了，想象，但他们确实这样做了。）