利用Travis CI+GitHub实现持续集成和自动部署

前言

如果你手动部署过项目,一定会深感持续集成的必要性,因为手动部署实在又繁琐又耗时,虽然部署流程基本固定,依然容易出错。

如果你很熟悉持续集成,一定会同意这样的观点:“使用它已经成为一种标配”。

什么是持续集成
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 CI

Travis 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 Token

Travis CI在自动部署的时候,需要push内容到仓库的某个分支,而访问GitHub仓库需要用户授权,授权方式就是用户提供 Access Token 给Travis CI。

获取token的位置:GitHub->Settings->Developer Settings->Personal access tokens

勾选repo下的所有项,以及user下的user:email后,生成一个token,复制token值。

注意:这个token只有现在可以看到,再次进入就看不到了,而且是再也看不到了,忘记了就只能重新生成了,所以要记住保管好。

二、使用GitHub账号登录Travis

进入Travis官网,用GitHub账号登录。(我目前使用的是它的旧平台)

登录后,会在Travis里看到自己GitHub账号下所有的public open source repo。

三、开启对项目的监控

选择目标项目,打开右侧开关。

四、配置travis

  • 点击开关右侧Settings,进入该项目的travis配置页
  • 勾选触发条件
  • 设置全局变量

    注意:第一步获取的access token,必须设置
    设置好的变量可以在配置文件中以 ${变量名}来引用。

五、在项目根目录添加.travis.yml配置文件

注意文件名以.开头。

Travis CI的一次构建分两个步骤:

  1. install安装,安装任何所需的依赖
  2. script脚本,运行构建脚本

Travis CI提供了一些构建生命周期的“钩子”

一个完整的 Travis CI 构建生命周期:

  1. OPTIONAL Install apt addons
  2. OPTIONAL Install cache components
  3. before_install
  4. install
  5. before_script
  6. script
  7. OPTIONAL before_cache(for cleaning up cache)
  8. after_success or after_failure
  9. OPTIONAL before_deploy
  10. OPTIONAL deploy
  11. OPTIONAL after_deploy
  12. after_script

before_installbefore_script之前,或者after_script之后,都可以运行自定义命令,详细资料可参考官方文档:Job Lifecycle

我在footprint项目中的.travis.yml完整配置:

language: node_js #设置语言

node_js: "10.16.3" #设置语言版本

cache:
  directories:
    - node_modules #缓存依赖

# S: Build Lifecycle
install:
  - npm i

script:
  - npm run build

#after_script前5句是把部署分支的.git文件夹保护起来,用于保留历史部署的commit日志,否则部署分支永远只有一条commit记录。
#命令里面的变量都是在Travis CI里配置过的。
after_script:
  - git clone https://${GH_REF} .temp
  - cd .temp
  - git checkout gh-pages
  - cd ../
  - mv .temp/.git dist
  - cd dist
  - git config user.name "${U_NAME}"
  - git config user.email "${U_EMAIL}"
  - git add .
  - git commit -m ":construction_worker:- Build & Deploy by Travis CI"
  - git push --force --quiet "https://${Travis_Token}@${GH_REF}" gh-pages:${D_BRANCH}
# E: Build LifeCycle

# 只有指定的分支提交时才会运行脚本
branches:
  only:
    - master

Done!

.travis.yml push 到远程,可以看到 travis 开始构建编译了。并且之后每次push代码,travis 都会自动执行.travis.yml里配置的脚本任务了。

  • 自动编译:
  • 构建完,travis 会根据我的配置,自动部署到 GitHub:

And One More Thing

构建成功后,我们就可以在自己的GitHub项目里添加build徽章了。
方法:在Travis里,点击项目右侧的徽章,即可获取小徽章地址,将地址放在README.md文档中即可。

效果:

--
GOODLUCK!

欢迎转载,转载请注明出处:https://champyin.com/2019/09/27/%E5%88%A9%E7%94%A8Travis-CI-GitHub%E5%AE%9E%E7%8E%B0%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90%E5%92%8C%E8%87%AA%E5%8A%A8%E9%83%A8%E7%BD%B2/#more

本文同步发表于:
利用Travis CI+GitHub实现持续集成和自动部署 | 掘金

原文地址:https://www.cnblogs.com/champyin/p/11621898.html

时间: 2024-10-23 05:44:56

利用Travis CI+GitHub实现持续集成和自动部署的相关文章

Travis CI用来持续集成你的项目

这里持续集成基于GitHub搭建的博客为项目 工具: [email protected]:~$ node [email protected]:~$ git --version git version [email protected]:~$ travis --version1.8.4 Travis CI简介 Travis CI 是目前新兴的开源持续集成构建项目,它与jenkins,GO的很明显的特别在于采用yaml格式,简洁清新独树一帜.目前大多数的github项目都已经移入到Travis CI

Jenkins+Maven+Svn搭建持续集成环境持续集成和自动部署

Jenkins和Hudson有很深的渊源,Jenkins目前更新频繁,目前选用Jenkins为持续集成工具和自动部署 Jenkins的使用有很多的介绍,主要记录如下要点: 192.168.1.240:Tomcat: /usr/local/share/apache-tomcat-6.0.37/ 访问端口8186 Jenkins: /usr/local/share/apache-tomcat-6.0.37/webapps/Jenkins访问地址: http://192.168.1.240:8186/

构建基于Jenkins + Github的持续集成环境

搭建持续集成首先要了解什么是持续集成,带着明确的目标去搭建持续集成环境才能让我们少走很多弯路.持续集成(Continuous integration)简称CI,是一种软件开发的实践,可以让团队在持续集成的基础上收到反馈并加以改进,不必等到开发的后期才寻找和修复缺陷.当然要明白的是持续集成环境的搭建也不是一劳永逸的,随着软件项目复杂度的增加,持续集成的环境同样要加以维护以确保集成环境的可靠性. 持续集成的重要要素:1.统一的代码库. 2.CI服务器 3.自动化测试和构建的脚本 4.Slaves 持

CI / CD /CD 持续集成 持续交付 持续部署

CI / CD /CD 持续集成 持续交付 持续部署 CI CD 是啥?干了啥? CI continuous integration 持续集成 CD continuous delivery 持续交付 CD continuous deploy 持续部署 他们干了点啥 代码自动building 测试环境和项目的自动部署 生产环境和项目的自动部署 恩恩 都是这些 和 管理工作 ** 因为是自动化的 可以在你合并代码后几分钟就开始测试 ** 流程: 用户提交代码到仓库 ->合并代码 -> 自动编译代码

持续集成之“自动化部署”

在前文<依赖管理>中,我们讨论了如何在代码变得庞大,组件增多的情况下,做好外部库和内部组件依赖管理,从而提高构建效率.可以应用的实践包括:一次生成,多次复用:建立统一制品库,外部依赖库可以使用像Maven或Ivy这样的工具进行统一管理:对架构进行调整,使一个大的代码库分成多个组件:每个组件有自己的持续集成体系:对多个组件做持续集成.然而,解决一个问题后,总会有另一个问题等在那里,需要你来解决.这次Joe的团队遇到了部署问题. 星期一早上,Alice一进办公室,就看到一脸倦意的Joe坐在椅子上,

Jenkins持续集成-自动化部署脚本的实现《python》

读者须知:1.本手记本着记续接前面的两张手记内容整理2.本手记针对tomcat部署测试环境实现 最近工作比较繁忙,导致这章一直拖延,没有太抽出时间来总结.要实现Jenkins端的持续集成,其实在CI服务配置端很容易,难点呢?就是如何实现自动化的部署.我的脚本设计就是为了解决以下难题: 难点一.如何使得自动化部署脚本更通用 我用的脚本,依赖依赖一个配置文件的模块化,让每一个应用业务模块更加通用.自动化所执行的命令呢?我也是设计想法本着更加通用平台的原则,至少对于tomcat+java or jav

转载:持续集成Jenkins+sonarqube部署教程

转载: 持续集成Jenkins+sonarqube部署教程 持续集成 1 引言 1.1 文档概要 本文主要介绍jenkins,sonar的安装与集成,基于ant,maven构建.用一个例子介绍jenkins的编译打包部署,代码检查.最后集成jenkins.(现阶段只是简易的集成,后续需要修改accio源码做深度集成) 1.2 预计读者 系统配置管理员:要懂得搭建持续集成环境,有问题可以排查:架构师:了解持续集成实现原理,协助项目接入持续集成.项目在持续集成环境运行中,进行维护.分析构建异常等:维

NET持续集成与自动化部署

https://www.cnblogs.com/hunternet/p/9590287.html 相信每一位程序员都经历过深夜加班上线的痛苦!而作为一个加班上线如家常便饭的码农,更是深感其痛.由于我们所做的系统业务复杂,系统庞大,设计到多个系统之间的合作,而核心系统更是采用分布式系统架构,由于当时对系统划分的不合理等等原因导致每次发版都会设计到多个系统的发布,小的版本三五个,大的版本十几个甚至几十个系统的同时发布!而我们也没有相应的基础设施的支撑,发版方式更是最传统的,开发人员将发布包发给运维人

.NET 半天搭建Jenkins持续集成与自动化部署系统

前言 相信每一位程序员都经历过深夜加班上线的痛苦!而作为一个加班上线如家常便饭的码农,更是深感其痛.由于我们所做的系统业务复杂,系统庞大,设计到多个系统之间的合作,而核心系统更是采用分布式系统架构,由于当时对系统划分的不合理等等原因导致每次发版都会设计到多个系统的发布,小的版本三五个,大的版本十几个甚至几十个系统的同时发布!而我们也没有相应的基础设施的支撑,发版方式更是最传统的,开发人员将发布包发给运维人员,由其讲各个发布包一个一个覆盖到生产环境.因此每次上线仅仅发版就需要2-3个小时.这种方式