《持续集成》章节试读

《持续集成》的笔记-第1页 - 前言

全栈工程师相关讨论 http://www.williamlong.info/archives/3731.html

《持续集成》的笔记-第78页

自动化测试性能提升的策略

《持续集成》的笔记-第89页

第一部分总结
持续集成的基本实践，包括编译、审查、测试、部署等基本环节，CI相关的原则，优化的方法。
能够借鉴的方面包括：
1. 分阶段集成
2. 数据库集成
3. 私有构建
4. 代码文档工具

《持续集成》的笔记-第78页 - 4.13 分阶段构建

分阶段构建过程图
1. 提交构建：编译单测，假合并过程
2. 次级构建：组件测试，应用内验收测试
3. 完整构建：系统测试，跨应用集成，端到端测试

《持续集成》的笔记-第10页

CI过程 1源代码编译 2数据库集成 3测试 4审查 5部署 6文档与反馈

《持续集成》的笔记-第300页

Done

《持续集成》的笔记-第23页 - 引入持续集成

CI 的价值在于:
1. 减少风险
2. 减少重复过程
3. 在任何时间、任何地点生成可部署的软件
4. 增强项目的可见性
5. 对开发团队的软件产品建立更强大的产品信息
阻碍 CI 的愿意:
1. 增加了维护 CI 系统的开销
2. 失败的构建太频繁意味着需要更快的响应速度
需要开发者做的事:
1. 编写自动化的开发者测试(单元测试、集成测试)
2. 坚持编码习惯(PEP8)

《持续集成》的笔记-第86页 - 针对每次变更构建软件

* 你的构建自动化了吗？你是否能够在没有IDE的情况下执行构建？
* 你是否已将所有软件资产都集中放置到版本控制库中？你是否能够从版本控制库中取出所有需要的文件并执行一次完整的构建？
* 您是否将更容易失败的构建任务放在了构建脚本的前面部分，这样就能够尽快收到构建失败的通知？
* 您的软件构建过程是否有一个“集成按钮”？数据库集成自动化了吗？测试呢？审查呢？部署呢？您在这个过程中收到并使用反馈信息吗？
* 您的集成构建过程是在一台独立的计算机上完成的吗？
* 您的集成构建需要花多少时间？您是否在尝试减少构建时间，提高反馈速度？
* 您是否使用CI服务器来集成软件？或者是否有规范的过程来执行手工集成构建？
* 您的项目以怎样的频率执行集成构建：每周、每晚或每小时？或者在每次发生变更时（持续）？