2017 DevOps 现状调查报告（官方中文版）
http://www.idcos.com/download/devops-report
读书总结：
如今 DevOps 实践已深入人心，成为一种企业文化。帮助企业提高应用部署效率、保证系统的质量与安全、快速适应市场。
DevOps 有助于提升 IT 效能，帮助企业提高生产率、增加利润、扩大市场份额。
高效的领导该如何影响技术实践及流程的改善，从而提升 IT 及组织的效能？
自动化是企业的核心竞争力。
综述：
1. 良好的建设性沟通能力、善于鼓励与启发及个人魅力，这些领导特质与 IT 的效能有密切关系。高效能团队其领导层均具备上述特质。相反低效能团队的领导层则缺乏这些方面的能力。
2. 不同效能团队的发布频率，发布延迟等指标上的差距在缩减。但低效能团队的故障恢复时间及发布失败率却有所上升。其原因是随着发布频率的提升，对构建的质量控制放松了。
3. 高效能团队在配置管理、测试、发布和审批流程等的自动化程度上，明显优于其他团队；进而高效能团队有更多的时间用于创新及快速响应市场。
4. 为达成 IT 的高效能，请采用松耦合服务架构，即服务可以独立开发与部署；以及松耦合的团队，随时准备进行变更。达成上述变化需要传统企业进行巨大投入。松耦合架构的好处是： 更高的业绩，质量和稳定性。
5. 精益产品管理实践帮助团队交付符合市场需求的产品，以及更短的交付周期。快速交付让研发团队与客户的联系更紧密。 其结果是，整个组织的盈利水平，生产率和市场份额的提升。
领导力：
领导力对企业有重大影响。好的管理者能够带领团队发布高质量代码、构建高质量系统、在产品研发中应用精益原则。上述能力对企业的盈利能力、生产率和市场份额有直接影响。对不以盈利作为衡量标准的组织和政府机构而言，领导能力的高低关系到客户满意度、组织效率及组织愿景的达成。
领导力如何帮助企业提升效能是 DevOps 实践中很容易被忽视的地方。领导力在如下任务中是必不可少的：
- 营造与鼓励互相信任的文化氛围
- 通过技术手段提升生产效率，缩减部署延迟， 提升可靠性
- 支持团队创新，更快更好的发布产品
- 打破部门界限，认同组织愿景
DevOps 社区内部对管理层往往缺乏认同，例如，中层管理者有时会阻碍提升 IT 与组织效率方面的变革。一个经常被问到的问题是，如何能让管理层支持我们进行变革和改进？ 所有人都同意管理层的支持是成功实践DevOps 的必要条件。大规模变革所需要的预算与流程必须经过管理层的批准。变革中若遇到障碍，团队需要管理层的支持和鼓励。管理层负责设定组织的基调与文化。
领导力的五个象限：
但是好的领导力并不等同于 DevOps 的成功。在领导力排名前 10% 的组织中，DevOps 的成效有好有坏。因为DevOps 的成功不仅仅取决于领导力，而是包含合理的组织架构、好的技术实践、遵循精益管理原则等等诸多因素。
中等效能团队的实施自动化过程中的阵痛：
中等效能团队实施自动化过程中的重做与手工操作的增加只是暂时现象。通过实施自动化，团队收到实际成效的同时，也遇到大量的技术债，妨碍 DevOps 和自动化的推进。我们建议团队不要追求对自动化过程的过度控制，而是逐步从审批委员会形态转为研发周期中常见的代码评审及测试自动化等技术手段。最终变更审批委员会这一组织形态会消失，被更快同时也是更可靠的审批流程取而代之。技术债的消解完成后，团队就可以在自动化和 DevOps 的实践中更进一步了。
DevOps技术实践：
DevOps 帮助更快的部署软件、提升团队效率、保持组织的竞争优势。打算实施 DevOps 的组织往往从购买相应的 DevOps 软件开始，但更重要的则是遵循 DevOps相关的技术实践。我们的问卷报告深入考察了这些技术实践，包括版本控制、持续集成、基于主干的开发模式、及自动化等。今年的问卷增加了系统构架及组织结构方面的实践内容，包括他们对软件研发及部署效率的影响。
持续交付：
成功实施持续交付的技术实践包括： 完备的代码控制、持续集成、基于主干的开发，在研发中引入安全合规、实施测试与部署自动化。当然，测试自动化最为关键。
持续交付成功的关键（其重要性超过自动化测试与部署），在于团队是否做到如下几点：
- 实施大规模变更不需要来自团队之外的人审批
- 实施大规模变更不依赖于其他团队所负责系统的 变更，也不会给其他团队增加额外的工作量
- 不需要与其他团队进行细节上的沟通
- 按需变更，不依赖其他服务的更新，也不影响依 赖本服务的系统
- 可无须集成测试环境完成大部分测试
- 在业务时间完成部署，不影响业务连续性
基于主干的开发：
报告考察了基于主干的开发模式对持续交付的影响。研究表明高效能团队选择工作在小的代码分支并及时合并到主分支，而不是保留众多的特性分支。如下实践有助于提升软件交付效率：
- 每天将代码合并到主分支（Trunk 或 Master）
- 缩短分支及 fork 的存活周期（短于一天）
- 只维护少于三个活跃分支
无需引入代码锁定期的团队具有更高的发布效率（上述列举的实践有助于避免代码锁定）。
虽然基于主干的开发有提升软件部署效率，部分习惯采用“Github 推荐开发流程”的开发人员对此表示怀疑。“Github推荐开发流程”建议基于分支进行开发，只是周期性的合并到主干。工作在短的分支，并每天合并到主干是持续发布的最佳实践之一。基于分支的开发，在分支寿命足够短的情况下，也是高效的。问题是“短”具体指的是多长时间？
今年的问卷我们专门分析了采用主干开发策略和分支开发策略的效率区别。考察点包括分支或 fork 在被合并到 master 之前的存活时间，分支合并的时间开销，以及不同效能组织分支策略的区别，以下是我们的发现：
- 高效能团队具有较短的合并耗时和分支存活时间，均为数小时
- 低效能团队具有较长的合并耗时和分支存活时间，为数天
该问卷揭示高效能团队具有较短的分支存活时间与分支合并耗时。历年问卷都揭示了同样的最佳实践：避免分支的存活周期超过一天。如果分支合并和整合的耗时超过一天，这就是告警信息，提醒团队重新审视系统架构与分支策略。
收集客户反馈：
敏捷方法的目标之一是将客户需求贯穿于整个研发周期中，甚至产品还在早期设计阶段。这使得研发团队能够获取重要的客户反馈并应用到设计中。如果研发团队不允许根据所收集到的客户反馈更新规范或需求，或者这样变更需要通过外部审批，团队的创新力会被极大的消减。
工具类项目和战略类项目的区分：
理解工具类项目和战略类项目的分别，并区别对待。Martin Fowler 提出的区分原则是：其功能是否为组织核心竞争力。如果答案是否定的，可以考虑购买市面上的商业软件而不是自行开发。一个经常犯的错误是将工具类需求误以为是战略需求，化大力气开发或订制，而不是主动调整自己的业务流程去适应成熟的商用系统。
错误的将工具类需求视为战略需求会导致严重后果，包括花费大量精力订制类一个难以维护，测试，升级改造的黑箱系统，该系统无法纳入到自动测试，自动发布和维护的服务生命周期中，而自动化是 DevOps 实践的核心。与其对商用系统进行耗费巨大定制，不如调整自身的业务流程去适应系统，将其作为业务流程优化的一部分。在许多情况下，这比定制的代价小很多。任何情况下，定期重新审视企业流程都是有益的。
上述实践可能与研发组织不轻易接受第三方开发软件的传统相违，许多工程师都认为：我们做得更好。但是，贯彻这一实践能够让精力和智慧都集中在创造具有竞争力的产品上，让企业立于不败之地。