🌐 😢 🕯️ 找到了无痛过渡到.Net Core的公式 🚗 ⛓️ 👨‍⚖️

对于每样东西，每杯50杯咖啡就足够了。

除了上面概述的经验法则外，我们还发布了有关需要密切注意的要点的简短说明，以便在战斗和过程中一切顺利。进行此注释是为了紧追移动服务的发布，该服务已完全迁移到.Net Core（开始于此处）。我们设法在没有停止主要开发过程的情况下就执行了客户未注意到的操作。

下面是一个现成的行动计划，将有一个非常宽敞的测试列表，此图片适合您：

因此，分步进行：

1.规划具有重要功能和/或回归的长距离冲刺

通过基本代码重写，该服务将需要时间来保持尽可能长的时间，以便有时间修复测试环境上的所有缺陷。

2.在精确的Sprint中重写.Net Core上的代码

为什么不提前开展这项业务很重要？因为您必须使用新的和旧的.net来拉出两个代码分支，所以在任何时候都可能出现紧急情况，否则您将需要进行新功能的演示，然后需要对旧的稳定分支进行更改。为了尽量减少对此的担忧，最好缩短过渡状态的时间。

顺便说一句，在使用代码时，我们很快得出结论，在本地保留两个版本的存储库更加方便。比切换两个大型分支更容易，更方便。

如果可能，请在使用的服务中的webapi中重写WCF接口

WCF客户端的.Net Core实现仍远非理想。尽管事实上旧疮在某种程度上是固定的，但在新版本中，您仍然必须使用变通方法（ 1，2 ）。

故事：在.Net Core 2.0上，myget存储库中的WCF稳定工作版本为4.4.2。例如，她在提前超时方面没有任何问题

在迁移开始时，我们使用了.Net Core 2.0版本。同时，Microsoft已发布.Net Core 2.1。谁有兴趣欣赏Redmond家伙在优化平台方面的成功，请阅读Bing搜索引擎在升级到新版本时取得的进展（剧透：latensi下降了34％！）

我们还升级到了.Net Core 2.1和WCF 4.5.3。我们也没有忘记在Dockerfile中指定新的基础microsoft / dotnet映像：2.1-aspnetcore-runtime。令人惊讶的是，他们看到的图像大小为0.5GB，而不是1.4GB（如果是突然的话，我们所说的是Windows图像）。

3.进行测试和演示

我们有两个环境可供选择。我们以旧版本作为参考离开了该演示。一项新服务已部署到测试环境-在开发人员和测试人员上运行。

由于开发人员通常使用测试，而测试人员主要使用演示，因此造成了一些混乱。如果有必要更新旧服务，则情况与正常情况完全相反。因此，方便的讨论和备忘单就在哪里和要寻找的东西上。

配置IIS

要在IIS中运行.Net Core服务，必须安装运行时附带的模块。

AppPool切换到CLR运行时=无托管代码。

在标准web.config中的解决方案中，重要的是不要忘记设置所需的requestTimeout并禁用WebDAV模块（如果有DELETE方法）。

此外，有两种选择可用于在IIS中发布服务：

您执行MSDeploy同步-这意味着您还需要-enableRule开关：AppOffline
您要进行文件发布-这意味着恰好在发布之前需要将文件app_offline.htm放在服务目录中，并在发布之后将其删除

两者都允许停止工作进程并打开可执行文件。否则，将发生错误，指出文件不可用于覆盖。

我们拒绝通过Nlog支持Serilog进行日志记录，并且丢失了日志的自动压缩功能-在Serilog中根本没有这样的功能。在这种情况下，可以使用常规Windows工具进行保存，并在目录属性中安装NTFS压缩。

4.测试

这是最脆弱的地方最缩小的清单：

检查状态码的返回错误的请求，未授权，未修改，未找到-API可以提供的所有功能
检查请求日志以获取所有状态代码
绘制外部依赖关系图；通常，所有必要的信息都在设置中
- 消除影响他们工作的方法
- 检查外部请求的日志记录
检查appsettings参数的设置的功能；尝试将它们变热
检查http缓存中的正负状态代码
- ETag标头
- 标头缓存控制
检查长请求和超时
用空答案检查请求
检查DELETE方法（是否禁用WebDAV）
用原始内容检查工作
- 上传并下载一个/几个文件
- 上传大小超出限制的文件
- 标头布局Content-Disposition
检查所有其他标题；将它们全部整合到代码中非常容易
if (env.IsDevelopment())在切换环境时检查条件代码执行
检查与客户端和服务器的断开连接
与标准swagger.json比较-将有助于检测传输字段中的差异
我们的移动应用程序基于swagger.json的描述使用代码生成器与API配合使用，因此与原始描述的差异最小是很重要的。在最新版本的Swashbuckle.AspNetCore中，界面和生成的swagger.json发生了很大变化。我必须回滚到Swashbuckle.AspNetCore 1.2.0的破旧版本，并添加几个过滤器。

5.边喝咖啡边打架

在我们的案例中，战斗环境由两个节点组成：主动节点和被动节点。
为了不引起切换到新服务的麻烦，我们在每个节点上复制了池和站点，并编写了脚本来切换旧站点和新站点之间的绑定。

因此，在紧急情况下，我们能够快速切换到旧版本。

此外，在部署到战斗中之后，我们在一周内就对服务的可行性深信不疑，并为发布移动应用程序开了绿灯。该项目的生命安全地恢复了以前的过程。

小计

现在，我们的服务已准备就绪，可以扩展Docker容器以交付给集群。我们已经准备好在Kubernetes和Service Fabric中进行部署。

找到了无痛过渡到.Net Core的公式