CD对开发过程的影响以及对发布的意义-2
前篇：http://leogao-java.iteye.com/blog/2155125
前者讨论了实际项目运行中的各种麻烦事情，相信有项目实践经验的也有感触。这里就不再多说各种折磨的故事了，因为太多了！关键我们如何解决它们！
软件开发的目的很明确，就是要满足客户或者最终用户的需要，但是软件公司需要赚钱，就要控制成本，增加它的价值，另一方面客户希望用最少的成本买到最好的软件和服务，所以最终就要求开发团队可以在一种高效、快速和可靠的方式交付高质量的有价值的软件！
实际上，N多组织都为此努力，但是都失败了，就像前者所说的折磨故事一般无二，不过也有不少成功的，仔细研究成功的案例，发现失败的项目基本是靠美其名曰的××方法论+PM的人治方针进行的，而成功的案例都是按某某项目实施机制的法制下进行的，而PM起得作用则是集中在解决需要人治的方面！
这个实施机制是什么哪？就是三点：
1）自动化：如果构建、测试、部署和发布流程不是自动化的，那么它就很难重复去做，因为每次都是人工去做，每次都可能产生结果的差异，就不知道那一次是最最准确的！人工去做，每次或多或少会引入不可预期的错误，而一旦一个人离去，接收的人有按自己的方式去作（人治），可想而知这样的方式会有多么混乱而不可控制！如果这个过程完全自动化，那么就不会出错，消除人治的因素，一旦出问题，自动化管线马上报告问题所在，由于我们可以一键就可以执行整个过程，不管什么环境都是一样。
2）频繁去做：如能做到频繁的发布，那么每个版本之间的差异就会很小了，这就大大减少了发布的风险，因为一旦出现问题，就能快速回滚到上一个良好的版本，每次提交代码都会自动激发自动化构建、测试、部署以及发布的流程，及时给予反馈，一小步一小步滴演进系统，系统的开发状况透明度增强，可视化程度高，那么团队对开发过程的掌控能力就高，能够及时修改问题所在。
以上的办法，不是轻易能够办到的，要是那么容易，所有组织都成了啊！这是因为自动化除了需要在技术上要有保证，在制度上也要有保证，最难最难的是需要团队每个人了解其含义和具体做法（技术好做，人事不好做）。自动化是频繁作的基础，而可以频繁作的话，自动化系统反馈报表也产出的快，反馈的快，我们就能及时修复问题，那么进度就在掌控之中了！
3）做好测试脚本，测试驱动开发，可以解决测试覆盖率和可以快速反馈的问题以及尽早发现实现业务机能的问题（具体的后面文章会有讲到）
下面我用一个图说明自动化的含义，因为自动化被很多人误解，所以先要破除某种误解。误解就是认为它是一种技术手段，但实际上它是一种实践过程！
说白了，就是实施一种从源代码提交到部署的全过程的自动化，如能实现自动化，那么无论何人都可以简单
实现部署和测试，不需要一个团队来负责，另外过去那种反复的手工被消除了，回归测试变成了不可思议的简单事情，那么就能支持频繁的提交和快速的反馈，如得到了快速反馈就能在短时间内修复问题，一步一步的演进系统，对系统有十足的操控力，那么对系统可运行的信心就越来越强！而且我们定义所有环境的部署配置脚本都是一样的，一致的，因为你在开发过程中就已经频繁的提交=》频繁的执行自动化部署脚本，就能逐渐优化部署脚本，等到真实发布时，您已经测试它千百遍了，这些难道不比传统方式更有革命性吗！
1) 整个自动化过程分成几个阶段（每个阶段都对应一种服务器环境，后面会有说明）：
提交阶段=》验收阶段=》功能和非功能测试阶段（UAT+非功能测试）=》部署阶段
为什么分成阶段？因为一个需要开发的软件要满足很多方面利益相关者的要求或者利益，那么提交阶段是
验证技术角度来测试系统，验证阶段还是从技术角度验证，但是重点是组件之间的集成，UAT阶段是验证
开发的软件是否完全满足业务需要，而非功能测试阶段，主要是测试一些隐性要求（比如容量、安全和性
能等等），生产环境部署阶段，它重点是验证在生产环境上是否可用。
2）每个阶段或几个阶段对应一种环境：
提交阶段对应开发测试环境
验收阶段对应Alpha测试环境
UAT和非功能测试阶段对应Beta环境
部署阶段对应生产环境
最好的设计，如条件上允许，开发测试环境、Alpha测试环境、beta环境的配置最好与生产环境相近，如能
作到一致就更加好了，因为只有接近或者一致，才能在开发阶段就尽可能滴发现各种隐藏的问题，比如和
环境相关的问题。那么就在早期发现了更多的问题，我们想想越是到后期，问题就越少了啊！
3）将所有的东西（除了二进制包）都放入版本控制系统之内，这是基础！（后面的文件会逐渐详细讨论），将提交阶段形成的二进制包与具体环境配置文件分离，二进制包与环境是独立的，配置信息都是放置在版本控制系统之中的（为什么这样作，之后会有详细讨论），最后必须保证整个自动化过程中，这个二进制包必须是同一个！如作成这些，基本可以消除由于配置混乱带来的问题（后面章节会有详细讨论）。
4）如果测试脚本覆盖率不够，那么潜在的问题很可能就被过滤过去了，到了部署阶段的话，出了问题，就需要不少时间去修正！保证测试覆盖率的手段有两个：覆盖率分析工具或者使用测试驱动的开发方法保证覆盖率。
5）要有纪律性！如没有纪律规定，那么1-4的自动化流程就形同虚设了，这是因为，如果自动化集成工具发现某个测试没有通过，并发出反馈，而开发人员还是像传统方式那样不管而是留到测试阶段去修正，因为时间间隔较长，修改成本就越高，简直和传统方式没有两样，越是这样，项目的可控程度越来越差，直到不可控制的程度，所以必须建立谁的bug谁就要及时修正的纪律。
对于1-5, 频繁的提交=》测试=》反馈和修复，让项目快速前进，一切都在掌握之中（达到这一点需要很多努力的，之后章节会有讨论的），是不是可以在时间区间内完成开发任务哪？质量、时间和成本都能得到期望的平衡状态！
6）开发测试环境需要Mock Server,因为一个开发中的系统可能依赖外部系统，而这些系统可能也在开发之中，如果依赖的系统不可用，我们怎么确认我们自己的软件没有问题，所以需要Mock Server来模拟外部依赖系统提供的服务，也使得各个系统不必互相等待进度，各开发各的。（有关Mock Server的话题后面会有讨论)，由于各个系统依赖带来的等待时间大大减少了，成本也大大减少了！
7) 最重要的，就把客户代表（Product Owner)、测试人员、部署人员以及运维人员在项目一开始就把他们拉进来，必须拉进来。拉他们进来，很有意义，那就是一起优化所有的流程，比如作测试脚本时，测试人员最专业，因为我们不断的在各种环境中部署，也让在项目一开始就不断的参与到优化部署脚本的开发当中，由于不断的快速提交和反馈，运维人员可以尽早滴参与到优化系统上的运维方案优化，而由于快速的反馈，客户代表也能在最短时间内纠正需求上的问题，也就是说，如果到了项目后期，项目的方方面面都接近质量目标了，大家就会大有信心进行发布了！而且不会发生由于沟通问题、配合问题所产生的争论以及后期各种问题的出现，组织内的知识传递也是透明的，沟通成本大大降低！
下一篇会继续逐渐展开讨论自动化的细节，逐渐进入技术实现手段的章节。
参考：http://www.continuousdelivery.info/