做 Web 开发的时候经常需要修改/etc/hosts文件把dev.cool.project或者cool.project.dev这样的域名指向 127.0.0.1(如果你从来没有这么做过那你可以跳过后面的内容了但, seriously? you are a web dev and never did this before?）。这样做有些麻烦：

• 每个项目需要修改 hosts 文件
• 需要 root 权限才能修改这个文件

这里记一下如何用dnsmasq把所有dev结尾的域名都指向127.0.0.1。

安装dnsmasq

在 Mac 下安装什么东西本座都用homebrew，先更新 brew:

    $ brew up

然后安装 dnsmasq。注意安装命令的输出，结尾是有配置的简单说明的。因为我用了boxen所以路径不一定对每个人都适用，以你自己的输出为准：

    $ brew install dnsmasq
==> make install PREFIX=/opt/boxen/homebrew/Cellar/dnsmasq/2.69
==> Caveats
To configure dnsmasq, copy the example configuration to /opt/boxen/homebrew/etc/dnsmasq.conf
and edit to taste.
  cp /opt/boxen/homebrew/opt/dnsmasq/dnsmasq.conf.example /opt/boxen/homebrew/etc/dnsmasq.conf
To have launchd start dnsmasq at startup:
    sudo cp -fv /opt/boxen/homebrew/opt/dnsmasq/*.plist /Library/LaunchDaemons
Then to load dnsmasq now:
    sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
==> Summary
/opt/boxen/homebrew/Cellar/dnsmasq/2.69: 7 files, 488K, built in 22 seconds

配置dnsmasq

在dnsmasq.conf里面添加一个配置dev的配置：

address=/dev/127.0.0.1

重启 dnsmasq 服务:

$ sudo launchctl stop homebrew.mxcl.dnsmasq
$ sudo launchctl start homebrew.mxcl.dnsmasq

配置OSX

安装了 dnsmasq 之后你有两个选择：

1. 把操作系统所有的 DNS 查询都由 dnsmasq 处理
2. 把.dev的 DNS 查询交给 dnsmasq 处理

第一个比较简单，在System Preferences里面配置一下就可以了。 第二个需要用/etc/reslov.conf 文件来更精细的控制 DNS 查询:

$ sudo mkdir -p /etc/resolver
$ sudo touch /etc/resolver/dev
$ sudo vi /etc/resolver/dev

在/etc/resolver/dev里面添加一行nameserver 127.0.0.1就可以了。

测试效果

    $ ping -c 1 www.sina.com.cn
    PING newscd.sina.com.cn (221.236.31.145): 56 data bytes

    $ ping -c 1 this.is.a.test.dev
    PING this.is.a.test.dev (127.0.0.1): 56 data bytes

    $ ping -c 1 this.is.cool.dev
    PING this.is.cool.dev (127.0.0.1): 56 data bytes

嗯哼~

对软件公司，特别是互联网软件公司来说，发布流程是企业的核心竞争力。

那么什么是一个好的发布流程呢？Github（别忘了它本身也是一家软件公司）的 CTO 在介绍Boxen 的时候说过，他们公司新员工从拿电脑到可以开始编码只要 30 分钟，这给混过几家 10w+员工公司的我带来的震撼特别强烈。

所以我觉得，一个好的软件发布流程应该是：

1. 新员工在第一天入职就能 push 改动到 production
2. 新员工在第一天入职就能学会怎么从 production 撤销一个错误的改动
3. 整个 deployment 流程是可预测的，也是可追溯的

那么，如果你到了一个新公司，推开门发现那是一个蛮荒之地，应该怎么办呢？这篇先理一下基本的概念，然后后面分节描述一下讲到的这些工具具体要怎么配置怎么用。

善其器

先 check 一下东西齐不齐活:

1. 代码 repo 是放在哪里： (git, hg, …),
2. hook 到 repo 的一套有 review 功能的管理系统: (ReviewBoard, Gitlab, gerrit, bitbucket, github, …),
3. hook 到 repo 的一套 CI 管理系统: (Jenkins, Travis CI, …),
4. 自动部署代码到服务器的系统 (Puppet, chef, clusto, …).

你选择的工具当然对后面的流程有很大的影响。我们公司是采用git+Gitlab+Reviewboard+Jenkins+fabric来做部署。在搭建这套东西之前我也试过很多其他的东西，有的东西我放弃了是因为太复杂不够轻量(比如 Puppet)，有的东西我放弃了是因为，长得太丑(比如 Gerrit)。

开发者视角

假设你今天入职，写了段代码，从你的视角看到的 deployment 流程:

1. 提交到本地 repo。
2. 运行RBTools生成一个 Reviewboard 的review request
3. 代码通过了 review 拿到提交许可后，把代码 merge 然后 push 到 Gitlab 上的alpha分支
4. Jenkins 拿到 change 后做自动测试，然后部署到 test 服务器，发邮件通知 QA
5. QA 或者是开发者自己玩一下 test 服务器，发现没有问题，手动运行 Jenkins 脚本。脚本会对代码打 tag，并部署改动到 staging 服务器，发邮件通知 QA 和 PO
6. PO 确认某个版本的所有代码都到了 staging，QA 做回归测试
7. 测试通过后，手动运行 Jenkins 脚本，脚本会部署某个 staging 服务器的版本到 production 服务器
8. 部署完毕后，Jenkins 运行相应的冒烟测试，测试通过后邮件关键人士，表明 production 音容宛在

整个流程里面，如果你是一个靠谱的开发者，需要花时间参与的步骤很少。但是如果是一个习惯不好的开发者，可能被 review 代码的人，Jenkins 的自动测试，QA 的集成测试或者是回归测试不断修理，惨痛的教训一定会让你成长起来的。

机器视角

很多重复性的事情，都是机器在干:

1. Reviewboard 上被通过的代码被 push 上 Gitlab 的alpha分支后，Jenkins 自动运行:
   1. 静态扫描工具
   2. 单元测试
   3. 有报错发邮件通知事主。没有报错， 部署alpha分支到 test 服务器
   4. 部署 test 服务器后，运行集成测试集
2. 有人手工触发 staging 的 build:
   1. mergealpha分支到staging分支
   2. 部署staging分支到 staging 服务器
   3. 部署服务器后，运行集成测试集
3. 有人手工触发 production 的 build:
   1. mergestaging分支到production分支
   2. 部署production分支到 production 服务器
   3. after deployment, runs integration tests against production

这里很多具体的步骤需要通过 Jenkins 和它的插件甚至是自己写的各种脚本来配合完成

考虑扩展性

未知的未来，你可能会发现项目换了开发语言，项目换了 JS 框架，项目自动化测试改成手动了…在架构整套部署系统的时候，要做好和具体语言具体流程的解耦。

一些可能会有用的思路:

1. 项目组足够小，成员能力足够好，可以不用 review 代码直接 checkin 到公共 repo(成员能力足够好至少意味着，他有写靠谱的 UT)
2. 你构建出来的系统，每个不同的 build 应该可以很容易的绑定不同的工具: 1. 静态扫描工具是很好 (比如 pylint, pep8或者jshint)，但最好项目一开始就用它们。如果是旧项目不要往上套，费时费力 2. 如果是用precommit的hook来跑测试，开发者本地可以不跑 3. 如果是有特别要求的项目（安全性，健壮性等），可以很容易绑定其他的工具
3. 每个项目对应不同的 deployment 环境有不同的 build 配置
4. 三驾马车的服务器配置 (test, staging, production)什么时候应该祭出？个人经验是，如果研发团队超过 3 人了，再怎么省也得有两个(test+production)。如果有专职的 QA 团队，并且希望有稳定的版本部署出去，那三种环境的配置几乎是必须的。
5. 手动触发 test 到 staging 以及 staging 到 production 主要是为了手动测试的时间窗，让版本发布更可控。你也可以结合项目的具体情况决定要不要把这两步也自动化。

如果是用了 Jenkins，上面这些就非常方便了，因为说白了每个 build 不过就是当特定条件满足时执行的一堆特定脚本而已：当然，如果你发现公司还在用 Ubuntu 12.04 做 build server，可能也没有那么方便。

Rants

1. 什么时候需要考虑上这种流程? 如果是三个人的车库队伍，然后就队伍里面又没人有兴趣做对运维，那就算了吧。如果是正经开门做生意的公司，都该上。
2. 能不能允许”加急”? 和很多大公司比，这套流程虽然已经精简了，但是总有时候我们有非常”紧急的”改动，能不能不走这套流程直接上？ 简单的回答就是，不能。如果你发现了有人要求加急，一定是目前的流程太慢。这种情况，一定是有什么东西坏掉了吧。比如之前的代码 check 不严格，很严重的错误很容易就到了 production，或者你的员工们写的 UT 跑一年都跑不完或者是在 build server 上根本没法跑。
3. 为什么不自动部署? 是，这里描述的流程只有到 test 服务器是自动部署的，后面到 staging 和 production 都是手动部署。因为据说，把自动 merge 和自动测试的代码部署到 production 服务器，是一个很容易让你半夜接到电话的举动，而且很多 CEO 鬓角的白头发都是因为这样的部署长出来的。当然如果你的 manager 已经在他老板那里夸口说你来了整个手动测试 team 都可以解散了，我就只能祝你好运了。
4. 静态扫描的工具（无论是 lint 还是 style 的检查），常常都会给团队带来比 UT 更好的提升：很多时候你在 review 的时候要不断告诉同事特别是新手同事你这段代码连 style 都不对，对两个人都是伤害…如果有个无情的机器用不妥协地负责做这件事情，嗯哼…

Hope you have fun when setting up the pipeline for your company.