最佳实践之持续集成篇

最佳实践之持续集成篇 我们目前希望是通过加强测试来提升代码质量，这是 SQA 的一个 常用的也是立竿见影的措施。如果真正要从本质上提升软件的质量的 话，我觉得测试驱动和持续集成这 2个 best practice 缺一不可。 我们目前的项目基本是采用阶段集成的方式，我觉得一个小型的 项目，几十个类的项目，采用阶段式的集成方式或许是最佳的方式， 如果走运的话能顺利的一次集成出一个版本，如果运气不好的话，反 复多次也不会带来多少损失。但对于我们目前的核心系统来讲，如果 再使用这种过程黑盒不可见的阶段集成方式，到了发布计划前用很长 的周期去集成出一个版本，并且由于程序的问题反反复复集成多次， 上线后也无法确保版本的可用性的话，那么就到了必须进行持续集成 的地步了。事实是我们目前的核心项目或多或少都有这个问题在频繁 发生。 为什么要做持续集成？  易于定位错误。也就是当你的持续集成失败了，说明你新加的代 码或者修改的代码引起了错误，这样你很容易的就可以知道到底 是谁犯了错误，可以找谁来讨论。  及早在项目里取得系统级的成果。因为代码已经被集成起来了， 所以即使整个系统还不是那么可用，但至少你和你的团队都已经 可以看到它已经在那了。  改善对进度的控制。这点非常明显，如果每天都在集成，当然每 天都可以看到哪些功能可以使用，哪些功能还没有实现。如果你 是程序员，你不用在汇报任务的时候说我完成了多少百分比而烦 恼，而如果你是项目经理的话，那么你也不再烦恼程序员说完成 了编码的 50%到底是个什么概念。  改善客户关系。理由同上。  更加充分地测试系统中的各个单元。这也是我们常讲的 Daily Build 与 Smoke Test 相结合带来的绝大好处。  能在更短的时间里建造整个系统。持续集成并不会为每个项目都 缩短时间，但却比没有实施时，项目更加可控，也更加有保证。  有助于项目的开发数据的收集。比如说，项目代码量的变化，经 常出错的 Tests，经常出错的 source code 等等。  与其它工具结合的持续代码质量改进。如与 CheckStyle, PMD, FindBugs, Fxcop 等等静态代码标准检查工具的结合。  与测试工具或者框架结合的持续测试。如与 xUnit，SilkTest, LoadRunner 等等的结合。  便于 Code Review。在每个 build 里，我们都可以知道与前一个 build 之间有什么改动，然后针对这些改动，我们就可以实施 Code Review 了。  便于开发流程的管理。比如说，要把一个开发的 build 提交给测 试组作测试，测完满意了，再提交到发布组去发布。 如何做持续集成？ 持续集成有很多很多的好处。可是持续集成要做好的话，本身就 有很多的讲究。从持续集成工具的选择到持续集成具体实施，每一点 都可能影响到你使用持续集成的效果。 持续集成绝不是持续编译，这是 80%以上的人对 CI肤浅的理解！ 首先需要有一个合适的持续集成工具，这个工具需要满足：  便于公司的统一管理（大约有 20+ Projects 需要统一管理） 对于项目本身进行流程管理: Daily Build -> QA Build -> Integration Build -> Release Build。 所谓 Daily Build，顾名思义，就是每天一次的，由 development team 管理以保证项目的顺畅执行，然后经过一段时间后，development team 要提交到 QA 那边进行测试，通常是 2个星期到一个月左右，随 项目大小不等，QA 测试结束之后，如果没有重大的问题，则提交作 Integration Test，以保证在模拟的实际环境中能正常工作，最后， 如果没有什么问题的话则作 Release Build 以形成发布版本。  对 Continuous Testing 的支持，即对于项目的 Test 要能产生出 详尽的以及收集 Test 的统计数据以作为项目的分析和考量  对 Continuous Code Quality Analysis 的支持，即能处理项目产 生的 Coverage 报告，Code 的 static analysis 报告，并且能收 集这些报告的统计数据以作项目的分析和考量  与 SCM 工具的集成，如 Subversion。  与 Jira 的集成。 除了选择一个合适的ＣＩ工具之外，还需要标准过程，我的设想 如下： 首先，我们对编码有一些需要遵从，所以我们需要制定一系 列的 FindBugs 和 PMD 的规则用于检查代码。 其次，我们需要使用一种 code coverage 工具来进行代码覆盖检 查。 再次，我们需要使用一种自动化单元测试的工具，如Ｊｕｎｉｔ． 基于上述几点，每个项目需要编写Ａｎｔ脚本或ｍａｖｅｎ脚本，这 个脚本有一系列的 task，包括: compile, source code analytics, unit test, generate reports, generate javadoc, package artifacts 有了这样一个脚本以后，配置我们的项目到持续集成工具中去， 配置一个 configuration，然后设定 SCM repository，对应于我们的 ant task，我们可以配置一系列的 step 用于完成整个过程。如果我 们的测试需要跨平台，可以对应与同一个 unit test 的 task，使用 CI Server 的分布式的 step 功能，使之在不同平台上可以进行测试， 这一点也是使用 CI Server 的一个好处。 对应于这个 configuration，可以配置四个子 configuration， 分 布 是 Development Configuration, QA Configuration ， Integration Configuration 和 Release Configuration。这几个 configuration 分别对应于我们开发过程的四个阶段，我们的每日构 建在 Development configuration 上，可以配置为每日一次，而对于 其它三个则不做自动的构建，因为我们是通过 Promote 来做的。对于 Development Configuration，可以不对 SCM 自动打 Label，而对于 其它的，我们则对每一个 Build 自动对 SCM 进行打 Label。 有了这些以后，开发工作开始了，我们每天的代码在当天工作结 束前都提交到subversion里去，第二天，Development Configuration 就自动的编译完成了，并且会发送给我们。我们可以在 CI Server 的页面上，看到昨天有哪些个改动，测试的状况，比如说哪些测试修 正了，哪些测试还没有被修正，哪些source code没有通过代码检查。 然后我们到具体的报告中去分析，这些报告都可以很容易的打开 source code，我们可以直接在上面对各个改动做 code review。 经过这样开发之后一段时间，我们的功能很多已经就绪，就可以 提交给 QA 作 test 了，由于当日的构建可能失败，或者不是我们特别 想给QA的，那么我们可以选择之前几日的一个好的build做Promote， 这个 promote 就会自动触发 QA Configuration 去做 build，QA Configuration 的 build做完以后，就会发送一个邮件通知 QA Lead， 这封邮件里 CI Server 会把所有与上一个 QA build 的 changes 都列 出来，这样他就知道我们这个版本里增加了什么功能，修正了什么 bug。 再如此经过几个迭代后，我们开发组和 QA 组如果一致认为功能 基本实现了，bug 也不多了，于是就由 QA 的 Lead 做一个 Promote， 触发 Integration Configuration 不 build 一个大版本交给用户，做 VOC (Voice of Customer)，听取用户的意见，如果用户没有什么易 见的话，那么就会在 Integration Configuration 上做一个 Promote 到 Release Configuration 上去。 通过这样做，我们基本上可以很容易的知道每一个版本之间有什 么变化，甚至我们可以很容易的重新 build 出任何一个时间点上的版 本。而且，我们基本上无需操心什么时候给 SCM 打什么样的 Label， 因为对于我们而言，我们需要看到的只是每一个版本的 build。