Deployment
Deployment一般直译为部署，本是一个军事名词。在被新兴的软件工程借用后，现在多是用来指软件开发的一些后续过程，如发布、安装与激活、适配、更新等，详见维基百科Software_deployment。
本文主要介绍如何用Travis，把自动编译后的某些文件，自动deploy到GitHub的Releases里。（以下均以“发布”来代称deploy与deployment。）
如果你还没用过GitHub Releases，可以自补官方文档：https://help.github.com/categories/releases/
自动发布配置
示例如下：
language: groovy
jdk:
- oraclejdk8
- openjdk7
script: "./gradlew build"
before_deploy:
cp $TRAVIS_BUILD_DIR/build/libs/ARTIFACT_ID*.jar ARTIFACT_ID.jar
deploy:
provider: releases
skip_cleanup: true
file: "ARTIFACT_ID.jar"
api_key:
secure: "KmMdcwTWGubXVRu93/lY1NtyHxrjHK4TzCfemgwjsYzPcZuPmEA+pz+umQBN\n1ZhzUHZwDNsDd2VnBgYq27ZdcS2cRvtyI/IFuM/xJoRi0jpdTn/KsXR47zeE\nr2bFxRqrdY0fERVHSMkBiBrN/KV5T70js4Y6FydsWaQgXCg+WEU="
on:
tags: true
jdk: oraclejdk8
# vim: set shiftwidth=2 tabstop=2 softtabstop=-1 expandtab:
script以前的内容，上篇已经介绍了。下面介绍之后的配置：
- before_deploy
在发布前，把编译好的jar改名，放在容易伸手的地方。（我不确定下面的file字段是否支持通配符。） - deploy
发布配置的主体。- provider
指定发布到哪里，这里releases就是指GitHub Releases。
目前（2016年），Travis支持GitHub Releases、bintray、Google App Engine、npm、PyPI、RubyGems等，约30种发布方式。 - skip_cleanup
由于Travis很可能执行到这一步时，会清理掉之前编译的部分过程文件，其中就有可能包含要上传的那些。所以这一条通常设置为true。
不过，在本例中，在before_deploy中就已准备好要上传的jar文件，这一条其实未起作用。 - file
指定要上传到GitHub Releases的文件。可以指定多个文件。 - api_key
GitHub特有的认证字段，可用账户密码代替，必须要加密。下面几个小节会介绍如何加密。
实际上，整个配置的难点就在这里，其它字段都没有什么理解、配置上的难度。 - on
条件发布（Conditional Releases）的指定。显然，发布这种事情，不是每次提交、每个分支都应该做的。
除了下面两类外，还可以指定repo（不影响fork出去的库）、branch（默认为master）、以及condition（自定义条件）。- tags
每次有新的git tag被提交时，GitHub都会自动生成一个release，默认带上源码的压缩包，这是本身就有的机制。
所以，对Travis来说，在每次打tag时触发一次deployment，是比较合适的时机。 - jdk
这个项目虽然在两个JDK下分别进行编译、测试，但其实只需要在一个JDK下发布。
同类的条件还有python、node等。
- tags
- provider
私有信息加密
由于Travis的运作，依赖于纯文本的.travis.yml配置文件，所以对public或有可能某一天变成public的项目来说，任何私密信息都不应该放在其中。
这是所有利用第三方CI时，都需要注意的信息安全问题。开源，分享的是文档、代码和创意，而不是银行账户。
Travis显然早已留意了这个问题，给出了加密方案。加密后，大致形式如下：
secure: "KmMdcwTWGubXVRu93/lY1NtyHxrjHK4TzCfemgwjsYzPcZuPmEA+pz+umQBN\n1ZhzUHZwDNsDd2VnBgYq27ZdcS2cRvtyI/IFuM/xJoRi0jpdTn/KsXR47zeE\nr2bFxRqrdY0fERVHSMkBiBrN/KV5T70js4Y6FydsWaQgXCg+WEU="
（注：这个secure拷贝于Travis某介绍文档。我实际使用的加密文本更长些。）
也就是把明文字段，加密成上面的模样，再放到配置文件.travis.yml中。
具体的保密原理，可见官方文档：《Encryption keys》。
安装travis.rb
为了实现加密功能，需要安装Travis的命令行客户端（Command Line Client），它就是GitHub上的travis-ci/travis。它既是一个基于Ruby的命令行程序，也是一个Ruby的库。
通常，使用gem install travis即可安装。
在中国，由于rubygems.org不够给力（也许可以换种说法），有时根本没法用，所以我们需要更给力的镜像。
ping rubygems.org如果没有好的结果，那么可以用https://ruby.taobao.org/。该镜像承诺每15分钟同步一次，可以解决大多数问题，装个travis显然没问题。（而且，看在逢年过节都大出血的份上，谢一声后，就可以心安理得地尽情使用。）
gem sources --add https://ruby.taobao.org/ --remove https://rubygems.org/
替换后，再执行前述安装命令，即可快速成功安装。
travis命令简介
任何一个网络服务的客户端，完整功能都需要先登录再使用，哪怕它是一个shell命令也一样。
最简单的上手是，执行travis login，根据提示输入GitHub账户、密码登录后，就可以正式开始使用了。但这有个权限过大的问题，它可以对GitHub进行完全控制，所以官方推荐另一种更好的登录方式：指定token。
travis login其实并未把账户密码发送到travis-ci.org，而是发给github.com，生成了一个完整权限token。它承诺，没有把账户密码发送到自家服务器，安全可靠。原理可见文档：travis.rb#login。
不过，这个token其实也是GitHub生成的，专门提供给第三方来调用。可以去GitHub上自己生成（见下一小节），然后用travis login --github "TOKEN"，可直接登录。
正式使用时，当前目录最好就是项目的根目录，这样travis可以自动识别需要处理的项目，省去很多麻烦。
登录后，在项目的根目录，开始加密：
travis encrypt "TOKEN" --add deploy.api_key
--add可以自动把加密好的内容放到.travis.yml文件的指定字段。也可省略这个参数，拿到secure密文后自行配置。
（注：这个token可以是和登录时的那个相同，也可以不同。）
另外，source ~/.travis/travis.sh后，travis命令就支持补全了。可以把这一行加到.bashrc或之类的shell配置文件中。
更多的使用教程，可以看其README，或执行travis -h。
熟练使用后，基本可以不登录网站了。
生成GitHub的token
作为第三方CI，无论是发布到GitHub、还是其它地方，都需要足够识别身份的私密信息，或是账户密码，或是某种key。
GitHub里用的就是Personal access tokens。
在这个页面可以生成一个token，并可修改相关权限。对公开项目Travis需要的权限如下：
- user:email (read-only)
- read:org (read-only)
- repo_deployment
- repo:status
- write:repo_hook
相关介绍，可见官方文档：《Travis CI's use of GitHub API Scopes》。
验证
配置完毕后，打上tag，然后git push --tags就可触发。
由于.travis.yml的配置开始复杂起来，所以大改后，为避免语法错误，最好先做验证，再提交。可以选择：
- 在线验证：http://lint.travis-ci.org/
- 本地验证：
travis lint .travis.yml
参考
Travis官网文档：https://docs.travis-ci.com/
相关文章：
- 上一篇：《从GitHub到Travis》
- 下一篇：《从Travis到bintray》
后记
匿：为什么不直接去发布，搞这么麻烦的配置文件？
蟒：我懒嘛！而且，据说优秀的程序员都懒，什么都要尽量自动化。
匿：有折腾这些的时间，你那小项目早就发布了，而且够手动发布一百回。这项目，你打算发布几百次？
蟒：……
