3

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

软件版本由什么组成？

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

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

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

手动流程

很久以前，我们手动管理这个。

  1. 启动每个新版本时，用于构建最后一个版本的文件将被复制到共享驱动器上的新文件夹中。
  2. 开发人员将手动添加或更新此文件夹中的文件（希望不会意外丢失或删除任何内容）。
  3. 将使用此文件夹中的文件编译软件安装程序脚本以生成 SETUP.EXE（输出）。
  4. 在验证和测试期间迭代步骤 2 和 3，直到发布。

自动化流程

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

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

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

剩余差距

到目前为止很好，但这给我们留下了两个问题：

  1. 重新构建程序集 CI 主要是在某些事情发生变化时构建项目，但当强制执行时，它会重新编译没有任何代码更改的二进制文件。输出是我们之前测试过的二进制文件的全新构建（提示：我们应该始终相信它们是等价的吗？）。
  2. 最新与稳定我们的 CI 机器主要构建每个项目的最新版本。在某些情况下这是可以的，但我们通常希望发布一个较旧的测试或稳定版本。为此，我们为最新和稳定的构建提供了单独的 CI 项目——这可行但很笨拙。

感谢您的耐心等待，如果您已经走到这一步了:-)

我还没有找到我要找的东西

在寻找解决方案一段时间后，似乎构建我们自己的解决方案可能更容易，但肯定有人以前解决过这些问题！？

我们想要的是一种存储和管理二进制文件（来自 CI 的输出，或第 3 方文件）的方法，这样每个文件都带有一个版本（v1.2.3.4）标签，允许：

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

我知道过去关于在 VCS 中存储二进制文件的争论。现在我正在寻找更好的解决方案。这种方法对于长期持续使用（例如如何修剪旧的二进制文件）似乎并不理想......以及其他问题。

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

有没有人知道这方面的工具？

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

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

4

1 回答 1

1

这是一个非常广泛的主题，但听起来你想要一个发布管理工具（例如BuildMaster，由我的公司 Inedo 开发），可能与 ProGet 之类的包管理服务器（你标记的，这就是我发现这个问题的方式）。

为了解决您遇到的一些具体问题，我会将其与可以解决问题的功能相关联：

混合文件进入我们的软件版本，包括...

这是在 BuildMaster 中使用工件处理的。该视频基本概述了如何将它们手动添加到版本和部署到文件系统：https ://inedo.com/support/tutorials/buildmaster/deployments/deploying-a-simple-web-app-to-iis

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

重建程序集......输出是我们之前测试过的二进制文件的新构建（提示：我们是否应该始终相信它们是等价的？）

您通常可以假设它们在功能上是等效的，但只有在它们不是问题的时候才会出现。对于不将依赖项锁定到特定版本号（即 NuGet、npm）的包管理器尤其如此。您应该发布与之前环境中测试过的完全相同的二进制文件。

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

这是通过发布来处理的。开发人员可以选择其名称、日期等，并将其与管道（即工件部署到的一组测试阶段）相关联，然后可以“单击部署按钮”并让自动化完成所有工作。

发布按“应用程序”分组，类似于 TeamCity 中的项目。作为更高级的用例，您可以使用deployables。可部署项本质上是您在发布中包含的应用程序的各个组件；在您的情况下，“文档”可能是可部署的，并且可能包含 .pdf 和 .docx 文件的工件。来自其他应用程序的可部署（可能由不同的团队负责，或其他）然后可以被引用并“包含”在一个版本中，或者您可以引用过去版本中的那些。

希望这提供了一些概述并满足您的需求。进入这个领域有点让人不知所措，因为有太多的术语、技术和方法，但我的建议是从简单开始，然后慢慢建立，例如：

  • 通过 BuildMaster 将单个手动上传的组件部署到共享驱动器，然后从那里手动部署它
  • 添加导入组件的部署计划
  • 添加第二个计划并将其与获取上传的工件并将其部署到目标的第二阶段相关联，绕过对共享驱动器的需求
  • 添加更多部署计划并将它们与管道阶段相关联，并通过它们进行推广以“结束”发布
  • 添加代理并部署到该代理而不是默认的本地主机服务器
  • 添加更多组件并将其部署与可部署对象隔离
  • 在流程中的各个点向电子邮件团队成员添加事件侦听器
  • 如果您需要门控“签字”，请开始添加批准

等等。

于 2018-08-16T15:34:37.953 回答