Travis-Ci

在 Github 我的项目文件夹上面增加 .travis.yml 文件。 为了运行构建，Travis CI 的零碎将触发构建的存储库克隆到构建环境。 构建环境是一个隔离的虚拟机或 LXD 容器，一旦构建实现就会终止。 克隆仅在构建申请之后产生，因而仅实用于在 GitHub 设置中明确启用的存储库。 一个例子： 为了设置构建环境并筹备构建，Travis CI 的零碎从存储库和构建申请中明确指定的分支中获取并解决 .travis.yml 配置文件，由 GitHub 触发。 这个 .travis.yml 配置文件的语法在官网能够找到。 比方，dist: bionic 的意思是，构建虚构零碎的类型，bionic 是其中一个枚举值。 Travis CI 反对 Linux 构建的两种虚拟化类型：“Full VM”和“LXD”。 最重要的是，Linux 构建能够在多个 CPU 架构上运行。 Full VM 是启用 sudo 的，每个构建的残缺虚拟机，运行 Linux. 尽管启动迟缓（与 LXD 容器相比减少了构建工夫）但没有任何限度。 它调配了固定数量的 vCPU 和 RAM。 而 LXD 环境，尽可能靠近容器世界中的虚拟机。 Linux 环境在非特权 LXD 容器中运行。 和 Full VM 相比，其启动速度更快（与残缺 VM 相比缩小了构建工夫）但的确存在一些限度。 它从起码 2 个 vCPU 开始，如果有更多的计算工夫可用，主机能够动态分配它以放慢构建速度。 ...

解释 Travis CI 的最简略办法是，每次提交到 GitHub 时它都会运行程序的测试（这能够通过多种形式进行配置，并且您始终能够在某些分支上禁用构建）。 这样做的重点是，你通常能够很快发现你的提交是否毁坏了某些货色，并在它成为问题之前修复它。 我倡议在每个有单元测试的 GitHub 存储库上运行 Travis CI，并且应用 Travis CI 反对的编程语言。 因为设置 Travis CI 非常简单，我通常认为没有理由不应用它，除非您不在乎您的程序是否通过了测试。 Travis 的官网。 当您运行构建时，Travis CI 会将您的 GitHub 存储库克隆到一个全新的虚拟环境中，并执行一系列工作来构建和测试您的代码。 Jerry：因而在本地笔记本上执行这所有没有意义？ 如果其中一项或多项工作失败，则构建被视为损坏。 如果没有任何工作失败，则认为构建已通过，Travis CI 能够将您的代码部署到 Web 服务器或应用程序主机。 CI 构建还能够自动化交付工作流程的其余局部。 这意味着您能够应用 Build Stages 使作业相互依赖、设置告诉、在构建后筹备部署以及许多其余工作。 在 Travis CI 文档中，一些常用词有特定的含意： build：一组按程序运行的作业(jobs)。 例如，一个构建可能有两个作业(job)，每个作业都应用不同版本的编程语言测试一个我的项目。 当它的所有工作实现时，构建就实现了。下图是 Travis 上 build 的一个例子： stage：作为由多个阶段组成的程序构建过程的一部分并行运行的一组作业。stage 的例子。 job：将您的存储库克隆到虚拟环境中的自动化过程，而后执行一系列阶段，例如编译代码、运行测试等。如果脚本阶段的返回代码非零，则作业失败。这一点和 Linux API 的返回值设计很像。job 的一个理论例子： phase：作业的间断步骤。 例如，装置阶段在脚本阶段之前，在可选的部署阶段之前。更多Jerry的原创文章，尽在："汪子熙":

前言开源社区里，开源我的项目个别会将一排花花绿绿的 badge（徽章）摆在 README 最显眼的地位，它们个别能够起到一些阐明和证实的作用。比方上面的这个我的项目（传送门）： 第一个 badge 证实其能失常构建，点击跳转至构建过程报告；第二个 badge 证实其测试覆盖率达到100%，点击跳转至单元测试报告；第三个 badge 阐明其是 MIT 受权协定；第四个 badge 阐明其最小化后包的大小； 别以为他们只是图片，正规的我的项目是随我的项目更新而更新的，点击不了或者点击进入的不是对应我的项目的报告都能够算作伪造，请远离这些我的项目。下面提到的 badge 中前两个能够算是我的项目可靠性的证实，是比拟有份量的 badge，接下来咱们将指引大家如何自动化增加这两 badge。 留神：本文以 Github 为代码仓库，第三方帐号受权都以 Github 帐号进行，请确保本身网络环境能失常拜访；不波及我的项目自身的构建和测试。 筹备编写一个我的项目，在 package.json 中以“build”为构建命令，dist 为打包后输入的目录；编写好该项目标单元测试，在 package.json 中以“test:prod”为测试命令，并且会主动在 coverage 目录下生成覆盖率报告；为我的项目装置 devDependencies（开发依赖）： coveralls注册一个 Github 帐号，提交我的项目到一个仓库。Travis 配置Travis CI 提供的是继续集成服务（Continuous Integration，简称 CI）。它绑定 Github 下面的我的项目，只有有新的代码，就会主动抓取。而后，提供一个运行环境（容器），执行测试，实现构建，还能主动部署到服务器。本次的自动化就是依附这个服务实现的，这里只展现相干的配置，更多的用法请自行查看文档。 新建配置文件在我的项目根目录下新建 .travis.yml 文件，输出上面配置并保留。 language: node_jscache: npmnotifications: email: falsenode_js: - '10'script: - npm run test:prod && npm run buildafter_success: - npm run report-coveragebranches: except: - /^v\d+\.\d+\.\d+$/配置阐明： ...

前言本文次要讲如何用 Travis 来实现自动化部署，并参照 Github 实在我的项目开发简略场景来介绍。 CI/CD在说 Travis 之前，先理解一下 CI/CD 的概念。 CICI（Continuous integration）—— 继续集成。继续集成是指频繁地（一天屡次）将代码集成到骨干，重视将各个开发者的工作汇合到一个代码仓库中，在源代码变更后会自动检测、拉取、构建和进行单元测试，其目标在于让产品疾速迭代，同时保障高质量。 比方日常工作中，向development分支提交一个 PR，配置好 Travis 就会进行自动测试等等工作，通过并被 review 后能力容许合并到开发分支。一旦自动测试脚本有谬误，则不容许合并。 CDCD 可对应多个英文名称，一个是继续交付（Continuous delivery），一个是继续部署（Continuous deployment）。 继续交付指频繁地将软件的新版本交付给品质团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。指标是领有一个可随时部署到生产环境的代码库。益处在于，每次代码的小幅变更，就能看到运行后果，从而一直累积小的变更，而不是在开发周期完结时，一下子合并一大块代码。 继续部署指继续交付的下一步，指的是代码通过评审当前，主动部署到生产环境。指标是代码在任何时刻都是可部署的，能够进入生产阶段。 继续交付并不是指软件每一个改变都要尽快部署到产品环境中，它指的是任何的代码批改都能够在任何时候施行部署。 继续交付示意的是一种能力，而继续部署示意的则一种形式。继续部署是继续交付的最高阶段 Travis 是什么Travis CI 提供的是继续集成服务，它能够绑定 Github 下面的我的项目，只有有新的代码，就会主动抓取。而后，提供一个运行环境，执行测试，实现构建，还能部署到服务器。当然这只是其中一种 CI 工具，另外还有Jenkins等。 本文仅仅做的抛砖引玉，让你对这些概念和 Travis 有初步理解和应用，不再生疏，残余的就靠你本人去学习了。兴许你感觉这是公司企业级我的项目才配上的货色，但其实 Travis 是收费的，集体开发者也能够进行应用，而且是挺好用。 注册 Travis进入https://travis-ci.com， 比方我抉择 Github 形式登录 登录之后 Github 的 repo 受权给 travis，我间接选 All，开启对我的项目的监控 选完之后回到主页就能看到你的仓库页面了，能够看到有一个我的项目我是配置了 travis 的，所以显示绿色状态。 这我的项目是最近在本人动手做的 React 组件库我的项目 monki-ui，尽量参照企业级规范搭建的，技术栈是React + TypeScript + Dumi + Jest，感觉不错可供借鉴学习的话能够 ✨ star 一下哦... ...

前言如果你手动部署过项目，一定会深感持续集成的必要性，因为手动部署实在又繁琐又耗时，虽然部署流程基本固定，依然容易出错。 如果你很熟悉持续集成，一定会同意这样的观点：“使用它已经成为一种标配”。 什么是持续集成Continuous Integration(CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.———ThoughtWorks 翻译过来就是：持续集成是一个开发行为，它要求开发者每天多次将代码集成到一个共享的仓库，每次提交都会被自动构建所检查，团队可因此提前检测出问题。持续集成的工具非常多，例如用java语言开发的Jenkins，由于其可以在多台机器上进行分布式地构建和负载测试的特性，很多大公司都在使用它。 但是Jenkins的不加修饰的界面界面让我有些嫌弃... 随着GitHub的发展，出现了越来越多支持GitHub的CI/CD产品。在GitHub市场上，可以看到，已经支持的持续集成服务提供商已超过300多家（详情）。 选择Travis CI，是因为身边很多朋友的推荐。 下面分享一下我是如何利用Travis CI+GitHub实现持续集成和自动部署的，通过我的一些研究和实战经验，希望可以帮到有需要的朋友。 什么是Travis CITravis CI是用Ruby语言开发的一个开源的分布式持续集成服务，用于自动构建和测试在GitHub托管的项目。支持包括Javascript、Node.js、Ruby等20多种程序语言。对于开源项目免费提供CI服务。你也可以买他的收费版，享受更多的服务。 Travis CI目前有两个官网，分别是 https://travis-ci.org 和 https://travis-ci.com 。https://travis-ci.org 是旧平台，已经逐渐往新平台 https://travis-ci.com 上迁移了。对于私有仓库的免费自动构建，Travis CI在新平台上给予了支持。 一、获取GitHub Access TokenTravis CI在自动部署的时候，需要push内容到仓库的某个分支，而访问GitHub仓库需要用户授权，授权方式就是用户提供 Access Token 给Travis CI。 ...

Github travis-ci CI CDCICD 是 持续集成Continuous Integration和持续部署Continuous Deployment简称。指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。 本文主要介绍一下 travis-ci 持续集成和给 github Actions Travis-cihttps://www.travis-ci.org/1.登录travis-ci通过 github账号登录,会自动同步你的仓库 选择需设置的仓库 先勾选一个测试仓库 3 设置一些解释说明可以看具体的文档,主要包括这几方面 添加.travis.ymlTravis-ci 构建的生命周期 具体一些步骤可以查看文档. 这个文件主要是告诉 Travis CI 应该做什么,以前端node.js为例: language: node_js # 语言设置node_js: # node 版本 - "8"# npm现在默认缓存，如果您要禁用它，请将以下内容添加到您的.travis.yml：cache: npm: false before_install: # 安装前 - npm installscript: - npm run build如果当前目录存在yarn.lock可以使用 Yarn; 如果当前目录中都存在package.json和yarn.lock，则运行以下命令而不是 npm install 具体的一些配置,通过查看文档即可; 现在已经构建成功; 发布部署如果每次构建完都自动部署,或者手动部署可以再下一步; language: node_jsnode_js: - "8"before_install: - yarn installscript: - yarn build after_script: - cd ./dist - git init - git config user.name "${U_NAME}" - git config user.email "${U_EMAIL}" - git add . - git commit -m "Update tools" - git push --force --quiet "https://${GH_TOKEN}@${GH_REF}" master:${P_BRANCH}#指定分支，只有指定的分支提交时才会运行脚本branches: only: - master发布的是 github page 博客. ...

原文链接：用 Travis CI 自动部署 Github Pages 前言Github Pages 不能运行动态程序，只能输出一些静态内容。因此 Github Pages 非常适合用于前端项目的展示。可用于存放项目介绍、项目文档或者个人博客。本文介绍了怎么用 Travis CI 自动化部署 Github Pages。 关于 CI持续集成（Continuous integration）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。目前 github 开源项目用的较多的 CI 主要是 Circle CI 和 Travis CI，两者都是利用容器技术来适配不同项目环境。 (图一 CIrcle CI，图二 Travis CI) 步骤1. 安装 Github App在 Github Market Place 安装 Travis CI。安装时选择你想要的项目权限。<img src="https://s2.ax1x.com/2019/05/0...; width="50%" alt="ENCylT.png" title="ENCylT.png" /> 2. 配置 Github Token配置 Github Token 用于 Travis CI 对你项目的访问权限，配置完了之后 不要刷新页面，先点一下 Token 后面的复制按钮，因为你只能看见这个 Token 一次，刷新了它就没了 不得不赞一下 Github 的安全性 :+1: ...

很早之前我就在用 Travis CI 做持续集成了，虽然只是停留在 zhuang bi 的阶段，但或多或少也保证了代码的提交质量。最近在写一个 《JavaScript API 全解析》系列的 Book，需要经常把文章部署到服务器上，手动部署实在是烦，索性花了一天时间研究了一下自动化部署。这篇文章是对 Travis CI 持续集成和自动化部署的总结，以飨社区。前戏Travis CI 目前有两个网站，一个是 travis-ci.com，另一个是 travis-ci.org. 前者用于企业级和私有仓库，后者用于开源的公有仓库。实际上 free plan 也可以使用 travis-ci.com，但优先级很低，跑个自动化动辄两个小时，因此我们使用 travis-ci.org.首先打开 Travis CI 官网，并用 GitHub 账号登录，授权后 Travis CI 会同步你的仓库信息。接下来把需要做自动化的工程授权给 Travis CI.最好有一台 Linux 的服务器，我的是 Cent OS 7.6.x 64bit.我们点开一个工程，再切到设置，可以看到在 push 代码和 PR 时都会触发持续集成，当然可以根据需求手动配置。持续集成为了让持续集成像那么回事儿，我们先在 master 上切一个 develop 分支，再在 develop 上切一个 featur/ci 分支。接着我们再用 Jest 写几个测试用例，注意如果项目中没有测试脚本而 .travis.yml 文件里面包含 yarn test，自动化 一定 报错。关于 Jest 这里不详细说，只贴出几个示例代码。import * as utils from ‘../utils/util’;test(‘should get right date’, () => { expect(utils.formatJSONDate(‘2019-03-10T04:15:40.629Z’)).toBe( ‘2019-03-10 12:15:40’, );});test(‘should get right string’, () => { expect(utils.upperFirstLetter(‘AFTERNOON’)).toBe(‘Afternoon’); expect(utils.upperFirstLetter(‘YANCEY_LEO’)).toBe(‘Yancey Leo’);});然后我们在工程的根目录下新建一个文件 .travis.yml，并复制下面的代码。language: node_jsnode_js: - 8branchs: only: - mastercache: directories: - node_modulesinstall: - yarn installscripts: - yarn test - yarn build简单解释一下，工程使用 Node.js 8.x，并且只在 master 分支有变动时触发 自动化部署（正常的提交、PR 都会正常走持续集成），接着将 node_modules 缓存起来（你懂的），最后安装依赖、跑测试脚本、在沙箱部署。因此，理论上只要跑通这套流程，我们就可以放心的部署到真实环境了。提交一下代码，并 pull request 到 develop 分支。在此过程中我们触发了 push 和 PR，所以会跑两个 CI。待到两个都成功跑完后，我们就可以放心的合到 develop 分支了。（这里我还做了代码质量检测，有兴趣可以戳 Codacy）最后我们回到 Travis CI 的官网，可以看到一套完整的构建流程：安装依赖 -> 测试 -> 沙箱部署持续部署创建 rsa 对，并给予权限首先登录你的服务器，一般来讲我们不会直接在 root 上操作，所以这里新增一个 caddy 的用户 。具体怎样在 Linux 新建用户请自行谷歌。接下来 cd 到 ~/.ssh，看看有没有一对 id_rsa 和 id_rsa.pub，如果没有就用 ssh-keygen 生成。给予 .ssh 文件夹 700 权限，给予 .ssh 里的文件 600 权限。（看下面这张图，你的文件夹里可能暂时没有 authorized_keys、 known_host、config 这三个文件，后面会说到。）$ sudo chmod 700 ~/.ssh/$ sudo chmod 600 ~/.ssh/将生成的公钥添加到受信列表进入到 .ssh 文件夹里，执行下面的命令，可以看到公钥被添加到受信列表。$ cat id_rsa.pub >> authorized_keys$ cat authorized_keys测试登录在 .ssh 目录下创建一个文件 config，输入如下代码并保存。Host testHostName 当前服务器的IPUser 当前用户名IdentitiesOnly yesIdentityFile ~/.ssh/id_rsa因为 authorized_keys 和 config 文件都是新增的，它们还没被赋予 600 权限，所以重新执行一遍 sudo chmod 600 ~/.ssh/.然后我们输入 ssh test，不出意外会重新登录 ssh。如果你的公钥从来没有被使用过，会提示 Are you sure you want to continue connecting (yes/no)? ，输入 yes 后也会正常重新登录，并且在.ssh 文件夹下还会生成一个 known_hosts 文件.安装 Ruby因为 Travis 客户端是用 Ruby 写的，所以我们得先安装 Ruby.首先安装需要的依赖包：$ yum install gcc-c++ patch readline readline-devel zlib zlib-devel \ libyaml-devel libffi-devel openssl-devel make \ bzip2 autoconf automake libtool bison iconv-devel sqlite-devel接下来安装 RVM，并载入 RVM 环境。RVM 是 Ruby 的版本管理工具，类似于 Node 的 NVM.$ gpg –keyserver hkp://keys.gnupg.net –recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3$ \curl -sSL https://get.rvm.io | bash -s stable# 载入 rvm 环境$ source ~/.rvm/scripts/rvm安装完之后输入 rvm -v 做下检查，如果有 rvm 1.29.1 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io/] 的字样证明安装成功。最后安装 Ruby，这里选择 v2.4.1 版本，安装需要一段时间，完成后记得将此版本设为默认。$ rvm install 2.4.1$ rvm 2.4.1 –default执行一下 ruby -v 和 gem -v，如果和下图差不多证明安装成功。安装 Travis 客户端执行下面的命令以安装 Travis 客户端。$ gem install travis安装完成后执行 travis，它会让你安装相应的 Shell, 输入 yes 即可。配置免密登录将你的工程克隆下来，并进入到工程目录，然后登录你的 GitHub 账号。$ travis login –auto执行下面这句，它会利用服务器的私钥加密成一个叫做 id_rsa.enc 的文件，这个文件被用于 travis 登录你服务器的凭证，从而达到免密的目的。$ travis encrypt-file ~/.ssh/id_rsa –add我们执行一下 ll，可以看到根目录下多出一个 id_rsa.enc 文件来，并且 cat .travis.yml，发现多出了 before_install.为了更好地组织代码，我们在项目的根目录新建一个文件夹 .travis，然后将 id_rsa.enc 放到里面。配置 after_success 钩子在写这一小节之前，我们先看一看 Travis 的生命周期：before_install 安装依赖前install 安装依赖时before_script 执行脚本前script 执行脚本时after_success 或 after_failure 执行脚本成功（失败）后before_deploy 部署前deploy 部署时after_deploy 部署后after_script 执行脚本后因此 after_success 可用在成功通过测试脚本之后执行部署相关的脚本。当然细一点可以使用 deploy 相关的钩子，这里不做太复杂。打开 .travis.yml文件，直接上全部代码。language: node_jssudo: truenode_js: - 8branchs: only: - master# 这里填写服务器的ip，若端口号不是22，后面要注明端口号addons: ssh_known_hosts: - 你的服务器IPcache: directories: - node_modulesbefore_install: # 因为我们把 id_rsa.enc 移到了.travis 文件夹下，所以 -in 后面要改成 .travis/id_rsa.enc # 其次，-out 后面自动生成的是 ~/.ssh/id_rsa，要把 \ 去掉，否则会编译失败 - openssl aes-256-cbc -K $encrypted_XXXXXXXXXXXX_key -iv $encrypted_XXXXXXXXXXXX_iv -in .travis/id_rsa.enc -out ~/.ssh/id_rsa -d # 开启 ssh-agent，即允许使用 ssh 命令 - eval “$(ssh-agent -s)” # 给予 id_rsa 文件权限，避免警告 - chmod 600 ~/.ssh/id_rsa # 将私钥添加到 ssh - ssh-add ~/.ssh/id_rsainstall: - yarn installscripts: - yarn test - yarn buildafter_success: # 登录服务器，执行部署脚本，其实最好把后面一串写成 shell 文件 - ssh caddy@你的服务器IP -o StrictHostKeyChecking=no ‘cd /var/www/jsapi/JavaScript-APIs-Set && git pull && yarn install && yarn build’走一遍正式的流程至此，搭建 Travis CI 持续集成和自动化部署就算完成了，可能不太严谨，但基本是这么一个思路。下面我们梳理一遍流程。我们先在 feature/ci 分支修改一段代码，提交分支，并 PR 到 develop，此时会运行两个 CI。当两个 CI 都跑通了，我们可以放心的 merge request 到 develop 分支。接下来让 develop PR 到 master，此时会运行两个 CI（一个是 develop 分支，一个是测试合并到 master 的 CI）。当两个 CI 都跑通了，我们可以放心的 merge request 到 master 分支。merge request 之后会跑最后一个流程, 也就是自动部署，部署成功后线上代码就会更新了。加入徽章别忘了把 build passing 徽章添加到你的 README.md 文件中。最后不知道你有没有发现，Travis CI 支持 LGBT…以上、よろしく。参考How to Encrypt/Decrypt SSH Keys for DeploymentTravis-CI 自动化测试并部署至自己的 CentOS 服务器CentOS 7 使用 rvm 安装 ruby 搭建 jekyll 环境 ...

最近研究nuxt服务端渲染的时候，看到nuxt的几种部署方式，因为nuxt打包的静态文件可以直接放在GitHub上面，然后 TravisCI跟GitHub又很亲切，就选择了TravisCI部署。然后就走上了研究TravisCI的不归路。Travis CI 部署到GitHub项目gh-pages分支上，打开页面发现引用资源404？在研究nuxt的这一篇文章 《如何部署至GitHub Pages？》的时候，所有操作都按照文章提示来，发现怎么部署都失败，然后仔细看自己页面资源引用的路径，并没有实现文章中的router base 的路径配置。router: { base: ‘/<repository-name>/’}然后自己反复上传验证，终于发现问题。在官网给出的TravisCI配置中：language: node_jsnode_js: - “8"cache: directories: - “node_modules"branches: only: - masterinstall: - npm install - npm run generate # 这个需要改为npm run generate:gh-pagesscript: - echo “Skipping tests"deploy: provider: pages skip-cleanup: true github-token: $GITHUB_ACCESS_TOKEN # Set in travis-ci.org dashboard, marked secure https://docs.travis-ci.com/user/deployment/pages/#Setting-the-GitHub-token target-branch: gh-pages local-dir: dist on: branch: master需要把install中的 npm run generate 改为npm run generate:gh-pages，这样就可以走gh-page分支的打包了。不知道是不是还有别的解决方法，刚接触也不是特别了解。Travis CI 如何部署服务器？可以参考这篇文章Travis CI 自动化部署博客Travis CI 部署服务器如何实现免密登录？搞完GitHub Pages静态部署，然后就想部署服务端，毕竟接触nuxt的目的就是实现服务端渲染。然后找了一个比较坑的文章… 每次Travis部署后，都要求输入一个密码。卡在了免密登录的地方卡了很久很久… 在此多谢 @X1nFLY 的帮忙，很耐心的帮我解决了问题。其实免密登录跟trvais并没有什么关系，原理就是私钥公钥的加密解密（有兴趣可以自行去搜索），只要你本地 ssh连接实现免密登录，那Travis部署也可以的。需要在终端输入：ssh-copy-id username@your-server-ipssh-copy-id 将本机的公钥复制到远程机器的authorized_keys文件中，ssh-copy-id也能让你有到远程机器的home, ~./ssh , 和 /.ssh/authorized_keys的权利，这时候只要你终端输入:ssh username@your-server-ip再次连接就不用再输入密码啦Travis CI 部署怎么启动 nuxt服务，node服务？下面到了最关键的时刻，部署成功后after_success:怎么处理？对于一个前端（没怎么接触过后台）来说，确实一脸懵逼，要操作 一些常用Linux命令。下面我就总结几个我碰到的：部署nuxt静态资源到服务器。因为nuxt静态资源是打包到 /dist 文件夹下的，所以我们只需要把/dist文件夹 拷贝到服务端对应的文件夹即可。after_success:- rsync -az –delete ./dist/* root@123.123.123.123:/data/html/nuxt # copy dist文件夹下的所有文件部署nuxt服务端渲染应用到服务器。打包对应文件夹是.nuxt 文件，但是需要服务端启动服务，所以需要安装各种依赖以及启动配置。所以需要将 .nuxt nuxt.config.js package.json static 文件或文件夹都拷贝到服务器上，并对其安装依赖，启动服务。after_success:- rsync -az –delete .nuxt nuxt.config.js package.json root@47.99.102.212:/data/ssr- ssh root@123.123.123.123 ‘cd /data/ssr/ && npm install && npm run start’部署node应用服务器。after_success:- ssh root@123.123.123.123 ‘cd /data/node/ && git pull && npm install && npm run prd’ ...

作者: 一波不是一波转载请注明出处并保留原文链接（ https://github.com/riskers/bl… ）和作者信息。这篇文章教你怎么用 gitbook + travis 在 github pages 上优雅地发布书籍。模板: https://github.com/riskers/gi…效果: https://riskers.github.io/git…项目结构git clone https://github.com/riskers/gitbook-templatecd gitbbok-template && rm -rf .git # 去掉模板中的历史记录修改模板:.travis.yml:recipients: 修改成你的邮件REF: 修改你项目的 github 地址book.json: 修改 gitbook 相应配置，不是这里的重点，不多介绍。配置结果见 https://riskers.github.io/git…，可根据喜好自己修改chap01 和 chap02 对应 SUMMARY.md 中的地址，就是这本书的内容了。然后就是在 github 上新建一个项目，并且 push 上去，然后你能看见这样的项目结构:github pages如果没有注册过 github pages 服务，还要先注册（注册过程略）。新建 gh-pages 分支:git checkout -b gh-pagesgit push origin gh-pages在项目『Settings』-> 『GitHub Pages』开启 github pages 服务:<img src=“https://i.imgur.com/mLt9b1L.j...; width=“300” />Travis给这个项目开启 Travis 服务: https://github.com/marketplac…最后你应该能看到这个界面:在个人设置里申请 token 好让 Travis 有权限改这个项目：然后选择 repo，点击生成按钮:复制生成的 token，填写在 Travis 的设置-全局变量中，并且取名为 TOKEN:试试效果添加一行字:然后 push 上去，可以看到 Travis CI 在跑了:稍作等待，跑完之后，可以在 gh-pages 下看到 Travis CI 给我们推过来了 gitbook build 之后的内容:可以在 github pages https://riskers.github.io/git… 上看到效果: 完成！后续这一阵在用 gitbook 写一本电子书，发现多于两本就要收费了，而老版本是不收费的，所以我最近一直在用老版本。但可能是维护少的原因，老版本的同步总是不及时，于是我放弃了 gitbook 服务。本来想在本地 gitbook build，然后 push 到 pages 服务，但是这样太不优雅了，就琢磨了一下怎么用 CI 来做这件事，刚好之前在公司折腾过一阵 gitlab ci，很快就解决了。至此，我做到了在 master 上写 md，然后 push 到 master， Travis 自动执行 gitbook build，并且把生成好的文档 push 到 gh-pages，好让 pages 服务生效。向我捐助 | 关于我 | 工作机会 ...

本文首发于：https://y0ngb1n.github.io/a/5…什么是 Travis CI？Travis CI 是在软件开发领域中的一个在线的，分布式的持续集成服务，用来构建及测试在 GitHub 托管的代码。这个软件的代码同时也是开源的，可以在 GitHub 上下载到，尽管开发者当前并不推荐在闭源项目中单独使用它。它提供了多种编程语言的支持，包括 Ruby、JavaScript、Java、Scala、PHP、Haskell 和 Erlang 在内的多种语言。许多知名的开源项目使用它来在每次提交的时候进行构建测试，比如 Ruby on Rails，Ruby 和 Node.js。目前 Travis CI 两个站点，提供不同的服务：版本主页特色免费版https://travis-ci.org/为开源项目提供免费服务收费版https://travis-ci.com/可以部署 GitHub 私有仓库两个站点只能看到各自的项目，不能通用，按需选用。准备工作首先，访问官方网站 travis-ci.org，点击右上角的登入按钮，使用 GitHub 账户登入 Travis CI。Travis 会列出 GitHub 上面你的所有仓库，以及你所属于的组织。此时，选择你需要 Travis 帮你构建的仓库，打开仓库旁边的开关。一旦激活了一个仓库，Travis 会监听这个仓库的所有变化。<p align=“center”> <img src=“https://i.loli.net/2019/01/17...; alt=“travis github repo”></p>.travis.ymlTravis 要求项目的根目录下面，必须有一个 .travis.yml 文件。这是配置文件，指定了 Travis 的行为。该文件必须保存在 GitHub 仓库里面，一旦代码仓库有新的 Commit，Travis 就会去找这个文件，执行里面的命令。.travis.yml：language: node_js # 指定语言环境node_js: ‘8.9.3’ # 指定 NodeJS 版本cache: npm # 指定 npm 缓存方案，会缓存 $HOME/.npm 或 node_modules 文件夹dist: trusty # 指定系统版本，trusty 是指 Ubuntu 14.04 发行版的名称sudo: required # 是否需要 sudo 权限branches: # 指定要构建的分支 only: # only 表示只构建以下分支 - sourcebefore_install: # install 阶段之前执行 - npm install -g hexo-cli # 全局安装 Hexo 命令行工具install: # 在安装项目环境阶段需要运行的命令，一条一行，类似的还有 before_install - npm install # 安装 package.json 中的依赖script: # 在构建阶段需要运行的命令，一条一行，类似的还有 before_script、after_script - hexo clean - hexo generate # Hexo 常规命令，执行清理和生成after_success: # script 阶段成功时执行，构建失败不会执行，其他同上 - git config –local user.name “travis-ci” - git config –local user.email “deploy@travis-ci.org” - sed -i’’ “s~git@github.com:https://${GITHUB_REPO_TOKEN}@github.com/” _config.yml - hexo deploy > /dev/null # 通过 Hexo 的 deploy 命令部署博客更多使用技巧请主动参考「持续集成服务 Travis CI 教程」。那么，现在又有一个问题了：我们的目是自动部署到 GitHub Pages，用的是 hexo deploy 命令，但是 Hexo 又配置使用的是 Git push 来推送的（由 hexo-deployer-git 插件提供技术支持），那么 Travis CI 怎么有权限操作我的 GitHub 仓库呢！GitHub Access Token以下内容摘抄「使用 Travis 自动构建 Hexo 到 GitHub」GitHub 允许你通过设置页面添加一个「个人访问令牌（Personal access tokens）」，使用 Assess Token 将有权限通过 https 访问 GitHub Api 操作自己的仓库，可见这个就是我们需要的。现在我们来添加一个 token，先进入自己 GitHub 的设置页面，点击 Personal access tokens → Generate new token 按钮，新建一个 token。在权限设置中，我们只需要操作仓库，因此只需要打开仓库相关的权限就够了，权限开放应该满足最小原则，能少就少。设置好权限后点击生成按钮就会生成完毕并跳到 tokens 列表。现在就需要把刚生成的 Access Token 的值复制下来，注意，这个页面一旦刷新过了， token 就不能再显示了，没记住的只能重新生成一个了。嗯，现在 Access Token 也有了，能操作仓库了，那么，这个 token 应该放到哪里呢？肯定不是放到代码里。。。其实在 Travis CI 的项目设置界面就有提供设置环境变量，我们就应该把 token 放到那里。回到我们 Travis CI 的博客项目设置页面中，添加一个名为 GITHUB_REPO_TOKEN 的环境变量储存我们的 token，并记得要设置 Display value in build log 为 OFF，关闭变量的显示，否则等于公开了 token。现在在我们的执行脚本中就能使用 $GITHUB_REPO_TOKEN 访问 token 的环境变量了~然后就是如何使用了。在 Hexo 部署前，我们应该把原来的部署仓库地址用带有 Access Token 的地址替换掉，于是在 .travis.yml 的 hexo deploy 命令前增加一条命令：sed -i’’ “s~git@github.com:https://${GITHUB_REPO_TOKEN}@github.com/” _config.yml这样，在执行时，这条命令就能自动替换到有权限操作的 token 地址了，并且也不会泄露或者影响本地的原始配置文件。构建失败：子模块拉取失败本博客的第三方主题使用 git submodule 管理，可以翻看「Hexo 搭建个人博客 #04 主题的安装与自定义样式」详细的构建日志可见 #1，下面提取关键信息：$ git submodule update –init –recursiveSubmodule ’themes/skapp’ (git@github.com:Mrminfive/hexo-theme-skapp.git) registered for path ’themes/skapp’Cloning into ‘/home/travis/build/y0ngb1n/y0ngb1n.github.io/themes/skapp’…Warning: Permanently added the RSA host key for IP address ‘192.30.253.113’ to the list of known hosts.Permission denied (publickey).fatal: Could not read from remote repository.Travis CI 官方是默认支持 Git Submodules，在拉取仓库时会默认拉取子模块的仓库，可以手动关闭该特性。由于在使用 git submodule 时，添加了 git@github.com 的仓库地址，使用 SSH 的协议，所以拉取失败了，下面提供两个解决方案：Adding to SSH Known Hosts - 官方提供的解决方案手动修改 .gitmodules 里配置的仓库地址，将使用 git 协议的仓库链接改为 https 协议我这使用方案 2，修改为https 协议：[submodule “themes/skapp”] path = themes/skapp url = https://github.com/Mrminfive/hexo-theme-skapp.git将修改推送至 GitHub 后，Travis CI 会进行构建，此时可见 #2 成功构建了。在 README 中查看构建状态我们可以在 README 中添加 Travis CI 的构建状态，这样便可方便地查看项目在 Travis CI 上的构建状态。—— Embedding Status Images、Shields.io参考资料Travis CI Tutorial - @Travis CI Docs持续集成服务 Travis CI 教程 - @阮一峰Travis CI 持续集成 GitHub 个人博客 - @路家豪使用 Travis 自动构建 Hexo 到 GitHub - @zthxxx开箱即用，Hexo 博客的 github+server 自动部署 - @伍酱用 Travis CI 自动部署 Hexo 博客 - @Karl使用 Travis CI 自动部署 Hexo 博客 - @wshunliHexo 遇上 Travis-CI：可能是最通俗易懂的自动发布博客图文教程 - @MichaelXHexo+Github+Travis-ci 搭建程序员自己的博客 - @baiyangliu ...

上一篇简单介绍了 Travis CI, 这里再简单介绍一个应用，利用Travis CI的Cron Jobs功能，实现自动备份segmentfault文章到Github。第一步：抓取文章内容Segmentfault 非常友好的为每个专栏提供了一个RSS，我们很方便就可以抓取到文章内容，稍做转化就可以了，省略不写，详见代码第二步：配置 SSH keysGithub 上有详细的说明，省略不写，敬请查看第三步：编写.travis.yml 配置我们采用git命令行提交commits的方式备份文章。要实现自动提交，需要把私钥也和代码一起上传，但是私钥泄漏相当于放弃了仓库的所有权，所以需要对私钥进行加密。（这是个比较麻烦的方法，但是实际上开发中我们部署代码到自己的服务器常用的也是 ssh 远程操作，有借鉴意义）1.安装 travis我们通过 Ruby 的 gem 包管理器来安装 travis, 如果未安装 Ruby,先下载最新版本，并安装它，然后执行如下命令确认 gem 是否安装成功gem -v能够正常列出版本号，表示安装成功因为众所周知不可说的原因，在安装包时，使用官方源地址会非常慢。我们切换成国内的镜像gem sources –add https://gems.ruby-china.com/ –remove https://rubygems.org/ # 老版本 Ruby 这里会证书相关的错误，所以确认安装了最新版本gem sources -l #确保列出的源地址只有镜像地址准备工作做好了，我们执行如下命令安装gem install travis2.登录 Travis CItravis login –auto执行命令，根据提示输入 github 的用户名和密码。这里有个坑，window 用 cmd 操作时死活不好使，如果你在输入密码时显示的明文，那么恭喜你也踩坑了，你可以改用 power shell 来操作，不过后面还是会遇到一些莫名其妙的问题，建议在 inux 环境下操作，哪怕是虚拟机也行。3.填加私钥执行如下命令travis encrypt-file ~/.ssh/id_rsa –add实际使用中很有可能会报错Can’t figure out GitHub repo name. Ensure you’re in the repo directory, or specify the repo name via the -r option (e.g. travis <command> -r <owner>/<repo>)这个的意思是找不到仓库，需要指定，可以这么操作travis encrypt-file -r actors315/actors315.github.io ~/.ssh/id_rsa –add执行完成后，在 .travis.yml 文件中会自动填加如下代码openssl aes-256-cbc -K $encrypted_xxxxxx_key -iv $encrypted_xxxxxxx_iv -in .travis/id_rsa.enc -out ~/.ssh/id_rsa -d并生成一个 id_rsa.enc 文件，你可以手动移到合适的目录，并调整上面命令文件的位置并在 Travis CI Setting 页面会看到增加了如下两个变量如果在 windows 下生成的文件，travis-ci 构建时很可能会报这个错。0.02s$ openssl aes-256-cbc -K $encrypted_2805aa35fedb_key -iv $encrypted_2805aa35fedb_iv -in .travis/id_rsa.enc -out ~/.ssh/id_rsa -dbad decrypt4.编写配置.travis.yml 增加如下配置，详细见源码# 配置环境before_install: # 替换为刚才生成的解密信息 - openssl aes-256-cbc -K $encrypted_79258127fb87_key -iv $encrypted_79258127fb87_iv -in .travis/id_rsa.enc -out ~/.ssh/id_rsa -d # 改变文件权限 - chmod 600 ~/.ssh/id_rsa # 配置 ssh - eval “$(ssh-agent -s)” - ssh-add ~/.ssh/id_rsa - cp .travis/ssh_config ~/.ssh/config # 配置 git 替换为自己的信息 - git config –global user.name ‘actors315’ - git config –global user.email actors315@gmail.com # 用 ssh 方法提交 - git remote set-url origin git@github.com:actors315/actors315.github.io.git # 切换到提交的目的分支 - git checkout masterinstall: - composer install –prefer-dist –optimize-autoloader –quietscript: - php -f bin/console.phpafter_success: - git add README.md - git add ./markdown/ - git add ./files/* # 这里很重要，commit message 一定要填加 [skip travis] , 不然可能会进入死循环，一直在提交一直在自动构建 - git commit -m “[skip travis] auto build by travis-ci” - git push origin master第四步：填加 Cron jobs最后一步，配置完后就可以自动跑了。有三个时间周期可供选择，每月、每周、每天，按需选择就好了这样就大功告成了，每天自动跑一次其他方法1.使用 Personal access tokens 实现这也是 git 命令行自动提交，使用 Personal access tokens 也很方便，也是推荐。2.使用 Travis CI 官方推荐的 deploy 流程如果你需要自动提交的分支和自动构建不是同一个分支，这就非常方便了，你只需要生成一个 Personal access tokens ，在.travis.yml 文件中简单增加一点配置就好了。deploy: provider: pages skip-cleanup: true github-token: $GITHUB_ACCESS_TOKEN target-branch: gh-pages keep-history: true on: branch: master这个方式还没有研究出来是否可能指定 commit message, 如果同分支又会进入到死循环，同分支部署慎用详见官方文档 ...

什么是Travis CITravis CI 是目前新兴的开源持续集成构建服务。构建并自动提交代码到 Github 1.填加私钥执行如下命令travis encrypt-file ~/.ssh/id_rsa –add实际使用中很有可能会报错Can’t figure out GitHub repo name. Ensure you’re in the repo directory, or specify the repo name via the -r option (e.g. travis <command> -r <owner>/<repo>)这个的意思是找不到项目，需要指定，可以这么操作travis encrypt-file -r actors315/actors315.github.io ~/.ssh/id_rsa –add

前言首先祝各位朋友新年快乐，工作顺利，事业有成，永无BUG。有些朋友一直疑惑Travis CI是个什么东西，网络上搜索后得知的答案是自动测试，自动发布。自动xx 这个名词貌似非常流行，这也是DevOps的一部分，什么?DevOps是什么？我们下一章讲讲这个。先来解释下“自动”这个词，自动顾名思义是自动完成一些事情，上述的自动测试，并不是各位认知中的人肉测试，而是通过我们自己的规则去测试，例如跑一遍tests内的所有测试，自动发布也是通过脚本对现有项目发布到生产环境中或预发布环境中。万事开头难，咱们只玩简单的。使用想玩起来TravisCi不需要安装任何软件,它的网址是 https://travis-ci.org/ ， 你可以选择通过GitHub账号登录他。随后我们可以建立一个github库，就叫它travis_ci_test吧，测试使用就随意点好了。之后点击项目管理 https://travis-ci.org/account… ，会列出你所有的GitHub库通过点击单选按钮将库添加到TravisCi内。添加完成后并没有完事，这时候我们就该认真看看自动测试、集成、发布的脚本怎么写了。配置文件TravisCi为我们准备了超棒的配置文件，你可以在配置文件内随心所欲，例如打开某个目录，执行某条命令，他与dockerfile文件或者shell脚本很类似。只不过运行的容器在travisCi上，并非你本机开发文档:https://docs.travis-ci.com/us…从简单开始,在根目录建立文件 .travis.yml , 下面是具体的配置项language: phpphp:- 7.1before_script:- composer install没错，五行配置就足够了，之后我们回到 https://travis-ci.com/dashboard，点击 trigger a build点击当前项目看看详情。 https://travis-ci.org/CrazyCo...TravisCi 做了几个简单的事情开机克隆你的GITHUB项目composer installphpunit通过测试了就显示success(大绿色) 失败就error喽。下面来看看这个详情页面上都有什么？上图大概展示了以下几点分支名称提交版本执行时间提交时间开发语言作者名称等….下面则是跑的命令行了。具体的配置文件还需要自己去研究，希望我这个头开的还不错吧。感言当你理解了Travis CI后会感觉这是一个多么优秀的产品，程序员要写出好代码是要求，而这些产品扩展。作为一名优秀的程序员，你其实可以这样做写测试用例实现业务提交分支 (TravisCi会自动检测提交并测试)自动部署结束任务看似很复杂，不妨试试？一波免费的广告来!狂撸一款PHP现代化框架 (准备工作) https://segmentfault.com/a/11…这是我正在造的一个轮子 https://github.com/CrazyCodes… ????欢迎关注欢迎加入我的Reader Group 致谢感谢你看到这里，希望本文可以帮到你。谢谢