0

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

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

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

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

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

4

2 回答 2

0

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

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

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

于 2014-03-29T21:17:09.153 回答
0

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

尽可能缩小您的问题范围

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

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

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

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

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

最好的！

于 2013-10-01T18:18:04.453 回答