Installation 如何在安装打包时管理稳定的二进制文件并避免CI重建的风险？

我正在寻找一个工具来管理二进制文件（输入组件）的集合，组成一个软件版本。这是一款软件产品，在过去20年中，我们每年都发布多个版本。文件的细节和类型可能会有所不同，但这是许多软件团队需要管理的

软件版本是由什么组成的？ 我们的软件版本中包含多种文件，包括：

• Windows可执行文件/二进制文件（40个DLL和30多个EXE文件）
• 安装程序用于创建数据库的脚本
• 各种平台（.NET、ActiveX和Java）的API程序集
• 文档文件（HTML、PDF、CHM）
• 示例应用程序的源代码

该版本的单个版本收集的完整文件约为90MB。大多数是从源代码构建的，但有些是第三方的

手工过程 很久以前，我们是手工管理的

启动每个新版本时，用于生成上一版本的文件将复制到共享驱动器上的新文件夹中

开发人员将手动添加或更新此文件夹中的文件（希望不会意外丢失或删除任何文件）

软件安装程序脚本将使用此文件夹中的文件进行编译，以生成SETUP.EXE（输出）

在验证和测试期间重复步骤2和3，直到发布

自动处理 几年前，我们采用了CI（每晚或按需构建二进制文件）

我们求助于将第三方二进制文件置于版本控制之下，因为它们通常不会经常更改

然后，我们根据CI构建输出自动收集和更新发布文件的过程。最后，我们能够自动构建SETUP.EXE

剩余差距 到目前为止还不错，但这给我们留下了两个问题：

重建程序集CI主要在某些内容发生更改时构建项目，但在强制执行时，它将重新编译没有任何代码更改的二进制文件。输出是我们之前测试过的二进制文件的新版本（提示：我们应该始终相信它们是等效的吗？）

最新vs稳定我们的CI机器主要构建每个项目的最新版本。在某些情况下，这是可以的，但我们通常希望发布一个较旧的、经过测试的或稳定的版本。为了做到这一点，我们为最新的和稳定的构建提供了单独的CI项目——这很有效，但很笨拙

感谢您的耐心，如果您已经做到这一点：-）

我还没找到我要找的东西 在寻找解决方案一段时间后，似乎构建我们自己的解决方案更容易，但肯定有其他人以前解决过这些问题

我们需要的是一种存储和管理二进制文件（来自CI的输出或第三方文件）的方法，以便每个文件都标记有一个版本（v1.2.3.4），该版本允许：

• CI将发布每个二进制文件的新版本（但拒绝已存在的重建版本）
• 开发团队需要为软件发布（有点像NuGet packages.config）制定一个配方，其中指定要包括的组件：
  • 包名
  • 版本
  • 发布文件夹中的路径/目标
• 使用配方的自动软件包脚本收集所需文件，并编译安装软件包（例如SETUP.EXE）

我知道过去关于在VCS中存储二进制文件的争论。目前，我正在寻找更好的解决方案。这种方法似乎不适合长期持续使用（例如，如何修剪旧的二进制文件）。。。除其他问题外

我尝试了一些目前可用的工件库。根据我的调查，这些为组件/工件存储和版本控制提供了解决方案。但是，它们不提供用于管理要包含在软件版本中的组件/工件列表的工具

有人知道这方面的工具吗

您是否找到了让CI基础架构解决这些遗留问题的方法

---

如果您正在使用工件存储库来解决此问题，您如何管理和自动化此过程？

这是一个非常广泛的主题，但听起来您需要一个发布管理工具（例如，由我的公司Inedo开发），可能与ProGet这样的包管理服务器结合使用（你标记了它，这就是我发现这个问题的方式）

为了解决您的一些具体问题，我将把它与解决问题的功能联系起来：

我们的软件版本中包含多种文件，包括

这在BuildMaster中通过工件进行处理。本视频提供了如何手动将工件添加到发行版并部署到文件系统的基本概述：

当然，一旦达到满意的效果，您可以自动从现有CI工具导入工件，从BuildMaster部署计划本身创建工件，从包服务器中提取工件，等等。接下来，您还可以让您的CI工具调用BuildMaster发布管理API来创建一个发布，并自动它包括您想要的所有工件和组件（这是我们大多数客户现在所做的，即在TeamCity中有一个构建步骤）

正在重建程序集…输出是我们之前测试过的二进制文件的新版本（提示：我们应该始终相信它们是等效的吗？）

大多数情况下，您可以假设它们在功能上是等效的，但只有当它们不等效时，问题才会出现。对于不将依赖项锁定到特定版本号（即NuGet、npm）的包管理器来说，这一点尤其正确。您应该发布与以前环境中测试的完全相同的二进制文件

[我们希望]开发团队为软件发布（有点像NuGet packages.config）制定一个配方，指定要包括的组件：

这是用.A devel处理的