在 2009 年第一届 DevOpsDays 上,《敏捷教练》的作者 Rachel Davies 作为第一届 DevOpsDays 上的第一位分享嘉宾。分享了在 BBC 采用用户故事跟踪非功能需求的经验。然而这一实践并不如 DevOps 的其它实践那样广泛。这个实践实际上很简单,就是把非功能需求做为用户故事的 AC 放入故事卡里。
在我过去实践 DevOps 的经历里,发现每次开始的时候都需要团队做同样的一些事情。而这些事情往往是和用户故事独立的,不能作为用户的一部分体现在工作量里。但这些事情又提升了团队之间的 DevOps 能力,于是,我把这一类的工作固化为 DevOps 故事用来落地 DevOps 实践,而且 DevOps 故事同样遵循并体现 CLAMS 原则的。
所谓 CLAMS 原则,指的是:
Culture(文化) Lean(精益) Automated (自动化) Measurement (度量) Sharing (分享/共担责任)
我把一个团队是否遵循 CLAMS 原则当做是否正确实践 DevOps 的标准之一。
DevOps 故事由 DevOps Epic (DevOps 史诗)和 DevOps Story (DevOps 故事)组成。和用户故事对应,DevOps 史诗故事可以依据具体情况的不同拆分成不同的 DevOps 故事。
而无论 DevOps 史诗 还是 DevOps 故事,都包含以下三个因素:
DevOps 史诗故事对于大部分组织来说是类似的,因为这些场景是 DevOps 的核心特征。也就是说,当你的团队完成了 DevOps 史诗故事。那么,你的团队就可以被称作是 DevOps 团队。
一个 DevOps 的史诗故事格式如下:
作为一个 DevOps 团队 应该采用<某一种 DevOps 实践> 团队中的Dev<应该如何做> 团队中的Ops<应该如何做> 得到<什么样的结果> 可以获得<什么益处>,从<某一度量指标>中得到。
举例1:持续部署流水线
作为一个 DevOps 的团队, 应该采用 持续部署流水线 团队中的 Dev 提交代码后 团队中的 QA 可以根据需要部署相应版本 团队中的 Ops 无需操作 就可以看到应用部署在生产环境上 可以 提升交付速度,通过部署时间度量 可以 提升反馈速度,通过部署频率度量 可以 节约 Ops 的部署时间,通过 Lead Time 度量
举例2:基础设施即代码
作为一个 DevOps 的团队,
应该采用 基础设施即代码
团队中的 Dev 用代码构建和生产环境开发环境
团队中的 Ops 需要通过代码和配置构建基础设施
就可以看到应用部署在生产环境上
可以 提升交付速度,通过部署时间度量
可以 提升反馈速度,通过部署频率度量
可以 节约时间,通过 Lead Time 度量
可以 减少人为变更失误次数和变更失败次数
以上的两个例子中,都包含了 DevOps 史诗故事的几个原则:
首先,DevOps 作为一个团队属性,放在第一行标识了出来。这是为了向团队强调 DevOps 的概念。
其次,需要注明 DevOps 所采用的最佳实践,在这里,最佳实践是不需要有具体的实施工具的。具体的实施工具要在 DevOps 故事里体现。
然后,下来的几行包含了各个角色要达成的效果,以及最终的效果。这里体现了 CLAMS 里 Culture 和 Share (分担)的原则。
最后,要标明 DevOps 史诗故事带来的益处以及度量方法。这里体现了 CLAMS 里的 Measurement 原则。
然而,仅仅有了 DevOps 史诗故事是没有办法落地的,我们还需要更加具体的 DevOps 故事来辅助。
DevOps 故事的原则要比 DevOps 史诗更加具体,并分成两种不同的故事。一种叫做“给 Dev 的 DevOps 故事”(DevOps Story for Dev),另一种叫做“给 Ops 的 DevOps 故事”(DevOps Story for Ops)。两者的格式相同, 但内容不同。
DevOps 故事的编写原则如下:
DevOps 故事的格式如下:
作为 DevOps 团队里的 <角色> 要实现 <某一 DevOps 史诗故事> 要采用 <什么工具> 完成 <什么事情> 对 <另一角色> 带来什么好处
例如,对于上文的持续部署流水线的 DevOps 史诗故事就可能会有以下几个 DevOps 故事组成:
DevOps 故事1:
作为 DevOps 团队里的 Ops 要实践持续部署流水线 我需要采用 Jenkins 作为持续集成服务器管理持续部署 让 Dev 提交的代码可以通过持续部署流程 让 QA 可以部署到测试环境上验证功能 验收条件:
DevOps 故事2:
作为 DevOps 团队里的 Ops 要实践持续部署流水线 我需要采用 Gitlab 作为代码仓库,提交代码。 让 Dev 可以提交代码。 验收条件:
DevOps 故事3 :
作为 DevOps 团队里的 Dev 要实践持续部署流水线 我需要用 git 提交代码并实现 单一主干发布分支 让 Ops 通过 Master 分支发布 让 Dev 在开发分支上开发 让 QA 可以选择对应的提交进行部署测试 验收条件:
通过以上三个 DevOps 故事,我们可以看出:完成一个 DevOps 史诗故事是需要不同角色的共同参与的,而且每个角色都能通过自己的 DevOps 故事让其它团队成员获益。此外,在以上三个 DevOps 故事中,都包含了 DevOps 故事的几个原则:
通过以上例子你可以感觉到,DevOps 故事实际上就是一个 DevOps 实践的落地说明。它采用 史诗故事确立了 DevOps 的文化和原则。有用具体的 故事 指导每个成员的技术实践。通过每日站会,我们在不断通过重复和强化每个人对 DevOps 文化和原则的认识。
有人曾经说文化无法落地和改变,这句话说对了一半。
作为 《DevOps Handbook》 的合著者之一,以及 DevOps 的早期布道者。 John Willis 的 “DevOps Culture(Part1)” 这篇文章里,引用了 一句话:
“You can’t directly change culture. But you can change behavior, and behavior becomes culture”
翻译过来就是:你无法直接改变文化,但是你可以改变行为,行为会演变成文化。
DevOps 故事就是通过类似于用户故事的方式将 DevOps 的相关行为可视化并落地的一个方法。这也给 Scrum Master 和敏捷教练一个指导团队落地 DevOps 的工具。
DevOps 故事源于我在学习用户故事(User Story)中受到的启发。而用户故事中最重要的原则就是,INVEST 原则,它们分别是以下六个单词的缩写:
Independent:独立的 Negotiable:可讨论的 Valuable:有价值的 Estimateable:可估计的 Small:小的 Testable:可测试的
DevOps 故事和 用户故事都满足 INVEST 原则。然而,这六个原则在 DevOps 的上下文里则需要一点补充和解释:
有些读者可能会发现 DevOps 故事有点像某些项目里的技术卡。但它们有以下几点不同:
DevOps 故事不同于非功能需求主要是面向用户不同:DevOps 故事是对于应用交付团队或者内部用户(Internal User)的。而非功能需求是针对于引用最终用户(End-User)的。因此,它们的关系也不一样。用户故事是应用功能的一部分。而 DevOps 故事是和应用功能无关的。
当你开始编写 DevOps 故事的时候,可能会出现一些问题,这不要紧。你需要编写 DevOps 故事之前,要牢记 CLAMS 原则。当你举棋不定时,团队是最好的答案来源,因为 DevOps 是关于团队本身,而不是终端用户的事情。不过当你开始咨询团队的意见之前,请和团队达成 CLAMS 原则的共识,在这样的共识之下,做出什么样的 DevOps 故事都会通过度量和反馈机制来衡量效果。
此外,DevOps 故事的 INVEST 原则也可以帮助你更好的实践 DevOps 故事。我采用 DevOps 故事作为落地 DevOps 的方法的时间和案例始终都很有限,还有更多未知的情况等待区处理。但我始终不忘用 CLAMS 原则去审视它。如果你发现有无法处理的状况,欢迎来信和我一起讨论,并形成新的 DevOps 实践。