哪些更改需要重新部署依赖程序集

本文关键字：部署 程序集 依赖 新部署 | 更新日期: 2023-09-27 18:13:30

在我的工作场所，我们通过仅替换已更改的程序集来部署内部应用程序(这不是我的想法)。

我们可以通过查看编译成程序集的源文件是否已更改来判断需要部署哪些程序集。大多数情况下，我们不需要重新部署依赖于已更改的程序集的程序集。但是，我们发现在某些情况下，即使程序集中的源文件没有更改，我们也需要重新部署它。

到目前为止，我们知道程序集中的任何这些更改都需要重新编译和部署所有依赖的程序集:

  • 不断变化
  • 枚举定义更改(值顺序)
  • 函数的返回类型改变，调用者使用var(有时)
  • 类的命名空间更改为另一个已引用的命名空间。

我们还遗漏了其他病例吗?我也愿意讨论为什么整个方法是有缺陷的(尽管它已经使用了多年)。

Edit要清楚，我们总是重新编译，但只部署源文件发生变化的程序集。

因此，任何破坏编译的东西(方法名更改等)都将被拾取，因为它们需要更改调用代码。

哪些更改需要重新部署依赖程序集

还有一个:

修改可选参数的值。

使用默认值(如果未指定)直接将其编译为程序集

 public void MyOptMethod(int optInt = 5) {}

任何调用代码，如:

 theClass.MyOptMethod();

将最终编译为:

 theClass.MyOptMethod(5);

如果将方法更改为:

 public void MyOptMethod(int optInt = 10) {}

如果要应用新的默认值，则需要重新编译所有依赖的程序集。

需要重新编译的其他更改(感谢Polynomial):

  • 泛型类型参数约束的更改
  • 方法名称的更改(当使用反射时尤其有问题，因为私有方法也可能被检查)
  • 异常处理的变化(抛出不同的异常类型)
  • 线程处理的更改
  • 等等……等等……等等…
总是

- 编译一切。

首先，我们有时在一个应用程序中只部署了几个程序集，而不是整个应用程序。然而，这绝不是常态，只有在我们的测试环境中，当开发人员最近(就在最后几分钟内)发布了整个网站，只是做了一个小的调整。然而，一旦开发人员感到满意，他们就会继续进行完整的重新编译和重新发布。

最后的测试总是基于一个完整的重新编译/部署。推进到登台和最终制作是基于完整的副本。

除了可重复性之外，一个原因是你真的不能100%肯定人类在比较中没有错过一些东西。接下来，部署100个程序集和部署5个程序集的时间是微不足道的，坦率地说，不值得花那么多时间去尝试找出真正发生了什么变化。

坦率地说，你的清单加上Oded的答案应该足以让其他人相信失败的可能性。然而，由于这种懒散的方法，您已经遇到了失败，这一事实应该足以成为一个警告标志，阻止它继续下去。

在一天结束的时候，这真的归结为一个专业的问题。在创建健壮的任务关键型应用程序时，将代码从开发中移出、通过各种环节最终进入生产的过程的标准化和可重复性是极其重要的。如果您的部署过程充满了由于这些类型的风险导致的捷径而导致的潜在失败，那么就会对所生成代码的质量提出问题。
相关文章：