问题描述
在他们的IT部门中有多个开发团队和DevOps团队。最近，他们的.NET开发团队完成了一个基于.NET 3.1的应用程序，完成时间约为一年。他们希望与相关的DevOps团队协调，将该应用程序部署到UAT环境。然而，当他们在部署应用程序时取得进展时，DevOps团队的管理层阻止了他们，因为他们说.NET 3.1已不再得到Microsoft的支持。因此，他们表示，如果在生产环境中部署不受支持的技术，检查员/审计员将提出严重的担忧。这个事件背后的政治因素似乎有点暗示DevOps团队将责任归咎于他们的.NET开发团队，因为他们没有意识到.NET 3.1已不再得到Microsoft的支持。作为.NET开发团队的一员，我觉得我们承受了太多的责备。他们想知道在这种情况下，可以采取什么样的管理技术/流程/程序来防止这种挫折性事件的发生。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
首先，要解决这个问题，需要建立一个DevOps思维方式。DevOps不是指“DevOps团队”，而是一组基于敏捷软件开发的价值观和原则。敏捷软件开发的一个关键原则是“业务人员和开发人员必须在整个项目期间每天一起工作”。DevOps在此基础上拓展，打破了开发团队和运维团队之间的壁垒，并将运维考虑因素提前到系统开发生命周期中，有时被称为“向左移动”。
从你的问题描述中可以看出，你没有采用DevOps的思维方式，因为你直到在部署到UAT环境之前才发现了一个运维问题。如果使用过时和不受支持的工具和技术是一种风险，我会期望这个问题在流程的早期就被提出来，甚至在需求中。你可以在部署只支持的依赖项方面有具体的要求，并且如果有技术原因无法满足要求，可以接受适当的偏差。DevOps文化的一部分是文化转变，朝着自动化的方向发展，因此我期望在团队中使用静态分析和依赖分析工具，如果有第三方依赖项包含已知漏洞或已经停止维护，这些工具会发出警告，以便团队采取适当的行动。
因此，如果你真的想要防止这种问题的发生，我建议你真正了解DevOps的价值观和原则。让你的运维专家参与到系统需求中，并找到方法将质量融入到产品中，可能是通过自动化实现。
方案2
还有一种方法是使用脚本或工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。
示例：
以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。
方案3
还有一些DevOps的能力可以帮助你的情况。
首先，DevOps最初的理念是开发人员和运维人员始终合作。如果你有一个开发团队与运维团队隔离的情况，那肯定不是DevOps，即使他们被命名为“DevOps”。
以下是一些能力，我会挑选一些特定的技术和实践，我认为这些能力将在你的组织中对未来的工作产生真正的帮助。
文化：Westrum组织文化
你的问题中涉及了很多责备。DevOps真正需要的是一种生成性文化。这意味着一种无责备的文化，具有高度的心理安全性。你需要建立信任，最大限度地提高学习能力，并使人们满意他们能够做好工作。
这是成功结果的最重要预测因素之一。
也许你不能改变组织的思维方式，但你肯定可以通过对待问题的方式对你的情况产生影响。与其寻找责备的对象，不如想办法与其他团队合作，以便下次能够取得更好的结果。一些同理心和关系建立将产生很大的影响。
精益产品开发：小批量工作
如果有一个普遍的教训，它是从分阶段软件交付、敏捷、精益和DevOps中得出的…那就是“小批量工作”。
想象一下，在第一周创建了一个最小的.NET应用程序。它只有一个API端点，返回“hello world”。如果你交付了这个版本的应用程序，你可能会在一年前发现.NET版本的问题。
想象一下，一年前发现问题与即将上线时发现问题的差异。情况不会像现在这样紧张，因为上线的压力正在增加。
小批量工作也意味着你和运维团队对部署流水线有信心，因为你们一年来每周都在部署。
技术能力：持续交付
这实际上是一系列能力的综合体，但它们高度相关。将代码频繁集成到主分支中，并具有自动化的部署流水线，使你的代码“随时准备部署”，这是从软件交付中消除压力的好方法。
在你的情况下，构建部署流水线意味着与运维团队更早地合作，并了解他们可能具有的治理、风险和合规性需求。
一个良好的构建过程和自动化部署将提高你的团队的信心，如果你能使这个领域变得无痛，也会增强团队的信心。
到处都有能力！
你可以在DORA研究网站上探索更多的能力。有很多研究和分析为我们提供了对模型中关系的信心。
.NET注意事项
升级.NET版本应该不会太麻烦。我已经将.NET Core MVC站点更新到.NET 6，而且没有代码需要更改。我倾向于定期更新，所以现在我正在使用.NET 7，但你可能希望坚持使用.NET 6，因为偶数版本有3年的支持。奇数版本只有短期支持。
希望你能更新你的API并将其发布。现在是引入某种持续改进流程，以使未来的工作变得更好的时机。一旦尘埃落定，危机过去，人们将不太愿意改变现状。
祝你好运！