持续交付中的部分包

Question

目前我们正在运行一个 C#（基于 Sharepoint 构建）项目，并实施了一系列自动化流程来帮助交付，以下是详细信息。

1. 持续集成。 DEV环境下频繁编译部署的典型CI系统。
2. 部分包装。每周，都会确定伴随修复的缺陷列表，并从完整包中提取相应的程序集以形成部分包。部分包在后续环境中进行部署和测试。

在这个管道中，有两个包正在被验证。额外的努力用于为部分包建立一个新系统（网站、脚本、流程等）。然而，一些因素阻碍了它的改进。

1. 构建和部署时间过长。在开发人员的机器上，对程序集的每一次修改都会在 IIS 中触发大约 5 到 10 分钟的重新部署。此外，重建整个解决方案需要 15 分钟（甚至更长时间）。 （这个项目最痛苦的部分）
2. 地理差异。每个最终包裹都会被送到另一个办公室，因此手动操作是不可避免的，并且包裹尺寸最好小。

如果您能提出意见，推动持续交付实践向前发展，我将不胜感激。谢谢！

Answer 1

我想这个问题没有答案的原因是因为它的范围太大了。需要消除的变量太多了，但我会尽力提供帮助。我也不确定您的技能水平，因此对于基础知识，我提前道歉，但我认为它们将有助于改进和更好地集中您的问题。

尽可能缩小问题范围

“太长”是一个非常主观的术语。我知道一些较大的项目希望看到 15 分钟的构建时间。鉴于您的问题，无法知道您遇到的是配置问题还是基础架构问题。配置问题的一个示例是，您的项目是否通过并行构建来充分利用多个内核/m switch？基础架构问题的一个示例是，如果您尝试使用无效或有缺陷的硬件在慢速线路上移动大量数据。听起来您在不同的机器上看到相同的时间，因此您可能希望专注于配置。

将您的构建分解为“任务”，并将每个任务分解为最简洁的步骤

这将最大程度地帮助您调整配置并了解更好地编排所需的内容。如果您正在使用 CI 服务器构建解决方案，您可能正在使用类似 msbuild.exe OurProduct.sln 这样的命令运行，这是快速启动和运行的正确方法，因此会有一些反馈。但是为了优化，这个解决方案需要分解成独立的项目。如果您发现一个项目导致您花费大量时间，这可能表明存在其他问题，或者可能只是其他一切都依赖的核心项目。您如何处理构建作业依赖项取决于您的 CI 服务器和解决方案。这样做会为您创建更多的编排，但如果这是需要的话，可以提供更快的反馈，因为您只是在构建发生变化的项目，而不是完整的解决方案。

我不确定您所说的“地理差异”是什么意思。这是对办公室的“推”还是从办公室的“拉”？这完全是另一个问题。你是怎么把文件放在那里的？为什么这需要手动步骤？

缩小你的范围并做多个问题，你可能会得到更好（更不用说更简洁）的答案。

最好的！

Answer 2

我不是 C# 开发人员，但原则保持不变。

为了加快构建速度，有必要尽可能将应用程序分解成更小的块。如果这是不可能的，那么你现在就有更大的问题要解决。记住 API、组件和关注点分离的原则。如果您不熟悉这些原则，那么绝对值得花时间了解它们。

在部署方面 - 很高兴您已经实现了自动化，但这听起来与您正在构建一个大爆炸部署完全相同。您能想出一种仅将增量部署到服务器的方法，您是否部署了单个压缩文件？如果可能的话，分手吧。