1.持续集成和持续交付关注对象分别是谁？
持续集成的关注对象是开发团队，持续集成系统的输出通常是手工测试和后续发布流程的输入。他能使用任何他能使用的工具和可视化整个流程
2.解释部署流水线的概念
指软件从版本控制库到用户手中这一过程的自动化表现形式。
3.流水线的各个阶段都是从哪些角度评估做为输入的构建版本
- 提交阶段是从技术角度上断言整个系统是可以工作的。
- 自动化验收测试阶段是从功能和非功能角度上断言整个系统是可以工作的。
- 手工测试阶段用于断言系统是可用的
发布阶段旨在将软件交付给用户，既可能是以套装软件的形式，也可能是直接将其部署到生产环境或试运行环境
4.只生成一次二进制包这一实践遵循了那两个原则？与之对应的反模式时什么？
保证部署流水线的高效运行，使团队尽早得到反馈，另一个原则是始终在已知可靠的基础上进行构建。
5.提交阶段包含的步骤
- 编译代码
- 运行一套提交测试
- 为后续阶段创建二进制包
- 执行代码分析来检查代码的健康状况
- 为后续阶段做准备工作，比如准备后续测试所用的数据库
6.描述从无到有，建立一个完整流水线的策略
- 对价值流建模，创建一个可工作的简单框架
- 将构建和部署流程自动化
- 将单元测试和代码分析自动化
- 将验收测试自动化
- 将发布自动化
7.应该由哪个团队来决定怎么做自动化部署？
由开发团队和运维团队一起来决定
8.解释任务导向和产品导向的构建工具有什么不同。
任务导向的构建工具会依据一系列的任务描述依赖网络，而产品导向的工具，是根据它们生成的产物来描述
9.解释如何做到部署系统的增量式改进？
- 运维和开发人员一起将应用程序部署到某个测试环境的过程自动化开始做起，
- 确保运维人员能够接受部署所用的那些工具，还要确保开发人员能使用同样的流程在自己的开发环境中部署和运行应用程序。
- 改进脚本，使其也能用于验收测试环境的部署
- 扩展这个部署流水线，使运维人员可以用同样的工具将应用程序部署到试运行环境和生产环境
10.提交阶段的理想运行时间是多少？
运行少于5分钟，最多不超过10分钟
11.“一旦发现错误，就应该让构建立即失败”，这个做法是正确的吗？为什么？
只在某个错误让提交阶段的其它任务无法执行时，才让提交阶段停下来，比如编译错误，否则就直至提交阶段全部运行完后，才汇总所有的错误和失败报告，以便可用一次性修复它们。
12.理想情况下，应该如何准备验收测试的起始条件？
在测试开始之前验证其状态是否符合你的期望，若有异常之处，就让这个测试失败。
13.用来进行容量度量的四种测试是什么？哪些是绝对度量，哪些是相对度量？
- 扩展性测试
- 持久性测试
- 吞吐量测试
- 负载测试
前两者是相对度量，后两个是绝对度量
14.容量测试应该到达哪些目标？
- 测试具体的现实场景
- 预先设定成功的门槛，能判定容量测试是否通过了
- 尽可能让测试运行时间短一些
- 在变更面前要更健壮一些
- 组合成大规模的复杂场景
- 是可重复的，既能串行执行，也能并行
15.不建议将容量测试增加到验收测试阶段的原因是什么？更好的做法是什么
通常需要的时间太长，资源占用太多。建议将自动化容量测试作为部署流水线中的一个完全独立的阶段。
简书回魂倒数第7天倒计时。
