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 一下哦... ...