DevOps是否会减少技术债务-或更糟？

DevOps可以从根本上帮助减少技术债务 。

持续交付/部署

首先，建立一个持续交付/部署管道 ，自动化迁移和部署工作，将迫使您清除配置和代码部署中的矛盾和漏洞，以及开发，测试和生产环境之间的矛盾。

自动化的持续交付和基础架构代码消除了因更改配置和手动应用补丁而造成的危险的雪花和配置漂移 。 这使系统更易于设置和管理，并降低了未打补丁的系统成为安全攻击或操作问题原因的风险。

CD管道还可以更轻松，更便宜，更快捷地偿还其他类型的技术债务。 通过持续交付/部署，您可以更快，更放心地测试和推出补丁程序以及重构更改和平台升级。

正面反馈

DevOps中的精益反馈周期和及时优先级可确保您从事对业务最重要的事情。 这意味着错误，可用性问题和安全漏洞不必等到下一个功能发布之后才能得到解决。 相反，影响操作或用户的问题将立即得到解决。

在问题出现时进行无懈可击的事后分析和根本原因分析的团队将会走得更远，并且从根本上解决问题并以根本和重要的方式进行改进。

但是DevOps的不利方面会增加技术债务成本。

侵蚀性变化

迈克尔·费瑟斯（Michael Feathers）的研究表明，持续不断的迭代更改是有害的 ： 反复更改相同的代码，相同的类和方法变得肿（因为自然而然地，将代码添加到现有方法中或将方法添加到现有类中比较容易） ），结构崩溃，最终设计丢失。

DevOps会使情况更糟。

DevOps和持续交付/部署涉及基于生产使用的持续反馈，推出许多小的更改，运行实验并迭代调整功能和用户体验。

许多DevOps团队直接在代码主线上工作，在代码仍在开发过程中，使用条件逻辑和标志在运行时跳过代码部分，从“ 分支到代码 ”到“ 暗启动 ”代码更改。 这可能会使代码难以理解，并可能带来危险：如果在代码准备就绪之前打开功能切换 ， 则会发生不良情况 。

功能标记还用于运行A / B实验并通过将更改逐步推广到几个用户来控制发布时的风险。 但是功能标记在代码中保留的时间越长，就越难理解和更改 。

在DevOps中，需要做很多内务处理：升级CD管道并确保所有测试都可以正常进行； 维护Puppet或Chef（或您使用的任何配置管理工具）配方； 规范的日常重构 ； 跟踪功能和选项，并在不再需要它们时清理它们，摆脱无效的代码，并尝试使代码尽可能简单。

微服务和技术选择

微服务是DevOps团队常用的架构方法 。

这是因为松散耦合的微服务使单个团队更易于独立部署，更改， 重构甚至替换 。

基于微服务的方法为开发人员在决定语言或技术堆栈时提供了更大的自由度：团队不一定必须以相同的方式工作，只要他们支持API合同即可为工作选择合适的工具。系统的其余部分。

在短期内，为团队提供更多的自由选择技术具有明显的优势。 他们可以更快地交付代码，快速试用原型，团队可以有机会对不同的技术和语言进行试验和学习。

但是微服务“ 不是免费的午餐 ”。 随着您添加更多服务，系统测试成本和复杂性也会增加。 调试和解决问题变得更加困难。 随着越来越多的团队选择不同的语言和框架，追踪漏洞，操作变得更加困难，人们在团队之间切换的难度也越来越大。 因为团队希望最大程度地减少耦合，并且很难或不可能在多语言环境中共享库，所以代码会重复。 出于相同的原因，数据经常在服务之间重复，并且随着时间的流逝，数据不一致会逐渐蔓延。

负面反馈

精益交付反馈周期也有潜在的负面影响。

不断响应生产反馈，始终致力于对组织最重要的事情，不会留出足够的空间或时间来考虑更大，更长期的技术问题，并且还清了因以下原因而产生的更深层次的架构和技术设计债务：错误的早期决策或错误的假设。

在DevOps中，较小的，更直接的问题得以快速解决。 对操作至关重要的错误，用户可以立即得到解决，而不必等到所有功能都完成之后，才可以更频繁地推出补丁和对运行时的升级。 这意味着您可以在成本开始增加之前还清大量债务。

但是在幕后，战略债务将继续增加。 没有任何问题，因此您不必立即修复任何问题。 而且，您也无法重构自己的出路，至少不容易。 因此，您最终只能使用较差的设计或陈旧的技术平台，从而慢慢降低了对更改的响应能力，从而提出了新的解决方案。 或迫使您在出现安全漏洞时继续进行填充，或者随着负载的增加而争先恐后地扩展规模。

DevOps可以减少技术负担。 但前提是您必须严格遵守纪律。 而且只有当您从战术优化中抬起头来处理更大，更具战略意义的问题，然后才成为真正的问题。

翻译自: https://www.javacodegeeks.com/2015/06/does-devops-reduce-technical-debt-or-make-it-worse.html