研发效能-加速

前言

实现DevOps最困难的部分是与管理层交流，转变他们的思想
管理层习惯于询问如下问题：
1-实施这个方案的成本是多少？
2-实施这个方案后我们能收益多少？
从管理者的角度来看，这些都是很合理的问题
但是在DevOps的世界中，如果在错误的时间以错误的方式回答这些问题
那么这些问题对于组织而言可能是有害的，并可能导致产生大量的预备工作
本文将介绍一些指标，这些指标可以使开发者与管理层的讨论不再局限于努力提高工程效率和开发者生产力
注意：
本文尽量保持用词与开发模式无关
见过采用DevOps实践的企业
包括敏捷模型、Scrum模型、规模化敏捷框架(SAFe)、看板和瀑布法等
但每个系统都有自己的术语，我尽量保持中立
例如，本文使用”需求”，而不是”用户故事”或”产品待办事项”
但本文使用的大多数示例都是基于Scrum的

工程效率-工作量

企业是如何衡量开发者效率的？
最常见的方法是通过工作量来衡量
曾经有一些企业使用诸如代码行数或代码测试覆盖率之类的度量标准
但这些显然是不好的选择，不知道现在还有哪些企业在这么做
如果可以通过1行代码或100行代码解决一个问题，那么1行显然更可取
因为每一行代码都有维护成本，代码测试覆盖率也是如此
覆盖率本身并没有说明测试的质量，而且糟糕的测试还会带来额外的维护成本

工程效率-无须评估

评估并不是一件坏事，如果应用在正确的场合，它会很有价值
如果开发团队和产品经理讨论下一个用户故事，评估可以有助于推动交流
例如，如果团队使用“扑克规划”评估用户故事但是评估结果不一致，表明人们对如何实现它有不同的想法
这可能引发有价值的讨论，并可能更有成效，因为可以跳过一些具有共识的讨论
对于业务价值来说也是如此
如果团队不理解为什么产品经理分配了一个非常高或者非常低的估计数字，这也可能引起重要的讨论
但是很多团队在完全不评估需求的情况下会感觉更合适
特别是在高度实践化的环境中，评估通常被认为是浪费时间的行为
远程和分布式团队通常也不喜欢进行评估
他们经常会进行面对面的会议或发起关于问题和Pull Request的讨论
这有助于记录交流过程，并帮助团队以更异步的方式工作
这也有利于跨越不同时区的开发者进行协作
不讨论开发者开发效率的情况下，开发团队应该被允许自行决定是否需要进行评估

部署到任何平台

CI/CD
CI意味着每次把代码修改推送到存储库时，代码都会被构建和测试，输出打包成一个构建工件
在CD中，每当创建一个新的构建工件时，会自动将该工件部署到指定环境中
当执行CI/CD时，开发和交付阶段是完全自动化的，代码随时准备好部署到生产环境
分阶段部署
阶段或层是部署和执行软件的环境
典型的阶段包括开发、测试、暂存(或预生产)和生产
通常，暂存(或预生产)阶段是生产环境的完全镜像，有时它用于通过使用负载均衡切换两个环境的零停机部署
而接近生产的阶段需要手动批准才能部署
如果一个企业使用功能标志和CD，则阶段的数量会减少

功能标记

功能标记(Feature Flag)是一种软件开发技术，允许在不改变代码的情况下修改运行时行为
是一种条件性编码工具，它允许在不部署新代码的情况下启用或禁用软件功能
它把最终用户功能的发布与二进制文件的推出分离开来
功能标记的工作原理类似于开关或切换，由于具有布尔性质，因此通常被称为功能切换或功能开关
但是功能标记可以有许多不同的用例，并且可能比开关更复杂，因此功能标记这个术语更加适合
功能标记允许开发者把新代码封装在功能标记后，将其推出到生产系统，然后可以根据给定目标受众的上下文启用该功能
对开发者来说，如果具有持续交付和负责基础架构的独立团队
功能标记是一种非常地道实用的技术
将标记添加到代码比更改基础架构更容易，因此开发者通常会使用标记允许测试人员执行与普通用户不同的操作
或者允许某些测试版用户测试某些内容
如果没有明确指定功能标记，配置通常会分散在不同的位置(配置文件、组成员身份和应用程序数据库)
明确使用功能标记有助于提高团队的透明度，并确保方法统一，可以启用更高级别的用例并确保安全性和可扩展性
这种将代码部署与功能激活分离的做法带来了诸多好处
如在生产环境中更有效地进行测试、分阶段推出新功能、迅速回滚更新以及提供定制化的用户体验
功能标记代表了一种从传统、固定的发布流程向更加灵活、可控制的策略的转变
随着 DevOps 的兴起，功能标记的发展与对敏捷和更少干扰的发布机制的需求相吻合，特别是在分布式系统中
通过功能标记，可以将新代码以休眠状态加入到生产环境中，在适当的条件下激活
从而最小化大规模部署和潜在的系统中断风险
部分使用案例：
0-发布标记
这些标记用于在标记后发布代码
发布标记通常在功能完全发布之前保留在代码中，可能需要保留数周或数月的时间
发布标记可以随着每个部署或系统配置的更改而变化
可以与金丝雀发布(Canary release)(逐渐向更多用户暴露该功能)或蓝绿部署(blue-greendeployment)(交换缓存和生产环境)一起使用
1-实验标记
如果开发者发布多个版本的同一功能并将其暴露给不同的受众，称为A/B测试或实验
实验标记通常用于通过测量用户如何与功能版本交互的某些指标来确认或排除假设
实验标记高度动态，并依赖于许多上下文来使用它们以针对不同的目标受众
2-权限标记
功能标记的一个常见用例是控制用户可以访问的内容
这可以是仅向特定受众暴露的管理功能或测试功能
或仅向付费客户暴露的高级功能
3-操作标记
有些标记用于应用程序的运营方面
例如用于禁用某些功能的故障开关(也称为断路器)
这些功能可能会成为其他功能的瓶颈
控制后端系统不同版本的标记也被认为是操作标记
4-简化的分支策略
功能标记和基于主干的开发往往是相辅相成的
因为不同的开发人员可在同一个分支上开发不同的功能
并通过启用或关闭特定功能来避免出现冲突的变更
这种简化的分支策略可有效避免以下情况发生：
即个别开发人员在独立的分支中工作，并且没有足够频繁地集成他们的更改，从而可能导致不必要的代码发布延迟
它还允许持续交付代码，因为开发团队可以轻松关闭不完善的功能，直至功能完善为止
5-持续部署
通过使用功能标记，开发团队可以使用安全的方式更快捷地为用户部署软件
功能标记是持续部署流程的关键组件
代码发布与代码部署是分开进行的
也就是说，代码可以逐步进行发布，如果发现缺陷就立即关闭功能标记
修复后再重新启用，从而确保不会影响代码部署周期
6-降低风险
因为功能缺陷造成问题？仅需关闭功能标记即可
这在测试期间很有帮助，必要时，可以通过快速关闭功能标记来减少该类问题所造成的影响
因为系统性能造成问题？
只需在一段时间内关闭不太重要的功能，直到该系统性能问题得到解决
担心如何接收新功能或修改过的功能？
只需为一小部分用户提供此类功能，并征求他们的反馈意见