@Lenciel

构建Deployment系统 (1)

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

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

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

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

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

善其器

先check一下东西齐不齐活:

  1. 代码repo是放在哪里: (githg, …),
  2. hook到repo的一套有review功能的管理系统: (ReviewBoard, Gitlab, gerritbitbucketgithub, …),
  3. hook到repo的一套CI管理系统: (JenkinsTravis CI, …),
  4. 自动部署代码到服务器的系统 (Puppet, chefclusto, …).

Deployment Phases

你选择的工具当然对后面的流程有很大的影响。我们公司是采用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. 静态扫描工具是很好 (比如 pylintpep8或者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.