研发推动的 DevOps

开发负责人和测试负责人沟通以后，总结了让他们痛苦的事情，如何解决？

• 估算不准确、临时插入事情多、项目计划很难做；
• 到了计划的测试时间点，开发人员还没有联调完，无包可测；
• 当有软件包可测的时候，测试人员却被调去测试其他项目了；
• 好不容易有测试人员了，一测试就发现很多低级问题，可能都启动不了；
• 没法继续测下去，还要打回给开发，继续修复；
• 测试环境和测试数据的准备要耗费很长时间；
• 测试时需要将线上环境的一些配置同步下来，因为那才是最可靠的环境；
• 反反复复提测好几次，手工重复测试真是受不了；
• 终于可以准备上线发布了，还要排队等待；
• 当轮到自己的项目上线了，还要把前面已经上线的代码拉取合并，再测试；
• 假如前面上线项目出了问题要回滚，我们还要把代码剥离出去，再打包，再测试；
• 写了一大堆上线文档，交给运维人员，运维人员说不符合运维规范，要重新修改；
• 运维人员终于可以部署了。可是，刚部署上去，就出问题，原来是把配置文件搞错了；
• ...

改进目标包括 短期目标 和 中期目标 。

短期目标如下：

1. 项目近预期时间交付。
2. 创建新的软件研发协作方式。
3. 建立必要的基础设施，以支持后续的持续发布模式。

中期目标如下：

1. 缩短发布周期，可以快速上线。
2. 不降低生产环境的质量。
3. 降低测试人力总投入。

这两个目标分别对应两个实施阶段。

第一阶段是以持续集成牵引的“敏捷101”，顺利完成一次发布，并为后续的持续发布奠定流程与工具基础。

第二阶段是向 DevOps 工作模式转型的持续发布之旅。