我很惊讶这不是重复的，但是我找不到另一个。
好的，这是交易。它们是两个独立但相关的问题。
对于构建管理，重要的一点是您应该具有一个可重复的自动构建，该构建可以从头开始重建整个软件集合，并一直进行到可交付的配置。换句话说，您应该每次都有效地构建一个候选发布版本。许多项目并没有真正做到这一点，但是我已经看到它烧伤了很多人（读“被它烧死”）。
持续集成表示，只要有可能，每次代码发生重大更改事件（如签入）时，都应重复此构建过程。我已经完成了多个项目，每晚都会在其中进行构建，因为代码足够大，需要花费数小时才能构建，但是理想的情况是设置构建过程，以便使用一些自动机制，例如蚂蚁脚本或生成文件
—仅重建受更改影响的部分。
您可以通过保留每种构建的所有受影响工件的确切配置来解决提供特定发行版的问题，因此可以将可重复的构建过程应用于您拥有的精确配置。（这就是为什么它被称为“配置管理”的原因。）常用的版本控制工具（如git或subversion）提供了标识和命名配置的方法，以便可以对其进行恢复；例如，在svn中，您可以为特定构建构建标签。您只需要保留一些元数据，以便知道使用的配置。
您可能想要阅读其中一本“实用的版本控制”书，当然，马丁·福勒（Martin Fowler）网站上CI和Cruise Control方面的内容也至关重要。
