团队的发布过程
设置 DevOps 做法的第一步就是评估你的现有过程。 这意味着要分析：
- 你的现有生成工件（如部署包和 NuGet）以及容器存储库。
- 你的现有测试管理工具。
- 你的现有工作管理工具。
- 推荐的迁移和集成策略。
和 Tailspin 团队一起执行该操作，并了解 DevOps 如何提供帮助。
待产品经理 Irwin 离开后，Amita 说道：“我们需要帮助。 我不知道这些修补程序什么时候到期，但我知道快了。 我们还没有准备好迎接一个快速的转变。 此外，新的 Space Game 网站必须等到我们解决了这个烂摊子才会推出 - 这款游戏很快便会上市。”
Andy 看着 Mara。 “最初这几周你要学的东西很多。”
“没问题，”Mara 回答道。 “或许你能给我讲一讲这里的情况。 游戏是如何从开发转到生产的？”
“这是一个好问题，”Andy 说。 “我不确定我们能否给出一个简单明了的回答，但我们尽力为之。”
团队决定去咖啡店休息，并进行一场非正式讨论。 同时，他们还试图找出存在这么多问题的症结所在。
喝咖啡期间，Mara 认真倾听并努力记着笔记。 信息很多，但没有条理。 关于这个团队，她的总体看法就是：
- 他们使用瀑布式方法。 管理人员设置事项的优先级。 开发人员编写代码，并将该生成提交给 QA。 QA 测试，然后移交给操作人员来部署。
- 瀑布式方法也许对小型团队有用，但在这里，团队目标有时并不清晰，而且似乎经常改变。
- 测试总是延迟到过程的后期。 这意味着修复 bug 并进行更改更加困难且代价更加昂贵。
- 对“工作完成”没有明确的定义。 每个团队成员都有自己的想法。 没有一个所有成员都想达到的整体业务目标。
- 有些代码放在集中式版本控制系统中。 许多工具和脚本仅存在于网络文件共享上。
- 手动过程太多。
- 通信没有计划性，且依赖于电子邮件、Word 文档和电子表格。
- 反馈也很少，而且不一致。
- 从好的方面看，这个团队似乎相处和睦，并且他们想把事情做得更好。
看着这堆笔记，Mara 知道她需要整理所有这些信息。 理清它们将使评估该过程变得更加轻松。 她确信 DevOps 方法将解决这个团队的很多问题，但她需要一种向团队展示自己观点的方式。
DevOps 做法通常是从了解现有过程开始。 在此期间，就可以评估哪些是有用的，哪些没用，然后把注意力集中到那些需要首先修复的问题上来。
Mara 问道，“你们有人完成过值流映射练习吗？”
Andy 翻了个白眼，Amita 叹气，Tim 说道，“我们不需要额外的文书工作了。”
Mara 说：“我知道了。 那就交给我来做吧。”
大家都乐于让新人来处理这件事，于是都回去工作了。