持续集成最佳实践

持续集成的七项最佳实践

1. 经常提交代码

   ( 注： 就是要常提交、早提交代码，对系统没有太大影响的代码要尽早提交,这样才能实现CI的好处,开发者才能利用最新的变更的代码 )

2. 不要提交无法构建的代码

   ( 注： 不要将无法构建的代码提交到版本控制库中，以一种可重复的方式编译和测试代码，在向版本控制库提交代码之前先执行私有构建)

3. 立即修复无法集成的构建

   ( 注： 就是没有能够报告成功的构建。可能存在编译错误，测试或审查失败，数据库问题或部署失败 )

4. 编写自动化的开发者测试

   ( 注： 为了在CI系统中运行测试，所有测试都必须自动化 )

5. 必须通过所有的测试和审查

   ( 注： 自动化的测试和编译同样重要，没有完全通过测试的代码将导致低品质的软件 )

6. 执行私有构建

   ( 注： 为了防止集成构建失败，开发者应该在完成他们的单元测试之后，在自己本地工作 IDE中模拟一次集成构建 )

7. 避免签出无法构建的代码

   ( 注： 当集成构建失败时，不要从版本控制库中取出新的代码。否则，你必须花时间找到一些方法来绕过让构建失败的那些错误，才能编译和测试代码 )

8. 自动化构建

   ( 注： 编写自动化的构建脚本，减少软件项目中手工的、重复的容易出错的过程 )

9. 执行单命令构建

   ( 注： 把所有需要构建的代码放到源代码版本控制库中，以便于通过单个命令就能构建整个系统 )

10. 将构建脚本从IDE分离

    ( 注： 有两个原因：1.每个开发者可能使用不同的IDE，而找出每种IDE(是集成开发环境,分为：eclipse(IBM)、NetBean(SUN)、IDEA等 )中配置文件的差别会很困难。2.CI必须在无人干预的情况下执行自动化的构建，因此，开发执行的自动化构建脚本也应该能够由CI执行 )

11. 集中放置软件资产

    ( 注： 使用版本控制库来存放所有文件，可以更好地实现单命令构建。而且,集中放置软件资产防止了“在我的机器上是可以工作的”这种情况，在这种情况下，开发者不能重现其他环境中出现的缺陷 )

12. 创建一致的目录结构

    ( 注： 为了能够在项目开发过程中从版本控制库中取出所有各种可供使用的资产组合 )

13. 让构建快速失败

    ( 注： 尽可能把最容易出现错误或失败的放在前面，然后，进行处理 )

14. 针对所有环境构建

    ( 注： 改进构建的可配置性，将构建脚本参数化，在任何环境下创建能工作的软件 )

15. 使用专门的构建计算机

    ( 注： 可以大大减少关于环境和配置的假定，当开发者得知最新的集成构建失败时，就可以避免从版本控制库中取出有问题的代码 )

16. 使用CI服务器

    ( 注： 通过IC服务器来进行持续集成.手工集成比较复杂 )

17. 执行手工集成构建

    ( 注： 在某个时间只有一个人能向版本控制库提交变更，有效的防止失败的构建，对于大型团队并不太适合 )

18. 执行快速构建

    ( 注： 如果构建需要很长时间才能完成，常常会给CI的实践投下令人不快的阴影。
    集成构建的时间越短，您就能越快收到反馈信息 )

19. 分阶段构建

    ( 注： 先是执行初步的集成“提交”或轻量级构建，对软件组建进行集成并执行单元测试，
    在执行更全面的集成构建，包括组件测试、审查和部署 )

20. 自动化数据库集成

    ( 注： Ant提供了一个任务，通过sql任务来执行SQL脚本，以一种序列化的方式执行数据库集成 )

21. 使用本地数据库沙盒

    ( 注： 创建一个数据库的本地实例，在他的工作站上对数据库进行修改，测试变更不会影响到他人，修改、测试通过后并将提交到版本控制库 )

22. 利用版本控制库共享数据库资产

    ( 注： 将所有数据库资产都放到版本控制库中，利用版本控制库中的脚本从头创建整个数据库,减少项目中所有开发者都要找DBA修改数据库所引起的瓶颈 )

23. 让开发者能够修改数据库

    ( 注： 让每一个开发者都能够修改任何一部分数据库脚本，并不是每一个开发者都会去修改数据库脚本，因为每个开发者都有自己的数据库沙盒 )

24. 让DBA成为开发的一员

    ( 注： 让DBA成为开发团体的一员，这样方便开发者修改数据库 )

25. 自动化单元测试

    ( 注： 使单元测试(即测试方法)实现自动化 )

26. 自动化组件测试

    ( 注： 验证系统的各个部分，可能需要安装整个系统或某些外部依赖关系，典型的组件测试需要底层数据库支持，甚至可能跨越架构边界 )

27. 自动化系统测试

    ( 注： 将项目的整体效果进行自动化测试. )

28. 自动化功能测试

    (注： 将项目的功能进行测试,也就是从客户的视角来测试应用程序，测试将模仿客户的行为。 )

29. 对开发者测试分类

    ( 注： 对开发者测试的内容进行分类管理. )

30. 先执行最快的测试

    ( 注： 首先执行最容易测试的方法 )

31. 为缺陷编写测试

    ( 注： 为缺陷编写测试用例，不断执行和修复测试，直到测试不再失败为止 )

32. 让组件测试可重复

    ( 注： 对数据库的测试.会对数据库的信息带来不便.所以得模拟一个测试数据库来进行测试.通过XML中的数据可以实现插入,更新,和删除等操作.配置具体的数据库,为我们测试 )

33. 将测试用例限制为一个断言(一个test中只能有一个Assert..)

    ( 注： 设置多个断言，任何一个断言失败，都不会执行下面的断言。限制成一个断言，就没什么干扰 )

34. 降低代码复杂度

    ( 注： 代码复杂：if else等逻辑判断和重复代码等等一般代码复杂圈度通常与缺陷有关，代码复杂度过高会增加程序的风险 )

35. 持续进行设计复查

    ( 注： 总是查看代码的耦合度.两个测量指标有助于确定过度耦合的情况(传入耦合和传出耦合)反映了一个构架维护问题.按耦合测量指标它会产生XML格式和HTML格式的报告.在情况失控之前加以纠正 )

36. 通过代码审查维持组织机构的标准

    ( 注： 通过持续地监控和审查代码，您的团队可以保持遵守架构和编码指南。问题可以早发现，常发现，从而避免了长期的维护问题 )

37. 减少重复的代码

    ( 注： 重复代码带来的问题：1.增加维护成本，因为需要多次发现、报告、分析和修复缺陷。2.不确定是否存在其他缺陷。3.对额外编写的代码增加了测试成本。使用通用的、可复用的、抽象的行为或好的框架解决代码重复问题 )

38. 判断代码覆盖率

    ( 注： 通常利用测试装备来执行代码，并且记录下测试过程中“接触”到的对应代码的数据.从而获得代码覆盖率.代码覆盖率越高说明你写的代码越优秀 )

39. 随时随地发布可工作的软件

    ( 注： 在任何时间、任何环境下发布能工作的软件 )

40. 为库中的资产打上标签

    ( 注： 创建一个版本控制库的标签有利于标识并追踪资产。为版本控制库打上标签，就相当于快照，在最坏的情况下，可以作为回滚的基础。这些标签也使得版本控制库中允许存在并行分支，还提供了处理多条开发线的能力 )

41. 得到干净的环境

    ( 注： 在测试之前就是说清理上次测试遗留记录或对程序可能影响的因素，避免影响当前程序的正常运行 )

42. 每一个构建版打上标签

    ( 注： 为每一个构建版创建一个唯一的标识符，即“构建版标签”，就是为了将功能、缺陷或需求与二进制的制品关联起来 )

43. 执行所有测试

    ( 注： 执行所有自动化测试，从单元测试到功能测试。之后还是要由人进行测试 )

44. 创建构建反馈报告

    ( 注： 生成自动化构建的反馈信息有助于大家理解要发布的构建版中的确切情况，
    包括构建版中哪些文件不同，修复了哪些缺陷，实现了哪些功能等 )

45. 回滚构建的过程能力

    ( 注： 能够“撤销”部署是有效的开发中的重要一环。如果需要以前版本取代新的有缺陷的代码，可能因 为以前的版本工作得更好。可通过构建版标签和版本控制库标签，索取想要的版本就可以了 )
    

46. 使用持续反馈机制

    ( 注： 使用持续反馈机制，不间断的反馈项目的构建信息给我们。以便我们及时做出处理 )


注解都是我们小组努力分析,讨教总结出来然后再把它们精辟,简短,易懂的注上去的哦,如有瑕纰,
欢迎指出.