持续集成总论
传统软件的持续集成主要有以下措施。
daily build：每日构建，开发者每天提交代码到代码仓库，构建一个可运行的版本。
build verification test（BVT）：构建验证测试，每日构建版本出来后，运行一组自动化的测试用例，保证基本功能可用。
对于前端来说，有一些现实的区别：
- 前端代码按页面自然解耦，大部分页面都是单人开发；
- 前端构建逻辑简单，一般开发阶段都保证构建成功，不需要构建；
- 前端代码一般用于开发界面，测试自动化成本极高；
- 前端页面跳转，是基于 url，没有明确的产品边界。
持续集成的目标
一是要及早集成代码形成可测试的版本，二是通过一定的测试来验证提交的代码的有效性。
持续集成的方案
前端的持续集成的措施
- 预览环境，代替每日构建，前端每次（或指定次）提交代码到仓库都同步到预览环境，保证预览环境总是可用；
- 规则校验，代替构建验证测试，通过数据采集（如前面提到的性能数据）和代码扫描，保证提交的代码满足一定的质量要求。
持续集成的实施
持续集成的实施，是必须严格做到自动化和制度化的。
这里，我们必须警惕三种错误：
少数人拍脑袋决定校验规则；
一成不变的校验规则；
频繁无规律变化的校验规则。
持续集成的结果
持续集成的结果也能够以数据的方式呈现出整个开发团队的健康状态
952
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
