企业官网建设流程全解析

• 教程
• 知识库

本文基于 tech-interview-for-developer 仓库中的 [Web/DevOps/[Travis CI] 项目联动指南](Web/DevOps/[Travis CI]%20프로젝트%20연동하기.md) 整理成文。文章围绕 Travis CI 与 GitHub 项目的联动全过程展开：先厘清 CI/CD 的概念边界，再逐步演示 Travis 网页端仓库激活、.travis.yml配置编写、push 触发自动构建，并给出构建无响应时的经典排错方案（仓库根目录与子目录项目两种布局）。读者学完后，可独立为一个 Gradle + Spring Boot 项目接入 Travis CI，实现"push 即自动测试、自动构建"的持续集成流水线，为后续接 AWS 部署脚本的无中断发布打下基础。

一、为什么需要 Travis CI：先理解 CI 与 CD

1.1 CI（Continuous Integration，持续集成）

代码版本管理的 Git 等系统中发生 PUSH 时，自动执行构建与测试，产出稳定可靠的部署文件的过程。

CI 的核心价值在于"把集成工作提前到每一天"。当多人协作时，如果每个人只在本地开发、隔很久才合并一次，冲突与回归问题会集中爆发。而接入 Travis CI 后，每一次 push 到目标分支都会触发一次干净的构建环境下的编译与测试，让质量问题在提交的当下就被发现。这正是仓库中 데브옵스(DevOps).md) 文档所强调的"持续集成：从初期就持续进行整合工作，不断施加软件质量管控"这一理念的工程化落地。

1.2 CD（Continuous Deployment，持续部署）

将构建产物自动、无中断地部署到运营服务器上的过程。

CD 与 CI 是流水线上的上下游关系：CI 负责"产出经过验证的构建物"，CD 负责"把构建物安全地送上服务器"。本仓库的 Web/DevOps/[AWS] Spring Boot 部署脚本生成 一文正是 CD 环节的典型实现——通过deploy.sh完成git pull、./gradlew build、jar 复制、旧进程 kill、nohup java -jar重启的整套无中断部署动作。将本文的 Travis CI 与那篇脚本串联起来，即可组成"push → CI 自动构建 → 触发脚本部署"的完整 DevOps 闭环。

1.3 定位：Travis CI 在流水线中的角色

Travis CI 是托管在云端的 CI 服务，与 GitHub 深度集成。它负责监控仓库事件（如 push、PR），按.travis.yml中声明的环境与命令在云端虚拟机里执行构建，并把结果反馈到 Travis 站点与邮件通知。开发者因此可以把精力聚焦在业务开发本身——这正是原文档开篇的宗旨："打造自动测试与自动构建的环境，让开发团队只专注于开发本身。"

二、Travis CI 网页端设置：登录与仓库激活

联动分两段：网页端激活仓库（告诉 Travis 去监听哪个仓库）+仓库内编写.travis.yml（告诉 Travis 构建怎么做）。

1. 访问 Travis CI 官网（https://www.travis-ci.com/），使用 GitHub 账号登录。登录过程本身即完成了一次 GitHub OAuth 授权，Travis 获得读取仓库的权限。
2. 进入Settings（设置）。
3. 在仓库列表中找到要接入 CI 的项目，打开该仓库的Repository 激活开关（Activate），让 Travis 开始监听此仓库的推送事件。

激活之后，Travis 只会对被监听仓库的 push/PR 事件做出响应；因此后续所有配置都围绕"该仓库根目录下的.travis.yml"展开。

三、项目内配置：编写 .travis.yml

网页端只能完成"激活"这一步，详细的构建规则必须通过 YAML 文件声明。对于 Gradle 项目，在build.gradle所在目录（即 Gradle 项目根目录）新建.travis.yml。

3.1 基础配置（项目根目录即仓库根目录的场景）

language: java jdk: - openjdk11 branches: only: - main # Travis CI 서버의 Home（Travis 服务器上的 Home 目录） cache: directories: - '$HOME/.m2/repository' - '$HOME/.gradle' script: "./gradlew clean build" # CI 执行完毕时发送邮件提醒 notifications: email: recipients: - gyuseok6394@gmail.com

3.2 关键配置项逐条解析

• language: java：声明构建语言类型。Travis 据此准备对应的基础镜像与工具链。该仓库技术栈以 Java 为主（如 Language 目录下的 Java 系列文档 所覆盖的 JVM、编译、Stream 等主题），Java 项目的language统一声明为java。
• jdk：指定 JDK 版本，支持多版本列表写法。示例使用openjdk11，即构建虚拟机内将安装 OpenJDK 11 作为编译与运行环境。列表写法允许声明多个版本让 Travis 逐一构建验证兼容性。
• branches.only：指定哪些分支的 push 会触发构建。示例只监听main分支，避免 feature 分支的临时提交也消耗构建配额、刷屏构建记录。若省略，默认所有 push 都会触发。
• cache：通过目录级缓存避免重复下载相同依赖。$HOME/.m2/repository是 Maven 本地仓库路径，$HOME/.gradle是 Gradle 缓存目录（含已下载的依赖与 wrapper 分发）。设置后，第二次及以后的构建可直接命中缓存，显著缩短构建时长——这是"同一个依赖不需要重复下载"的核心机制。
• script：分支被 push 后实际执行的命令。"./gradlew clean build"使用 Gradle Wrapper 执行"清理 + 构建"，clean保证构建从干净状态开始，避免增量构建掩盖问题。
• notifications：构建完成后的自动通知。示例为邮件通知，recipients列出收件人邮箱。CI 每次执行结束（无论成功失败）都会向该邮箱发送结果通知。

3.3 构建生命周期：script 只是其中一环

Travis 构建过程可视为一条流水线，常用阶段按顺序为：

本文下面即将介绍的before_script: cd {프로젝트명}/正是流水线中"构建前先切换目录"的标准用法。

3.4 触发与验证

.travis.yml创建完成后，将其与代码一起 push 到 GitHub。随后登录 Travis 站点，在对应仓库的构建记录中可以看到一次新的构建任务，状态为 running，最终变为 passed（成功）或 failed（失败）。点击构建可查看每一步的输出日志，script阶段的 Gradle 输出、测试报告、构建产物路径都可在日志中追溯。

四、经典故障排查：push 后 Travis 毫无反应

4.1 故障现象与根因

如果 push 之后 Travis 没有任何反应、不产生新的构建记录，大概率是因为当前项目的 GitHub 仓库并不位于仓库根目录——即"该仓库下又额外创建了文件夹，项目位于子文件夹中"的布局。

Travis 约定：.travis.yml必须位于被监听仓库的根目录。当项目位于子目录、而.travis.yml被放在了build.gradle所在的子目录时，Travis 在仓库根目录找不到配置文件，自然对 push 事件无动于衷。

4.2 解决方案 A：把 .travis.yml 移到仓库根目录

将.travis.yml从build.gradle所在位置移动到仓库根目录。此时文件与项目目录的对应关系为：

仓库根目录/ ├── .travis.yml ← 必须在这里 └── {프로젝트명}/ ← 实际 Gradle 项目（含 build.gradle） ├── build.gradle └── ...

4.3 解决方案 B：根目录配置 + before_script 切换目录

由于 Travis 默认以仓库根目录作为工作目录执行命令，而./gradlew位于项目子目录中，因此需要在执行构建前先进入项目目录，在仓库根目录的.travis.yml中追加before_script：

language: java jdk: - openjdk11 branches: only: - main # ------------新增部分------------ before_script: - cd {프로젝트명}/ # --------------------------------- # Travis CI 서버의 Home cache: directories: - '$HOME/.m2/repository' - '$HOME/.gradle' script: "./gradlew clean build" # CI 执行完毕时发送邮件提醒 notifications: email: recipients: - gyoseok6394@gmail.com

这里的cd {프로젝트명}/的作用是：把当前工作目录从仓库根目录切换到实际项目目录，使后续的./gradlew clean build能正确找到 Gradle Wrapper。{프로젝트명}需替换为实际的项目文件夹名。完整流程为：

1. Travis 检出仓库代码到工作目录（默认在仓库根目录）；
2. 进入before_script阶段，cd到项目子目录；
3. 进入script阶段，执行./gradlew clean build，触发自动构建与测试。

4.4 排查小结

五、延伸：从 CI 到 CD 的完整闭环

Travis CI 解决的是"push 后自动验证与构建"；而要真正发布到运营环境，还需要 CD 环节。本仓库的 Web/DevOps/[AWS] Spring Boot 部署脚本生成 给出了完整的思路：EC2 服务器上运行deploy.sh，依次执行git pull拉取最新代码、./gradlew build构建、cp build/libs/*.jar复制构建物、pgrep -f定位旧进程并kill -15优雅停止、最后nohup java -jar携带外部配置文件启动新版本。其中nohup保证 SSH 终端关闭后应用持续运行，-Dspring.config.location用于加载.gitignore排除的敏感配置（如application-oauth.properties）。

将两者组合，即可形成典型流水线：

本地 push → GitHub → Travis CI（.travis.yml 自动构建+测试） → 构建通过 → 触发/手动执行 deploy.sh → EC2 无中断部署

这与仓库中 Web/DevOps/시스템 규모 확장.md 所强调的"通过 CI/CD 自动化构建、测试、部署等验证流程，大幅提升开发生产力"的规模化实践方向一致；同时仓库 ETC/Git Commit Message Convention 中规范的提交信息（如feat:、fix:）也有助于在 CI 日志中快速定位每次构建对应的变更意图。

六、实践清单与注意事项

1. 目录即真相：无论项目在仓库根目录还是子目录，.travis.yml都放在仓库根目录；子目录项目必须用before_script的cd切换。
2. 分支策略：branches.only只列主干分支（如main），避免低价值提交消耗构建资源。
3. 缓存提速：Gradle 项目务必缓存$HOME/.gradle，Maven 项目缓存$HOME/.m2/repository。
4. 构建命令保持干净：./gradlew clean build从零构建，能暴露增量构建掩盖的编译与测试问题。
5. 通知配置：notifications.email.recipients按团队需要列出收件人，让构建结果第一时间触达责任人。
6. 注意适用前提：Travis CI 的 SaaS 定价策略、免费额度、构建环境镜像会随官方政策变化；示例中的 OpenJDK 11、main分支等均以本仓库文档写作时的实践为准，接入时应按实际项目与 Travis 官方文档核对。

参考与延伸阅读

• 本文主体来源：[Web/DevOps/[Travis CI] 项目联动指南](Web/DevOps/[Travis CI]%20프로젝트%20연동하기.md)
• CD 部署脚本实践：Web/DevOps/[AWS] Spring Boot 部署脚本生成
• DevOps 概念背景：Computer Science/Software Engineering/데브옵스(DevOps).md)
• 规模化部署与自动化理念：Web/DevOps/시스템 규모 확장
• 配合 CI 日志阅读的提交规范：ETC/Git Commit Message Convention

• 教程
• 知识库