我有一个我们之前使用 nAnt 脚本构建的 NSIS 安装程序，它复制一些文件并通过 exec 任务运行 makensis.exe 来构建安装程序 exe。在 nant 脚本完成后，我有了 CD 的完整结构和下载。
我只是从 sourcesafe 获取到一个未使用的桌面并将其用作构建框，在那里编译。有时我们会检查几个文件来修复一些关键问题。在这些情况下，我会去构建框，并且非常有选择地只获取那些文件，以避免获取我们尚未准备好发布的其他已更改文件。基本上，我能够允许开发继续并有选择地将某些更改的文件包含到安装程序中以供发布。
现在我们不再有免费的盒子，需要从我们的服务器构建。所以我正在设置 CI 工厂，以便开发人员可以在不远程连接到服务器的情况下启动构建。我正在努力解决的一个问题是继续允许这种选择性变更控制发生的最佳方式。CI Factory 实现的默认 CI 概念非常适合内部开发“负责人”。但是，我还想为这种“公开发布”类型的构建设置一个仅通过强制构建按需运行的 CCNet 项目。
到目前为止，这就是我的头脑风暴，但不确定它的效果如何，如果有的话（仍在弄清楚 CCNet 和 CI 工厂的全部内容）。将设置“公开发布”CCNet 项目配置/构建，使其不会最新。修改不会触发构建。由于另一个 CCNet 项目使用默认的 CI 方法（我们将其称为“CI 项目”）在检测到更改时获取最新信息，因此这两个项目不能共享同一个工作目录。所以“公开发布”需要一个不同的工作副本，这样当 CI 项目的构建被触发时，它的文件就不会被更新。开发人员需要远程访问服务器，一个 VSS，有选择地进入“公共发布”的工作副本，然后通过 CI 工厂强制构建。
我看到的缺点是
1) 必须远程访问才能有选择地进行获取。
2) 我不知道如何允许单个 CI 工厂项目拥有 Product 文件夹的两个不同工作副本，以便每个项目配置块都有自己的。
3）我担心这可能会导致什么样的奇怪。我还不太确定如何在 CCNet 项目配置块中指定源代码控制块，但要防止它在构建时执行最新操作。我仍在逐渐弄清楚脚本中的内容，并且可以在不破坏其他内容的情况下轻松取出，而不是那些不应该被弄乱和/或不可配置的东西。
如果您有类似的情况，我真的很想听听其他人如何处理选择性发布更改的问题。我受限于 VSS，所以我迫切需要考虑到这一点来解决这个问题，但同时我很想听听您如何使用其他源代码控制系统来管理这个问题。我猜你可能会有一个分支是你最新的开发分支，然后在你想发布它们时将更改合并到主干中？我真的不相信 VSS 进行分支/合并，我认为分支概念对于这家商店来说可能有点过多的开销和学习曲线。就像我说的那样，其他源代码控制系统的故事对我来说是有用的未来知识。
提前致谢。