Posts - 270,
Articles - 0,
Comments - 2033
09:35 by 破狼, ... 阅读,
&&&&& Travis CI 是目前新兴的开源持续集成构建项目，它与jenkins，GO的很明显的特别在于采用yaml格式，简洁清新独树一帜。目前大多数的github项目都已经移入到Travis CI的构建队列中，据说Travis CI每天运行超过4000次完整构建。对于做开源项目或者github的使用者，如果你的项目还没有加入Travis CI构建队列，那么我真的想对你说out了。
&&&&& 下面是本人的构建历史：
& 搭建Travis CI build，需要你有个github账号和github项目：
1：用github账号登陆.
2 :在右上角你的账户名点击进入 account，在Repositories tab页点击Sync now同步你的github项目，
3：选中项目将默认的off改变为on开启项目的持续集成。
4：在你项目的根目录建立一个.travis.yml文件，内容为：
language: node_js
node_js:&&
&&&& - 0.4&&
&&&& - 0.6
5: 在打开你的node.js的package.json文件，确保加入script/test节点：
"scripts": {
& & "test": "XXXX"
这里你可惜选择mak或者jasmine-node等node.js测试框架的测试命令。并且可以把依赖加入package的depends
6：在你项目中运行npm test，确保正常工作。
7： check in你的code到github，代开tracivs
ci界面等待其同步并运行你的build构建。
& 如果你需要将你的build构建状态放在一个显眼的位置或者项目readme，你可以在首页My Repositories中找到项目并设置中复制状态图片code，形如：
[![Build Status]()
Travs CI 支持多中语言如ruby，java的maven，gradle,Go等请参见文档.
&&&& 在上面提到的travis.yml文件中我们还可以加入build前后执行脚本，形如：
before_script:&&
&&&& - before_command_1&&
&&&& - before_command_2
after_script:&&
&&&& - after_command_1&
&&&& - after_command_2
&& &将你的开源项目加入Travis CI队列吧，很容易让你的项目加入持续集成，持续构建队列。如何使用 Travis CI 自动化私有 npm 模块的预发布版本管理
Presence Insights：背景知识IBM Presence Insights 包含近 30 个库，以两周为周期进行迭代。在这个两周的周期中，这些库的默认分支会随着多个团队交付特性而快速更改。因为我们依靠 npm 将这些库部署到临时环境，所以，以传统方式处理此过程会导致在每个开发周期砍掉许多版本，其中大部分版本都不重要或无关紧要。这产生了过于复杂的版本历史，在突然出现性能退化时通常很难进行分析。通过 ，可以建立和管理多个开发流，而不会让库的版本历史复杂化。dist-tags 是有效的安装目标，这意味着一个名为 unstable 的给定 dist-tag 可通过 npm 使用 npm install @pi/library@unstable 命令来安装。这还意味着它是 package.json 的有效目标。当在迭代期间将代码签入到任何分支并通过回归测试时，Travis CI 会基于当前（“最新”）版本来创建一个版本。最新版本包含更多元数据，包括分支名称和时间戳。此版本在一个基于该分支名称的标签下发布。参考资料此信息会传递到：travis.ymlpackage.json@pidev/publish.travis.yml在签入代码时，来自 PI 记录器的 Travis.yaml 会控制 Travis 运行的编译版本的配置。下面是一个示例：
provider: script
script: npm run travis-publish
skip_cleanup: true
all_branches: true
node: '0.12'
tags: false这段代码声明部署由我们通过 npm run travis-publish 提供的一段自定义脚本来管理。on:d 用于定义要发布哪些模块。因为我们希望管理预发布版本，所以我们从所有分支发布，而不发布 on 标签（发布脚本在每次迭代结束时推送 on 标签）。我们启用了 skip_cleanup，因为我们的自定义发布脚本依赖于一些 Node 依赖项。package.json定义 npm run travis-publish 的含义。来自 Presence Insights 记录器的一个 package.json 示例如下："travis-publish":"publish npm --platform travis"publish 是一个使用 Node 编写的 CLI，被指定为一个开发依赖项："@pidev/publish":"0.x"@pidev/publish定义我们的部署的自定义逻辑，包括利用分支名和时间戳构成元数据。它是一个简单的
node CLI，通过 publish npm 公开一个发不到 npm 的命令。当 --platform travis 存在时，会使用一个访问 Travis 环境变量的例程。对于 Presence Insights，我们将临时环境命名为 YS1-dev。当更改签入到默认分支时，使用标签 dev 来匹配临时区域的名称。对于其他团队或情景，推荐使用 rc，以清楚表明默认分支上的所有内容均可发布。// change on master branch, main development stream
if (branch === 'master') {
sh.echo(ch.blue('creating dev version and publishing'));
version += '-dev-' + moment().tz('America/New_york').format('YYYYMMDD-HHmm');
tag = 'dev';
}版本是利用 dist-tag 创建的，时区的格式为 YYYYMMDD-HHmm。例如：@pilib/logger@1.0.5-dev-5。来自在 Travis 上运行的一次编译的示例输出：creating dev version and publishing
exec npm version 1.2.11-dev-4
v1.2.11-dev-4
exec npm dist-tag add @pilib/logger@1.2.11-dev-4 dev
+dev: @pilib/logger@1.2.11-dev-4
exec npm publish --tag dev
+ @pilib/logger@1.2.11-dev-4如果它不是默认分支，我们会稍微将其规范化，以确保分支名可在版本元数据中安全地使用。删除 /将 _ 替换为 -使用 normalize()else {
// if its not master branch, its a feature branch, create dist-tag for feature
// based on branch name, publish to that.
sh.echo(ch.blue('creating a feature version and publishing'));
var normalizedBranch = branch.split('/').join('-');
normalizedBranch = normalizedBranch.split('_').join('-');
normalizedBranch = normalizedBranch.normalize();
sh.echo(ch.green(normalizedBranch) + ' is the dist-tag for this feature');
version += '-' + normalizedBranch + '-' + moment().tz('America/New_york').format('YYYYMMDD-HHmm');
tag = normalizedB
}在此场景中，一个名为 feature/geofences_39284（其中 39284 是工作项 id）的分支被规范化为标签 feature-geofences-39284，并使用完整版本 @pilib/logger@1.0.5-feature-geofences-16-0945。此版本可通过 npm install @pilib/logger@feature-geofences-39284 获得。解析出相关信息并将标签和预发布版本字符串拼凑在一起后，发布到 npm 而不更新 latest 标签。// properly exit if version fails
if (sh.exec('npm version ' + version).code !== 0) {
sh.exit(1);
// properly exit if adding the dist-tag fails
if (sh.exec('npm dist-tag add ' + scope + '/' + name + '@' + version + ' ' + tag).code !== 0) {
sh.exit(1);
// properly exit if publish fails
if (sh.exec('npm publish --tag ' + tag).code !== 0) {
sh.exit(1);
}首先，剪切掉我们创建的版本。如果这是第一次，则显式添加 dist-tag，然后使用 --tag 标志发布，以告诉 npm 不要更新最新版本。这样，签入的代码就可以通过创建的 dist-tag 用于本地和临时环境。指定 dev 作为私有 Presence Insights 依赖项版本的项目，将在整个迭代周期中自动选择对默认分支的更改。指定未来版本的项目将选择对该分支的更改。结束语目前依靠 moment-timezone 等来精减 @pidev/publish，但时区仅需出现一次。它还使用了 commander，这是一个大型框架。您可以精减 @pidev/publish 来仅依靠 shelljs、yargs 和 chalk。在 @pidev/publish 中参数化默认分支和表示它的标签。我们使用主分支作为默认分支，但临时环境的名称为 dev，所以容易产生混淆。将名称从 dev 更改为 staging 或 rc。结束语在本文中，您学习了如何结合使用 npm dist-tags 和 Travis CI，自动化预发布版本的管理。预发布版本是一种强大的工具，有助于在部署的环境中快速获取反馈，同时维护简洁且容易理解的版本历史，并且支持更轻松地对单个版本执行迭代式工作。
相关主题访问""，获取更多关于 DevOps 技术的文章和教程。加入 ，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=DevOpsArticleID=1038511ArticleTitle=如何使用 Travis CI 自动化私有 npm 模块的预发布版本管理publish-date=为什么不做个类似Travis CI或者Bamboo这样的提供持续集成的服务呢？
或者直接基于Jenkins二次开发？
国内做代码托管服务的已经不少了，但是周边服务几乎没有，红薯可以考虑一下。
早是我们计划的一部分，快了！
--- 共有 3 条评论 ---
帅气，加油
提个建议，希望可以跟Github、Bitbucket这些网站方便对接
这个好，，，，Jenkins， Hudson 就行了。
就是用jenkins做个山寨 travis-ci 嘛！基于Travis CI搭建Android持续集成以及自动打包发布流程 - 简书
基于Travis CI搭建Android持续集成以及自动打包发布流程
最近项目进度比较轻松，闲来自己研究一些感兴趣的技术，恰好这两天研究了一下Travic CI, 用于Android持续集成以及自动打包，话不多说，下面大家就跟我一起踏入Travis CI的奇妙旅行
我们在开发Android项目的时候，大致的流程是这样：
Question:这些步骤能否简化，能否自动化？懒是码农的美德，作为资深码农应该善于用工具提高自己的工作效率，能自动化的要自动化。那么今天要讲的Travis CI就能简化我们的工作，上述流程如果使用Travis CI那么工作流程是这样的：
Tag提交后，Travis CI会自动编译代码，生成apk文件，并发到Github和相应地其他渠道（fir.im, 蒲公英等），分发完成后，会邮件通知参与测试的人员。如此一来，作为码农，只要安心Coding和打Tag就好了，轻松愉快啊?,下面我们就来着重介绍Travis
简单来说它是用来做持续集成的工具，可以为你自动构建、测试、打包等等，极大的简化了工作流程。它对Github的支持特别好，链接到你在Github上的项目以后，每当你把测试通过后的代码提交到master去，它会pull你的代码并按照你的要求构建执行
如何安装Travis CI
首先需要安装Ruby, 你可以通过运行ruby -v 检查系统是否安装Ruby:
ruby 2.0.0p645 ( revision 50299) [universal.x86_64-darwin15]
然后运行：
$ gem install travis -v 1.8.0 --no-rdoc --no-ri
安装完毕后，检验一下：
$ travis version
配置Android项目，启用Travis CI
先添加Travis CI到Github repo:
然后按照官网说法是大致三步走：
先选择要开启Travis CI的项目，将开关设为On即可：
在项目的根目录下新建一个文件.travis.yml，如下是一个Android 项目的配置模板：
language: android
components:
# Uncomment the lines below if you want to
# use the latest revision of Android SDK Tools
# - platform-tools
# The BuildTools version used by your project
- build-tools-19.1.0
# The SDK version used to compile your project
- android-19
# Additional components
- extra-google-google_play_services
- extra-google-m2repository
- extra-android-m2repository
- addon-google_apis-google-19
# Specify at least one system image,
# if you need to run emulator(s) during your tests
- sys-img-armeabi-v7a-android-19
- sys-img-x86-android-17
当Travis CI准备好我们所需要的环境后，将自动运行yml文件script部分所设置的指令，上例中运行的是./gradlew assembleRelease，运行成功的话会在项目的主模块下生成build/outputs/apk/app-release.apk
【备注】Travis CI目前有2个网站：如果是开源项目，直接进入travis-ci.org即可，如果是私有付费项目，则需要进入，2个网站除了域名外所有的界面及操作几乎一模一样
Android项目自动化构建的密码和证书安全问题
安卓项目发布需要证书文件和若干密码，但无论是开源项目还是私有项目，任何时候都不应该将原始证书或密码放入代码库（原则上来讲证书和密码也不应该交于开发人员，而应该只能通过发布服务器进行编译）。Travis CI为此提供了2种解决方案，一种是对敏感信息、密码、证书等进行对称加密，在CI构建环境时解密，另一种是将密码等通过Travis CI的控制台（即网站）设置为构建时的环境变量。
由于前者会在Travis控制台生成一对环境变量，所以我的做法是尽量选择后者，但由于Travis控制台无法上传文件，因此涉及到文件加密的部分，则只能选择前者。说了这么多，首先还是需要先对编译脚本进行改造，如果不考虑安全问题，项目的build.gradle文件可能会是这样：
signingConfigs {
releaseConfig {
storeFile file("../xx.keystore")
storePassword "123456"
keyAlias "key_alias"
keyPassword "123456"
buildTypes {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.releaseConfig
而我们最终要的效果，还是希望一份编译脚本既可以用于开发环境，也可以在CI环境下使用，在Travis CI中，可以通过点击项目名称 -& Settings -& Environment Variables中设置环境变量，比如我们可以针对上面的配置，分别设置KEYSTORE_PASS、ALIAS_NAME、ALIAS_PASS三个环境变量:
在Travis CI环境下可以通过System.getenv()获得这些环境变量本地开发环境中，我的做法是将这几个变量加到gradle.properties文件中，这样就可以在build.gradle内直接使用了。下面是开发环境的gradle.properties:
KEYSTORE_PASS=123456
ALIAS_NAME=key_alias
ALIAS_PASS=123456
这样一来build.gradle就变成了:
releaseConfig {
storeFile file("../xx.keystore")
storePassword project.hasProperty("KEYSTORE_PASS") ? KEYSTORE_PASS : System.getenv("KEYSTORE_PASS")
keyAlias project.hasProperty("ALIAS_NAME") ? ALIAS_NAME : System.getenv("ALIAS_NAME")
keyPassword project.hasProperty("ALIAS_PASS") ? ALIAS_PASS : System.getenv("ALIAS_PASS")
接下来处理证书文件，为了方便文件加密等功能，Travis CI提供了一个基于ruby的CLI命令行工具，可以直接使用gem安装:
gem install travis
安装后进入安卓项目根目录，尝试对证书文件加密：
travis encrypt-file xx.keystore --add
travis encrypt-file指令会做几件事情:1.在Travis CI控制台自动生成一对密钥: encrypted_59c_key和encrypted_59c_iv
2.基于密钥通过openssl对文件进行加密，上例中会项目根目录生成xx.keystore.enc文件3.在.travis.yml中自动生成Travis CI环境下解密文件的配置，上例运行后可以看到.travis.yml中多了几行：
before_install:
- gem install fir-cli
- openssl aes-256-cbc -K $encrypted_59c_key -iv $encrypted_59c_iv
-in xx.keystore.enc -out xx.keystore -d
最后在.gitignore中忽略xx.keystore以及gradle.properties
Travis Ci自动发布安装apk文件到Github Release
Travis CI的script部分运行成功后，可以通过配置文件进入到发布阶段。下面是一个Travis CI发布的示例：
provider: releases
user: "GITHUB USERNAME"
password: "GITHUB PASSWORD"
file: app/build/outputs/apk/app-release.apk
skip_cleanup: true
tags: true
provider：发布目标为Github Release
Github用户名和密码，因为Travis CI要上传APK文件，因此需要有Github项目的写入权限
file： 发布文件，输入文件路径即可
skip_cleanup: 默认情况下Travis CI在完成编译后会清除所有生成的文件，因此需要将skip_cleanup设置为true来忽略此操作。
on： 发布的时机，这里配置为tags: true，即只在有tag的情况下才发布。
这边直接暴露了Github密码是我们更加不能接受的。更好的做法是在Github -& settings -& Personal access tokens 生成一个只能访问当前项目并只有读取权限的Github Access Token，并通过Travis CI将Access Token加密。好在Travis CLI中已经可以通过一行指令做好这一切：
travis setup release
根据提示填写上述配置项目的信息后，Travis CLI会自动在.travis.yml文件中生成好所有的配置项：
provider: releases
secure: XXX
file: app/build/outputs/apk/app-release.apk
skip_cleanup: true
tags: true
all_branches: true
其中api_key下的secure就是加密后的Access Token。
自动发布APK到fir.im
自动发布到Github对于开发人员已经足够，但是考虑到项目实际需要以及国情，还是有必要选择一个国内的App分发服务，fir.im是不错的选择，不但允许游客下载，还提供了二维码等更适合对接手机的功能，国内下载速度也很快。由于fir.im提供了比较方便的CLI工具，因此本文以fir.im为例，在.travis.yml中添加以下几行：
before_install:
- gem install fir-cli
after_deploy:
- fir p app/build/outputs/apk/app-release.apk -T $FIR_TOKEN -c "`git cat-file tag $TRAVIS_TAG`"
即在环境构建阶段安装fir-cli，在发布成功后通过fir命令行工具将apk上传到fir。其中$FIR_TOKEN可以在fir.im的用户-&API Token中找到，然后在Travis CI控制台中创建环境变量FIR_TOKEN并粘贴即可。
其实所有的yml文件配置不到30行，就能利用Travis CI进行自动化持续集成和打包。最后我们回顾一下Travis CI的工作流：提交代码：
git commit -m "注释"
git push origin
git tag -a v0.0.1-alpha.1 -m "Tag注释，说清楚这个版本的主要改动，也可以省略-m参数直接写长文本"
git push origin --tags
这个是我集成了Travis CI的项目地址，供参考：
Google Fans、Android Follower