持续交付中的部分包

Question

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

1. 持续整合。典型的CI系统，用于在DEV环境中频繁编译和部署。
2. 部分套餐。每周都会识别出附带修复的缺陷列表，并从完整包中提取相应的程序集以形成部分包。部分包在后续环境中进行部署和测试。

在此管道中，正在验证有两个正在经历的包。额外的努力用于为部分包构建新系统（网站，脚本，过程等）。但是，有些因素阻碍了它的改进。

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

我将非常感谢您的意见，以推动持续交付实践。谢谢！

Answer 1

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

将问题范围尽可能缩小

<太长“是一个非常主观的术语。我知道一些更喜欢看15分钟构建时间的大型项目。鉴于您的问题，无法知道您是否遇到配置问题或基础架构问题。配置问题的一个示例是，您的项目是否通过构建并行/m switch来充分利用多个核心？如果您尝试使用无效或有缺陷的硬件在慢速线路上移动大量数据，那么基础设施问题就是一个例子。听起来你在不同的机器上看到相同的时间，所以你可能想要专注于配置。

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

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

我不确定你对“地理差异”的意思。这是对办公室的“推动”还是来自办公室的“拉动”？这是另一个问题。你如何获得那里的文件？为什么需要手动步骤？

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

最佳！

Answer 2

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

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

在部署方面 - 很棒，你已经自动化了它，但听起来和你正在建立一个大爆炸部署完全相同。你能想到一种只向服务器部署增量的方法，你是否部署了一个压缩文件？如果可能的话，分手。