DevOps正在终止维护。 让我们一起庆祝吧。

DevOps可能不会杀死开发人员 。

但这正在改变人们对开发的看法 -从运行项目到专注于构建和运行服务。 更重要的是，DevOps正在终止维护，维持工程或任何经理想要的工作。 这是我们所有人都应该庆祝的事情。

高带宽协作和对敏捷变化的快速响应使外包的CMMI 5级认证开发工厂完成了离岸开发。 DevOps通过扩展开发团队和运营团队之间的协作，并提高了交付到生产的速度（每天多达数百甚至数千次），并利用生产中的真实反馈来推动开发优先级和设计决策，从而使DevOps停滞不前提出了这样一个令人生厌的想法：维护工作应该由持续的工程团队来完成，并与服务台一起离岸到遥远的某个地方，以便获得廉价的人才。

Devops可以完成

当大型公司忙于寻找离岸开发和测试合作伙伴时，敏捷改变了他们的游戏规则。

在大型瀑布式项目中，支持大量编码和测试工作是有意义的，因为该项目具有大量的前期计划和详细规范，可以从分析师那里移交给程序员和测试人员。

但是，在包括大型企业在内的许多组织中成功采用敏捷技术 ，使得外包或离岸开发工作变得不切实际 ，效率更低。 敏捷团队无需进行详细的分析和记录下的交接，而是依靠彼此之间，特别是与客户之间的高带宽面对面协作以及快速的迭代和反馈。 一切发生得更快。 客户更改优先级和要求。 开发人员可以更快地响应并构建和交付功能。

在持续集成，结对编程以及持续审查和改进中，时间密集型和人工密集型工作（例如手动测试和审查）被自动测试和静态分析所取代。

在这个充满活力的世界中，尝试将工作铲向海外是没有道理的。 您必须放弃太多回报以节省员工成本。 跨时区和文化的电话会议，使用网络摄像头的“虚拟团队会议室”，通过Skype进行远程配对编程……这些都是糟糕的折衷方案，导致误解，效率低下和错误。 当然，您可以进行离岸敏捷开发，但是仅仅因为您可以做某事并不意味着这是个好主意。

Devops将完成工作

在DevOps中，通过持续交付和持续部署，更改发生得更快。 周期时间和响应时间变短，从几个月或几周到几天或几小时。 反馈周期从开发到生产都已延长，让整个IT组织都可以进行试验，并从实际的客户使用中学习和改进。

开发人员不仅要彼此之间和与客户之间，而且还要与操作方面进行更多的协作，以确保系统正确设置并以最佳方式运行。 在不同时区工作的开发和运营团队无法有效地做到这一点。 而且并不需要如此。

我们都知道外包是如何发挥作用的。 我们以效率为名，将核心IT的非战略部分分割开来，然后将其出售给其他公司，无论是离岸公司还是国内公司。 首席信息官之所以喜欢它是因为预算方面的好处。 同时，它引发了关于IT外包，美国经济，个人职业以及人与企业之间关系的一千场对话。

但是事实证明，我们把外包做得太过分了。 它对某些功能有意义，但也可能意味着失去对管理，质量和安全性的控制权。 现在，我们看到许多大合同被撤回，而今天的话就是内包。

《信息周刊》 ， DevOps：新的外包

线条模糊

DevOps故意模糊了开发人员与操作之间，编码与支持之间的界限。 工程就是工程。 项目工作分解为零碎工作：可以快速完成并尽快投入生产的单个功能或修复或升级。 开发工作与操作和支持任务一起被确定优先级。 重要的是对企业重要的是什么，对于系统运行需要什么。 如果企业现在需要修复某些东西，那么最好的人会修复它，而不是将其交给一些孩子或运送到国外。

在DevOps中，开发人员要负责确保其代码在生产中可以正常工作：

“ 构建它，运行它 ”

这意味着确保代码投入生产，进行监视以确保其正常工作，在发生问题时诊断并修复任何问题。

新功能，更改，修复，升级，支持工作，部署……所有工作均由同一个人共同完成。 这意味着维护和支持与新开发具有相同的管理重点。 这意味着没有人会陷入支持死胡同系统的死胡同工作。 这意味着客户在需要时可以获得更好的结果。

除了基于生命支持的企业遗留系统之外，由于DevOps，我们今天大多数人认为它的维护应该很快就会死掉。 仅凭这一点，DevOps就值得采用。

翻译自: https://www.javacodegeeks.com/2015/05/devops-is-killing-maintenance-lets-celebrate.html