连续运送的部分包裹

Question

目前，我们正在运行一个C# (构建在Sharepoint上)项目，并且已经实现了一系列的自动化过程来帮助交付，下面是详细信息。

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

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

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

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

Answer 1

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

将您的问题范围缩小到尽可能窄的

“太长”是一个非常主观的术语。我知道一些更大的项目，希望看到15分钟的构建时间。考虑到您的问题，您无法知道您是遇到了配置问题还是基础结构问题。配置问题的一个例子是，您的项目是否通过构建并行/m开关来充分利用多个核心？基础设施问题的一个例子是，如果您试图使用无效或有缺陷的硬件将大量数据移动到慢速线路上。听起来，您在不同的机器上看到相同的时间，所以您可能需要关注配置。

将您的构建分解为“任务”，并将每个任务分解为尽可能简洁的步骤()。

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

我不知道你说的“地域差异”是什么意思。这是“推”到办公室还是从办公室“拉”？这是另一个问题。你是怎么拿到文件的？为什么这需要手动操作呢？

缩小你的范围，做多个问题，你可能会得到更好的答案(更不用说更短、更简洁了)。

最好的！

Answer 2

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

为了加快构建速度，有必要在可能的情况下将应用程序分解成更小的块。如果这是不可能的，那么你现在有更大的问题要攻击。记住API的原理、组件和关注点的分离。如果您不熟悉这些原则，那么了解这些原则肯定是值得的。

在部署方面-很好，您已经自动化了它，但听起来与您正在构建的大爆炸部署完全一样。您能想到一种只将增量部署到服务器上的方法吗?您是否部署了一个压缩文件？如果可能的话就分手吧。