这是在微软技术大会Ignite2015上听李智桦老师推荐的视频，说得是DevOps（开发运维一体化），旨在推动IT开发效率。

视频中的两个小伙来自Flickr，人家一天能发布十多个版本。这效率也真是让人醉了，开发运维搅在一起，也真是激情无限。做了点笔记（很久不用英语，听错了的请轻拍）：

##要点

1. 自动化基础
   • 角色／配置管理
     • 系统镜像？
2. 统一版本控制方式
   • 运维人员也需
   • 让所有人都知道该干什么
3. 一步编译／部署
   • 一个操作解决
   • 工具自动记录时间／任务／事情
   • 小而频繁地更改

4. 特征标记（分支）
   

   • 可以开发很多功能，完成之前不对外开放
   • 不同开发语言都有？

   • 水桶测试

     设想把编程看成是转动曲柄从井里提一桶水上来的过程。如果水桶比较小，那么仅需一个能自由转动的曲柄就可以了。如果水桶比较大而且装满水，那么还没等水桶全部被提上来你就会很累了。你需要一个防倒转的装置，以保证每转一次可以休息一会儿。水桶越重，防倒转的棘齿相距越近。 测试驱动开发中的测试程序就是防倒转装置上的棘齿。一旦我们的某个测试程序能工作了，你就知道，它从现在开始并且以后永远都可以工作了。相比于测试程序没有通过，你距离让所有的测试程序都工作又近了一步。现在我们的工作是让下一个测试程序工作，然后再下一个，就这样一直进行。分析表明，要编程解决的问题越难，每次测试所覆盖的范围就应该越小。

   • Dark Lauches
     简单说，就是开发新功能是要能使之方便地开启／关闭，可以很好应对突发事故。

5. 统一的度量标准

   • 开发人员可以看到运维情况（CPU/网络等情况）

6. 即时聊天工具／机器人

   • 远程办公
     • 开发／运维／机器人可以进行有情景地沟通，更好传达信息

文化

• 不要有偏见
• 尊重他人的工作／观点／技能
• 别隐藏东西

开发对运维说对代码的影响：

• 什么标注（CPU/网络…）会更改，怎么改？
• 风险是什么？
• 事情变糟糕的迹象时啥？
• 突发事件时啥？

信任

• 运维应该信任开发，邀其讨论需求
• 开发应该信任运维，与之讨论基础变更
• 每个人都应该相信其他人都在为工作努力

正确面对失败

如果你认为你可以避免失败，你就失去了锻炼应对失败的能力。