软件开发面临的问题
- 确定软件需求
- 确定项目进度（可见性）
- 如何以最快速度将软件交付给用户？
- 如何让开发、测试、产品经理、运维人员高效工作？
软件需要满足于业务目的，质量不等于完美，“追求完美是把事情做好的大敌”。
持续集成
持续集成是一种软件开发实践【不是工具】，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。 — Martin Fowler
持续集成的价值
协作
让开发的软件一直处于可工作状态
开发人员
- 尽快发现问题 解决问题的关键是尽快发现问题 减少引入缺陷与修复缺陷之间的时间
- 防止分支大幅偏离主干
-
减少重复过程&人为错误： 以自动化编译、发布、测试…，代替手工操作 避免了一些人为的错误(build 号忘加 1、Debug 开关忘关)
- 建立团队对开发产品的信心
测试人员
小步增量，易于发现问题，并快速反馈给开发人员
小结
集成的目的其实是沟通：集成可以让开发者告诉其他人他们都改了什么东西，频繁的沟通可以让开发者更快地了解变化。
持续集成的前提条件
团队共识
持续集成不是工具，是一种实践，需要投入并遵守一些规则，才能提高质量
频繁提交
“如果你遇到一件很痛苦的事情，似乎比较好的建议就是更频繁地做这件事情” — Martin Fowler
哲学：一件事情很难，又必须去做，不妨经常去做，每次做一点，分而治之，滴水穿石、跬步千里 —— 早集成、常集成 解决问题的关键是尽早发现问题 每过几个小时就提交一次，冲突也会在几个小时之内被发现 两次提交之间只有几个小时的修改，产生这些问题只可能在很有限的几个地方 提交的越多，需要查找冲突错误的地方就越少，改起来也越快 用差异调试比较当前版本和之前没有 bug 的版本 客观上会鼓励开发者将工作分解成以小时计的小块
保证每次提交的质量
每次提交的版本都有可能产生一个可发布的版本 每次提交的质量不好，不但会影响自己，而且会影响别人
不单单源代码
与项目相关的所有内容（代码、测试代码、数据库脚本、构建与部署脚本、 IDE 配置文件，以及所有用于创建、安装、运行、测试应用程序的东西） 关于这点，可以参考持续集成之“Everything is code”
全面的自动化构建、测试套件
- 10 分钟 build（快速的 build） 没有什么比缓慢的 build 更能危害持续集成活动 一旦提交 build 成功，其他人就可以放心地基于这些代码工作了
- 在不同的情况中 build 不同的 target
- 每次代码提交后都会在持续集成服务器上触发一次构建 构建不只是编译，可能包含编译、测试、审查和部署以及其他一些事情，将代码放在一起，并让其可以作为一个一致的单元运行的过程
- 自动化标准 任何人都应该能从一个干净的计算机上 check out 源代码，然后敲入一条命令，就可以得到能在这台机器上运行的系统
本地环境与持续集成环境、测试环境、生产环境一致
关于环境可参考：Traditional Development/Integration/Staging/Production Practice for Software Development
必要的实践
“最新的正确版本”作为起点
时刻准备回滚到前一个版本
修复破坏应用程序的任意修改是最高优先级的任务
10 分钟修复不完，需要回滚&在回滚之前要规定一个修复时间
等提交测试通过后再继续工作
给自己喝一杯咖啡的时间 等待集成返回结果后继续工作能减少错误，也能让别人在最新的正确版本作为起点
提交前在本地运行所有的提交测试
现代 CI 服务器提供“预测试提交”、“个人构建”
构建失败后不要提交新代码
谁提交，谁负责
监视 mainline 上的构建，失败时及时修复 如果在下班前提交了代码，那在 mainline 构建成功之前就不能回家
勿将失败的测试注释掉
修改代码、修改测试、删除测试
测试驱动开发
持续集成实践步骤
自动化构建
引入自动化测试
试着指出主要出错的地方，并要让自动化测试暴露这些错误
试着加快 build 的速度
10 分钟 build
CI 选型
寻找老司机帮忙（很重要）
老司机理论+实践经验丰富
iOS Localizable.strings与Excel互相转换工具