想象你经营着一家繁忙的咖啡店。每天开门前，店员们要完成一套固定的“开店流程”：检查咖啡豆库存、预热咖啡机、测试磨豆机、擦拭吧台。这套流程如果靠人肉记忆，迟早会出错——今天忘了预热，明天漏了库存。于是你写了一张《开店检查清单》，贴在墙上，谁值班都照单执行。更聪明的是，你让每位咖啡师提交新配方时，自动触发一次“完整流程演练”，确保新配方不会搞砸招牌咖啡。 Travis CI 就是软件世界里的“开店检查清单自动化管家”。当你在 GitHub 上托管代码（咖啡豆仓库），每次有人提交代码（新配方建议），Travis CI 自动拉取代码（拿咖啡豆）、搭建环境（预热机器）、运行测试（试喝新品）、构建产物（打包成品）、甚至部署上线（正式上架）。全程不需要人类盯着，一切由一份 .travis.yml 配置文件（你的检查清单）驱动。这篇文章，我们就来拆解这个“自动化管家”的运作机制——从配置语法、环境矩阵、并行作业到条件部署，再到它和 GitHub Actions 的对比迁移。

岗位关联

掌握 Travis CI 意味着你理解了 CI/CD 的黄金范式：配置即流程。这是 AI 从业者从“训练模型”走向“交付模型”的必修课——模型要上线，流水线是桥梁。

目录
  1. 可视化演示
  2. CI服务概览
  3. 配置语法基石
  4. 环境变量管理
  5. 构建矩阵策略
  6. 缓存与并行优化
  7. 部署流程设计
  8. 迁移GitHub Actions
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

三模式展示Travis CI：流水线五阶段(push→install→build→test→deploy)、构建矩阵（Python版本×Ubuntu发行版并行作业）、.travis.yml配置结构（lang/script/deploy/cache/services键值）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

CI/CD五阶段流水线 push触发Webhook→自动排队构建 inst→bld→tst→dpl阶段串行 trigger: push | PR | tag GitHub事件触发Travis CI自动构建，测试通过后触发部署。

CI服务概览

咖啡店的开店清单如果只是纸上的文字，价值有限；真正的价值在于“有人严格执行”并且“每次执行都留痕”。Travis CI 的角色，就是那个从不偷懒、每次都能一字不差执行清单的值班经理。它是一款云端托管的持续集成服务，你不需要自己买服务器、搭 Jenkins、配监控——Travis 在云端帮你把环境备好、代码拉下来、测试跑起来。

为什么它和 GitHub 是“天作之合”？因为你的代码仓库托管在 GitHub 上，Travis 可以直接“看到”仓库的每一次变动。你只需要在 GitHub 上登录 Travis CI，授权它访问仓库，然后在仓库根目录放一份 .travis.yml 配置文件——Travis 就像拿到了你的开店清单，从此每次 push（提交代码）或 pull request（合并请求），它都会自动开工。

这种“声明式配置”的核心哲学是：你不告诉 Travis“怎么一步步做”，而是告诉它“我要什么环境、跑什么命令、测什么结果”。剩下的脏活累活，Travis 全包。就像你写开店清单时不会写“请用右手拿起抹布擦吧台”，而是写“吧台必须干净”——具体怎么干净，值日生自己想办法。

配置语法基石

开店清单上，每一项都有固定的书写格式：“准备阶段”写什么、“执行阶段”写什么、“收尾阶段”写什么。Travis CI 的 .travis.yml 同样有一套阶段化语法，它规定了流水线的“时间轴”。

最基础的三件套是 language、install 和 script。language 告诉 Travis“我们店是咖啡店还是奶茶店”——即项目用什么编程语言和版本。.travis.yml 会先按 language 字段准备基础镜像，相当于开店清单规定“我们需要一台意式咖啡机”。

install 阶段负责安装依赖。这一步对应开店流程里的“检查库存、补齐原料”。例如 Python 项目常见 pip install -r requirements.txt——把 requirements.txt 里列出的所有 Python 包一次装齐。before_script 是 script 之前的“预备动作”，比如启动测试数据库、导出环境变量。最后 script 阶段是“正戏”：运行测试、执行构建。

回到咖啡店的比喻：install 是采购原料，before_script 是预热机器，script 是正式制作。每一步失败都会让门店停止营业——但好在这份清单是自动执行的，失败时会立刻响铃报警，而不是等顾客投诉才发现。

流水线=install→before_script→script\text{流水线} = \text{install} \rightarrow \text{before\_script} \rightarrow \text{script}
流水线时间轴公式：Travis 按固定顺序执行各阶段，任何一个环节失败（非零退出码），后续阶段立即终止。
  1. 阶段定义Travis 将流水线划分为多个有序阶段，每个阶段对应一组 shell 命令。
    install→before_script→script\displaystyle \text{install} \rightarrow \text{before\_script} \rightarrow \text{script}
  2. 退出码门禁每个阶段只要有一条命令返回非零退出码，流水线立即标记为失败。
    exit_code≠0⇒fail\displaystyle \text{exit\_code} \neq 0 \Rightarrow \text{fail}
  3. 嵌套钩子before_script 可以包含多条命令，用 YAML 列表形式展开。
    {before_script:[cmd1,cmd2]}\displaystyle \{\text{before\_script}: [\text{cmd}_1, \text{cmd}_2]\}

环境变量管理

开店清单上有些信息是“店长才知道的秘密”，比如烤箱的解锁密码、保险柜的备用钥匙。这些不能写在任何人可见的墙上。Travis CI 的环境变量管理机制，正好对应这个需求。

全局变量定义在 .travis.yml 的 env 字段下，对当前构建的所有作业生效。这相当于贴在厨房墙上“所有人可见”的公告：比如 PYTHONPATH=src，告诉每个作业“代码在 src 目录下”。

加密变量则是那个“保险柜”。Travis 提供了 travis encrypt 命令，你可以把敏感信息（API 密钥、云服务凭证）加密后放入 .travis.yml，只有 Travis 云端才能解密。仓库里的任何协作者，甚至恶意者，看到的都只是一串密文。

加密变量就像一个“密码信封”：咖啡店把保险柜密码装在信封里贴在墙上，店员看得见信封但打不开，只有值班经理（Travis）有钥匙。这既保证了透明度（人人可见信封存在），又保证了安全性（密码不泄露）。

env={global:[K1=v1,… ], matrix:[K2=v2,… ]}\text{env} = \{ \text{global}: [K_1=v_1, \dots], \ \text{matrix}: [K_2=v_2, \dots] \}
环境变量卷：全局变量、加密变量、矩阵变量构成三层作用域。矩阵变量优先级最高，允许在同一流水线中注入不同配置。
  1. 全局变量定义在 env.global 下，所有作业共享，适合公共配置。
    env.global=[PYTHONPATH=src]\displaystyle \text{env}.\text{global} = [\text{PYTHONPATH}=\text{src}]
  2. 矩阵变量定义在 env.matrix 下，每个作业取其中一个组合，适合差异化配置。
    env.matrix=[MODE=A,MODE=B]\displaystyle \text{env}.\text{matrix} = [\text{MODE}=A, \text{MODE}=B]
  3. 加密变量通过 travis encrypt 生成密文，Travis 在运行时解密注入环境。
    cipher=Encrypt(Kpub,v)\displaystyle \text{cipher} = \text{Encrypt}(K_{\text{pub}}, v)

构建矩阵策略

一家连锁咖啡店有二十家分店，每家店的咖啡机型号不同。如果只在总店测试新配方，其他分店可能翻车。构建矩阵让 Travis 同时模拟多种环境——就像在同一时间让所有分店一起试做新配方。

矩阵的展开逻辑很简单：你定义多个维度的取值，Travis 自动做“笛卡尔积”。例如：

这会产生 2×2=4 个作业，分别测试 Python 3.8/3.9 × fast/full 四种组合。矩阵的威力在于并行作业——4 个作业同时跑，总耗时约等于最慢的那个作业，而不是四个串行相加。

快速失败机制（fast finish）是矩阵的“止损保险”：如果某个作业已经确定失败，Travis 可以提前终止其他仍在排队或运行的作业。这就像咖啡店发现浓缩咖啡机集体故障，立即停掉所有门店的试做，而不是等每家店都做完才汇报失败。

矩阵策略让 AI 项目的测试覆盖面大幅提升：你可以同时验证模型在不同 Python 版本、不同依赖组合下的行为，这相当于同时开二十家分店试做新品，而不是一家一家轮着来。

矩阵作业数=∏i=1n∣维度i∣\text{矩阵作业数} = \prod_{i=1}^{n} |\text{维度}_i|
笛卡尔积公式：矩阵作业数等于所有维度取值数量的乘积。维度越多，覆盖面越广，但消耗的构建时间也越多。
  1. 矩阵维度每个字段（如 python、env）是一个维度，各自有若干取值。
    D1={3.8,3.9},D2={fast,full}\displaystyle D_1 = \{3.8, 3.9\}, \quad D_2 = \{\text{fast}, \text{full}\}
  2. 作业组合所有维度的笛卡尔积构成作业集合。
    Jobs=D1×D2={(3.8,fast),… }\displaystyle \text{Jobs} = D_1 \times D_2 = \{(3.8, \text{fast}), \dots\}
  3. 快速失败当任一作业失败时，未完成的作业可以被标记为“已取消”。
    ∃job=fail⇒cancel pending\displaystyle \exists \text{job} = \text{fail} \Rightarrow \text{cancel pending}
yaml6 行
python:  - 3.8  - 3.9env:  - MODE=fast  - MODE=full

缓存与并行优化

开店清单执行最耗时的是什么？不是做咖啡本身，而是每次开店都要“重新进货”——从仓库搬咖啡豆、清洗机器。Travis 也面临同样的困境：每次构建都从头安装依赖，pip install 动辄几分钟甚至十几分钟。

缓存机制就是 Travis 的“常备库存”。你可以配置 cache: pip 或指定目录，Travis 会将 ~/.cache/pip 等目录缓存起来，下次构建时直接复用。这就像咖啡店每次打烊后不清空咖啡豆柜，第二天开店直接零补货就能开工。

并行度方面，免费套餐的并发数有限。这就像开店清单上写着“最多同时启用 2 台咖啡机”——超出部分排队等候。合理规划矩阵大小（比如先 2×2 而不是 4×4）能让资源利用更高效，避免排队浪费时间。

T构建=T依赖下载×(1−缓存命中率)+T实际工作T_{\text{构建}} = T_{\text{依赖下载}} \times (1 - \text{缓存命中率}) + T_{\text{实际工作}}
缓存收益公式：缓存命中率越高，依赖下载耗时越低。实际工程中，缓存常能砍掉 50%-80% 的构建时间。
  1. 缓存目录cache 字段声明要持久化的目录或包管理器缓存。
    cache=dict(package_manager=true)\displaystyle \text{cache} = \text{dict}(\text{package\_manager} = \text{true})
  2. 失败回退缓存可能损坏，Travis 在缓存不可用时自动回退到全新安装。
    fallback=full_install\displaystyle \text{fallback} = \text{full\_install}
  3. 并行作业矩阵产生的多个作业并行执行，总体耗时由最慢作业决定。
    T总=max⁡(job1,…,jobn)\displaystyle T_{\text{总}} = \max(\text{job}_1, \dots, \text{job}_n)

部署流程设计

咖啡店的新配方经过所有分店测试通过后，最后一步是“全国门店上架”。在 CI 世界里，这一步叫部署。Travis 的 deploy 阶段是整个流水线的“收官之战”。

deploy 支持多种 provider（部署目标），比如 PyPI、AWS S3、GitHub Pages、Docker Hub 等。这相当于你的配方最终要发布到哪个“分发渠道”。例如，一个 Python 库测试通过后自动 twine upload 到 PyPI，全世界开发者就能 pip install 到你最新版本。

条件控制通过 on 字段实现，最常见的是“只在 master 分支且 tag 匹配时才部署”。这就像咖啡店规定：“只有店长签字（打 tag）的配方才允许全国上架。”

skip_cleanup 是一个容易忽略但极其重要的选项。Travis 默认在部署前会清掉构建产物，以防止垃圾文件被上传。但如果你要上传的正是构建产物（比如编译好的模型二进制），就必须设置 skip_cleanup: true——相当于告诉咖啡店：“打包好的产品别扔，我要的就是它。”

部署触发器设计的本质是“信任边界”：测试通过的代码才会进入部署候选，而部署候选只有在满足特定条件（分支、tag）时才会真正上线。这和开咖啡店如出一辙——新品必须通过试喝测试，但“正式上架”还需要店长签字。

deploy:provider⏟目标平台+on⏟触发条件+skip_cleanup⏟保留策略\text{deploy}: \underbrace{\text{provider}}_{\text{目标平台}} + \underbrace{\text{on}}_{\text{触发条件}} + \underbrace{\text{skip\_cleanup}}_{\text{保留策略}}
部署三要素：目标平台（provider）、触发条件（on）、产物保留（skip_cleanup）。三者缺一不可，组合起来才能安全地让流水线自动上线。
  1. provider 选择声明部署目标，Travis 内置多种云平台插件。
    deploy.provider∈{pypi,s3,docker,… }\displaystyle \text{deploy}.\text{provider} \in \{\text{pypi}, \text{s3}, \text{docker}, \dots\}
  2. on 条件用 branch 和 tags 字段限定触发场景。
    on:branch=master∧tags=true\displaystyle \text{on}: \text{branch} = \text{master} \wedge \text{tags} = \text{true}
  3. skip_cleanup禁止 Travis 清理构建产物，保留待部署文件。
    skip_cleanup=true⇒保留 build/\displaystyle \text{skip\_cleanup} = \text{true} \Rightarrow \text{保留 } \text{build/}

迁移GitHub Actions

2021 年 Travis CI 宣布免费套餐大幅缩减后，大量项目开始迁移到 GitHub Actions。好消息是，你已经掌握了 Travis 的配置心智模型，迁移就是“把开店清单翻译成另一套表格格式”。

最核心的差异是语法结构。Travis 的 .travis.yml 用 language 字段声明环境；Actions 则用 jobs.<id>.runs-on 指定运行器（runner）。Travis 的 script 阶段对应 Actions 的 run 步骤。矩阵方面，Travis 的隐式笛卡尔积在 Actions 中变成了显式的 strategy.matrix 字段。

缓存与密钥迁移也有对应关系：Travis 的 cache: pip 对应 Actions 的 actions/cache；Travis 的加密变量（travis encrypt）对应 Actions 的 secrets（在 GitHub 仓库 Settings 中配置，更直观）。Actions 的最大优势是它原生集成在 GitHub 中，不需要跳转到外部站点查看构建日志。

成本模型方面，Travis 免费额度缩减后，超出部分按用量计费；Actions 则为 GitHub 用户提供每月免费分钟数（私有仓库 2000 分钟/月，公有仓库完全免费）。对于 AI 项目的持续集成来说，Actions 的免费额度和原生集成往往更具吸引力。

Travis 配置范式→语法映射Actions workflow\text{Travis 配置范式} \xrightarrow{\text{语法映射}} \text{Actions workflow}
迁移的本质不是“改配置文件”，而是“把清单翻译成新格式”。你对 CI 的底层理解（阶段、矩阵、缓存、部署）完全通用，这才是最重要的资产。
  1. 环境声明对比language: python → runs-on: ubuntu-latest + setup-python。
    language→runs-on+actions/setup-python\displaystyle \text{language} \rightarrow \text{runs-on} + \text{actions/setup-python}
  2. 运行阶段对比install + script → run 步骤序列。
    install/script→steps[run]\displaystyle \text{install}/\text{script} \rightarrow \text{steps}[\text{run}]
  3. 矩阵语法对比Travis 隐式矩阵 → Actions strategy.matrix 显式声明。
    ∏dims→strategy.matrix.include\displaystyle \prod \text{dims} \rightarrow \text{strategy}.\text{matrix}.\text{include}

AI 应用场景

场景一：AI 模型训练流水线自动化

阶段：模型开发与持续集成

解决的问题：传统 AI 项目中，模型训练、评估、版本管理全靠人工操作。数据科学家改一行数据处理代码，需要手动重跑整个训练脚本，耗时且容易出错（换台机器就复现不了）。Travis CI 可以在每次 push 代码时自动触发：拉取最新数据 → 安装依赖 → 运行数据预处理 → 执行模型训练 → 跑评估指标 → 将模型产物上传到制品库。

具体案例：一个 NLP 团队维护着情感分析模型。他们在 script 阶段运行 python train.py --test（用小数据快速验证代码正确性），在 deploy 阶段用 on.tags: true 条件——只有打了 v1.2.0 这样的 tag 才触发完整训练并发布模型到私有 PyPI。这样，团队每次代码改动都会收到 Travis 的验证结果，模型效果回退被第一时间捕获。

场景二：AI 服务的自动化部署

阶段：模型部署与交付

解决的问题：AI 模型训练好之后，如何安全、可靠地部署到生产环境？手工 SSH 到服务器拉代码、重启服务，既慢又容易出错（忘记激活虚拟环境、依赖版本覆盖等）。Travis CI 的 deploy 阶段支持直接推送到云平台容器服务，结合 skip_cleanup 保留 Docker 镜像构建产物，让“测试通过即上线”成为现实。

具体案例：一个推荐系统团队将模型封装为 Docker 镜像。Travis 流水线在 master 分支测试通过后，通过 provider: script 执行 docker build && docker push 将镜像推送到镜像仓库，随后触发云平台滚动更新。回滚也简单——重新部署上一个 tag 的镜像即可。整个流程提交一个 merge request 就完成，全程无需人工登录服务器。

Python 演示

python76 行
"""模拟 Travis CI 核心流水线机制的本地演示。 通过小型 Python 脚本还原 Travis CI 的五个核心机制:1. 流水线阶段执行 (install -> before_script -> script)2. 构建矩阵笛卡尔积展开3. 环境变量注入4. 缓存命中断言 (以哈希值为模拟)5. 部署条件门禁""" import osimport itertoolsimport hashlib  class TravisMock:    def __init__(self, config):        self.config = config        self.cache_store = {}     def expand_matrix(self):        """将配置中的矩阵维度展开为笛卡尔积作业列表"""        python_versions = self.config["python"]        env_modes = self.config["env"]        return list(itertools.product(python_versions, env_modes))     def run_pipeline(self, python_ver, env_mode):        """按顺序执行流水线阶段, 任一阶段失败则中止"""        install = f"pip install -r requirements-{python_ver}.txt"        before_script = f"export MODE={env_mode}"        script = f"python train.py --env {env_mode}"        print(f"  [install]       {install}")        print(f"  [before_script] {before_script}")        print(f"  [script]        {script}")        return True     def load_cache(self, key):        """模拟缓存: 命中返回 True, 否则返回 False"""        return key in self.cache_store     def save_cache(self, key, value):        """写入缓存"""        self.cache_store[key] = value     def should_deploy(self, branch, tagged):        """部署条件门禁: 仅 master 分支且打 tag 时部署"""        return branch == "master" and tagged  def main():    config = {        "python": [3.8, 3.9],        "env": ["fast", "full"],    }    travis = TravisMock(config)     jobs = travis.expand_matrix()    print(f"展开构建矩阵, 共 {len(jobs)} 个作业:")    for py_ver, env_mode in jobs:        print(f"  作业: Python {py_ver} + MODE={env_mode}")        travis.run_pipeline(py_ver, env_mode)     cache_key = hashlib.md5(b"requirements").hexdigest()    hit = travis.load_cache(cache_key)    print(f"\n缓存命中: {hit}")    if not hit:        travis.save_cache(cache_key, "cached-deps")        print("首次构建, 已保存依赖缓存")     deploy = travis.should_deploy(branch="master", tagged=True)    print(f"\n部署条件判断 (master + tag): {deploy}")    assert deploy, "master 带 tag 应允许部署"  if __name__ == "__main__":    main()
目的：用 60 行代码还原 Travis CI 最核心的五种机制，帮助你把抽象概念映射为具体逻辑。运行后可以看到矩阵展开、阶段执行、缓存判定、部署门禁的完整流程。
  1. def expand_matrix(self)模拟 Travis 的矩阵笛卡尔积展开逻辑，对应“分店同时试做新配方”
  2. itertools.product(python_versions, env_modes)标准的笛卡尔积计算，等价于 Travis 内部按维度做乘积
  3. def run_pipeline(self, python_ver, env_mode)模拟流水线的三阶段顺序执行，对应开店清单的流程
  4. if not hit: travis.save_cache(...)缓存未命中时写入，命中则跳过依赖下载，体现“常备库存”思想
  5. def should_deploy(self, branch, tagged)部署门禁：只有 master 分支且打 tag 才允许上线
  6. assert deploy用断言自动验证部署条件逻辑，模拟 CI 中“测试不通过就失败”的哲学
  7. if __name__ == "__main__":标准入口，保证脚本可以直接运行

常见误区

误区“既然 Travis CI 免费额度缩减了，那它是完全过时的工具，任何新项目都应该直接上 GitHub Actions，不该再看 Travis 的配置。”

正解Travis CI 仍然是理解 CI/CD 概念的绝佳教材。它的配置范式极其简洁（一个文件搞定全流程），语法设计的抽象层级非常适合入门者建立“流水线思维”。而且大量历史项目仍在用 Travis，你接手这类项目时不会读 .travis.yml 就等于“看不懂店里的老检查清单”。更关键的是，Travis 的很多概念（阶段、矩阵、缓存、部署条件）在 Actions 中一一对应，先学 Travis 再迁移到任何 CI 工具都会轻松得多。

为何常见：因为 2021 年 Travis 免费套餐缩减后，社区舆论一边倒唱衰它，很多人就以为它“死了”——但旧项目维护、私有化部署、教学场景中，它依然活跃。

误区“我把 API 密钥直接写在 .travis.yml 的 env 字段里就行了吧？反正仓库是私有的，别人看不到。”

正解私有仓库的协作者、任何能拿到仓库权限的人都能看到明文密钥。更危险的是，一旦仓库转为公开或被 fork，密钥立即泄露。正确的做法是使用 travis encrypt 命令加密敏感变量，或者直接在 Travis 网站后台配置环境变量（不进仓库）。这就像保险柜密码不应该写在墙上，而应放在只有值班经理能打开的信封里。

为何常见：很多初学者对“环境变量”的理解停留在“配置文件里写变量”，没有建立“密钥必须加密”的安全意识，直到泄露事故发生才追悔莫及。

误区“测试覆盖越多环境越保险，我把 Python 2.7 到 3.12 的每个版本都放进矩阵，再加上四种不同的 env 组合，一次跑完所有情况不就无敌了？”

正解矩阵作业数等于各维度取值数量的乘积，每多一个版本，总作业数翻倍。Travis 免费资源有限，大量作业会排队等待，反而拖慢整体效率。工程上应遵循“最小可行覆盖”原则：只测“主版本+边界版本”（如 3.8 和最新版），依赖组合只在关键变更时全量展开。这就像咖啡店试做新品不会让二十家分店同时做，而是选三家有代表性的门店先试。

为何常见：初学者容易把“覆盖率”和“数量”画等号，忽略了资源有限性这个硬约束。

误区“我没写 skip_cleanup 字段，反正部署功能正常，这个选项应该无所谓吧？”

正解默认情况下 Travis 在部署前会执行 cleanup，删除构建过程中生成的临时文件。如果你的部署目标是上传构建产物（如 Docker 镜像、编译后的模型文件），cleanup 会把这些文件全部删掉，导致部署内容不完整或直接失败。设置 skip_cleanup: true 才能保留产物。这就像开店打烊后员工顺手把吧台上打包好的新品礼盒扔进垃圾桶——你辛辛苦苦做出来的东西被“保洁阿姨”清掉了。

为何常见：这个字段名太反直觉——“skip_cleanup“ 看起来像”跳过清理“，新手往往以为不写才是”正常清理”，没意识到清理会误伤部署产物。

误区“Travis 的 deploy 触发条件只能写 `on: branch: master`，其他分支不可能触发部署。”

正解on 条件支持多种组合——tags: true + branch 匹配、condition 自定义表达式（如环境变量判断）、repo 匹配（fork 仓库不部署）等。实际工程中，常见策略是“master 分支测试通过就部署到 staging，打 tag 才部署到生产”。条件字段是部署触发器设计的核心，它是你的发布策略的“门禁规则”。这就像咖啡店既可以“每天 10 点试营业”，也可以“店长签字才正式营业”——触发条件完全由你定义。

为何常见：大多数人只见过示例代码里的 branch: master，误以为这是唯一写法，没有意识到 CI 配置的灵活性和可编程性。

面试题

Q1. Travis CI 配置文件中，language 字段的主要作用是什么？

单选题 · mid

  • A.指定项目代码的编写语言和运行环境← 正确答案
  • B.控制 Git 仓库的默认分支名称
  • C.决定 Travis 服务器的物理位置
  • D.设置构建产物的加密级别

答案：A。language 字段告诉 Travis 该用什么语言生态来准备环境（比如 Python 就装 Python 解释器），相当于开店清单规定“我们需要一台咖啡机”。B 是 Git 操作，C 是托管区域，D 是安全功能，都与 language 无关。

Q2. Travis CI 中，script 阶段的任务是下列哪一项？

单选题 · easy

  • A.安装 Python 依赖包
  • B.运行测试和构建命令← 正确答案
  • C.推送代码到远程仓库
  • D.加密敏感环境变量

答案：B。script 是流水线的“正戏”阶段，负责跑测试、执行构建，对应咖啡店的“正式制作”环节。A 是 install 的职责，C 是开发者自己做的 push 操作，D 是 travis encrypt 命令的功能。

Q3. 关于 Travis CI 的构建矩阵，下列说法正确的有哪些？

多选题 · mid

  • A.矩阵作业数是各维度取值数量的乘积← 正确答案
  • B.矩阵中的作业默认串行执行
  • C.矩阵允许同时测试多版本多环境组合← 正确答案
  • D.快速失败机制会立即终止所有已完成的作业

答案：AC。A 正确，矩阵是笛卡尔积展开，作业数等于各维度数量相乘。B 错误，矩阵作业默认并行执行。C 正确，这就是矩阵的核心价值——像二十家分店同时试做新品。D 错误，快速失败终止的是“未完成”的作业，已完成作业的结果依然保留。

Q4. Travis CI 部署阶段中，skip_cleanup: true 的作用是什么？

单选题 · mid

  • A.跳过缓存清理以加速构建
  • B.保留构建产物以便部署上传← 正确答案
  • C.跳过测试直接进入部署阶段
  • D.防止部署后 Git 仓库被清空

答案：B。Travis 默认部署前会清理临时文件，skip_cleanup: true 告诉它“别扔打包好的产品”。这对应咖啡店“把新品礼盒留着别被保洁扔进垃圾桶”。A 与缓存无关，C 是危险行为，D 是对仓库的误解。

Q5. Travis CI 中，加密环境变量的推荐做法是哪一种？

单选题 · easy

  • A.直接在 .travis.yml 中明文写入
  • B.使用 travis encrypt 命令生成密文后放入配置← 正确答案
  • C.写在 GitHub README 中记录
  • D.通过 commit message 传递密钥

答案：B。B 是官方推荐：travis encrypt 生成密文，只有 Travis 云端能解密，对应“密码信封”机制。A 明文写入等于把保险柜密码贴墙上，C 比 A 更危险，D 完全错误——commit message 是会公开留存的。

Q6. 将 Travis CI 迁移到 GitHub Actions 时，正确的对应关系有哪些？

多选题 · hard

  • A.Travis 的 language 字段对应 Actions 的 runs-on 加 setup 动作← 正确答案
  • B.Travis 的 script 阶段对应 Actions 的 run 步骤← 正确答案
  • C.Travis 的矩阵展开对应 Actions 的 strategy.matrix← 正确答案
  • D.Travis 的加密变量完全无法在 Actions 中使用

答案：ABC。A 正确，language: python 在 Actions 中用 runs-on + actions/setup-python 实现。B 正确，script 阶段的命令对应 run 步骤。C 正确，Travis 隐式矩阵对应 Actions 的显式 strategy.matrix。D 错误，Actions 用 Secrets 功能实现加密变量且更安全。

Q7. Travis CI 中 on.tags: true 条件控制通常用于什么场景？

单选题 · mid

  • A.每次 push 都触发构建
  • B.只在打 Git tag 时触发部署← 正确答案
  • C.只在 PR 合并时触发测试
  • D.定时调度流水线运行

答案：B。on.tags: true 表示“只有打了 tag 才部署”，对应咖啡店“店长签字才正式上架”的策略。A 是默认行为，C 是 PR 触发，D 是 cron 定时功能，都与 tags 条件无关。

Q8. Travis CI 的换缓存机制中，当缓存命中率达到 100% 时，下列哪一项描述最准确？

单选题 · hard

  • A.构建时间趋近于零
  • B.依赖下载时间趋近于零，但实际构建仍需时间← 正确答案
  • C.测试一定全部通过
  • D.部署速度提升一倍

答案：B。缓存只解决“依赖获取”部分，就像咖啡店的常备库存只省掉“进货”环节——做咖啡本身的时间省不了。B 准确：下载时间趋近零，但 install 后仍需执行真实构建和测试，实际构建时间不变。

Q9. 关于 Travis CI 的快速失败机制，下列理解正确的有哪些？

多选题 · mid

  • A.任一作业失败时，未完成的作业可被取消← 正确答案
  • B.快速失败会撤销已完成的作业结果
  • C.它能节省矩阵的无效构建时间← 正确答案
  • D.它会让全部作业永远失败

答案：AC。A 正确，快速失败的核心是“止损”——某个作业已确定失败，没必要等其他作业跑完。B 错误，已完成作业的结果会被保留。C 正确，这就是它存在的意义。D 错误，它只影响未完成作业，不影响已出结果的作业。

Q10. Travis CI 的 deploy.provider 字段用于指定什么？

单选题 · easy

  • A.云服务商的认证方式
  • B.部署目标平台的类型← 正确答案
  • C.测试框架的版本
  • D.GitHub 仓库的可见性

答案：B。provider 声明“部署到哪”，可选 PyPI、S3、Docker Hub 等，对应“新品发布到哪个分销渠道”。A 是凭证管理，C 与部署无关，D 是仓库设置，都不属于 provider 的范畴。