什么是devops开发运维

DevOps的定义，由Donovan Brown提供 是“ 人员 ， 流程和产品的结合，以实现向客户不断交付价值 。 ”它强调了持续交付价值的重要性。 让我们讨论一下实验是现代开发实践的核心。

回顾过去

在进行假设驱动的开发之前，让我们快速回顾一下如何使用瀑布式，敏捷性，部署环和功能标记来交付价值。

在瀑布时代 ，我们得到了可预测的，流程驱动的交付。 但是，我们只是在开发生命周期的末期才交付价值，通常会因为解决方案偏离原始要求而失败，或者我们的杀手级功能在最终交付时就已经过时了。

在这里，我们有一个X版本和八个功能，所有这些功能都已部署并公开给耐心等待的用户。 我们一直在不断创造价值，但是随着发布时间的延长（通常为六个月到两年）， 这些功能的价值随着世界的发展而下降 。 当有计划时间并且对更紧急的需求做出较低的期望时，它就足够好了。

敏捷的引入使我们能够创建并响应变化，因此我们可以不断交付有效的软件，感知，学习和响应。

现在，我们有三个版本：X.1，X.2和X.3。 在X.1版本之后，我们基于反馈改进了功能3，并在X.3版本中对其进行了重新部署。 这是一个简单的示例，该示例提供了更多功能，专注于工作软件并响应用户反馈。 我们正在持续交付的道路上，专注于我们的主要利益相关者：我们的用户。

使用部署环和/或功能标志 ，我们可以将发布部署和功能暴露分离到各个用户，以控制功能的暴露（爆炸半径）。 我们可以进行实验； 逐步公开，测试，启用和隐藏功能； 微调版本，并持续以学习和反馈为中心。

当我们将功能标记添加到以前的工作流程时，我们可以将功能切换为启用（启用和公开）或禁用（隐藏）。

此处，功能2、4和8的功能标志为OFF，这会使用户接触较少的功能。 所有功能均已部署，但尚未公开。 部署到生产环境后，我们可以微调每个版本的功能（价值）。

当我们通过观察逐步部署和评估一个或多个功能时， 基于环的部署限制了对用户的冲击（爆炸）。 环使我们能够逐步部署功能，并具有多个并行运行的版本（v1，v1.1和v1.2）。

在金丝雀和早期采用者环中公开要素，使我们能够评估要素，而不必担心全盘部署或全无部署。

功能标志将发布部署和功能暴露脱钩。 您“翻转标志”以显示新功能，通过重置标志执行紧急回滚，使用规则隐藏功能以及允许用户切换预览功能。

当结合部署环和功能标志时，可以通过环逐步部署发行版，并使用功能标志来微调已部署的发行版。

请参阅部署新版本：功能标记或功能环 ， 功能标记 的成本是多少 ，以及在人员，流程和产品之间打破壁垒，以进行有关功能标记，部署环和相关主题的讨论。

将假设驱动的开发添加到组合中

假设驱动的开发基于一系列实验，以验证或反证在未知问题未知的复杂问题域中的假设。 我们想找到可行的想法或失败很快。 我们没有开发整体解决方案并进行大规模发布，而是通过假设进行了迭代，评估功能部件的性能，最重要的是，客户如何以及是否使用它们。

模板： 我们相信 {客户/业务部门} 想要 {产品/功能/服务} 是因为 {价值主张}。

示例： 我们认为用户希望能够选择不同的主题， 因为这将提高用户满意度。 我们希望50％或更多的用户选择一个非默认主题，并增加5％的用户参与度。

每个实验都必须基于假设，得出可衡量的结论，并有助于功能和整体产品学习。 对于每个实验，请考虑以下步骤：

• 观察您的用户
• 定义假设和实验以评估假设
• 定义明确的成功标准（例如，用户参与度提高5％）
• 运行实验
• 评估结果并接受或拒绝假设
• 重复

让我们再看一下具有八个假设功能的示例发行版。

部署每个功能时，我们可以观察用户的行为和反馈，并证明或反驳促成部署的假设。 如您所见，功能2和功能6的实验失败了，这使我们能够快速失败并从解决方案中删除它们。 我们不想携带无法带来价值或无法使用户满意的废物！ 功能3的实验尚无定论，因此我们在X.2版中调整功能，重复实验并执行A / B测试。 根据观察，我们将变体功能3.2确定为获胜者，并在X.3版中对其进行重新部署。 我们仅公开通过实验并满足用户需求的功能。

假设驱动的发展点亮了渐进式曝光

当我们将假设驱动的开发与渐进式风险暴露策略相结合时，我们可以垂直分割我们的解决方案，逐步实现我们的长期愿景。 在每个切片中，我们逐步展示实验，启用使我们的用户感到高兴的功能并隐藏那些未完成的功能。

但是还有更多。 当我们接受假设驱动的开发时，我们可以了解技术如何协同工作或不协同工作，以及我们的客户需要和想要的东西。 我们还补充了测试驱动开发（TDD）原则。 TDD鼓励我们首先编写测试（假设），然后确认我们的功能正确（实验），然后通过测试（评估）成功或失败。 正如 《 敏捷宣言》的 原则1、3和7所述， 这一切都是关于质量和使我们的用户感到满意的 ：

• 我们最优先考虑的是通过及早和持续交付价值来满足客户。
• 经常交付软件（从几周到几个月不等），并且倾向于较短的时间范围。
• 工作软件是进度的主要衡量标准。

更重要的是，我们引入了一种新的思维方式，打破了开发，业务和运营之间的壁垒，可以通过一系列迭代实验，采用基于科学分析，用户行为，和生产中的反馈。 通过在生产过程中的观察和学习，我们可以在细粒度中发展我们的解决方案，这是航空航天或土木工程等其他工程学科只能梦can以求的奢侈品。

好消息是，假设驱动的发展支持经验过程理论及其三个Struts： 透明度 ， 检验和适应 。

但是还有更多。 根据精益原则，我们必须在测量和检查反馈后坚持或坚持不懈。 通过将特征切换与假设驱动的开发结合使用，我们获得了两全其美的优势，并且能够使用A | B测试对反馈（如喜欢/不喜欢和价值/浪费）做出决策。

记得：

假设驱动的发展：

• 关于确认或否定假设的一系列实验。 识别价值！
• 得出可衡量的结论并能够继续学习。
• 允许关键利益相关者（即用户）不断反馈，以了解未知/未知！
• 使我们能够了解不断演变的价值演变格局。

渐进式曝光：

• 不能隐藏未准备就绪的代码。 始终保证质量！
• 关于通过生产中的环部署功能发布。 限制爆炸半径！
• 关于启用或禁用生产中的功能。 微调释放值！
• 依靠断路器来保护基础架构免受逐步暴露的影响。 观察，感知，行动！

您从渐进式暴露策略和假设驱动的发展中学到了什么？ 我们期待您的坦诚反馈。

翻译自: https://opensource.com/article/19/6/why-hypothesis-driven-development-devops

什么是devops开发运维