构建Deployment系统
2015-06-16 18:06
357 查看
对软件公司,特别是互联网软件公司来说,发布流程是企业的核心竞争力。
那么什么是一个好的发布流程呢?Github(别忘了它本身也是一家软件公司)的CTO在介绍Boxen的时候说过,他们公司新员工从拿电脑到可以开始编码只要30分钟,这给混过几家10w+员工公司的我带来的震撼特别强烈。
所以我觉得,一个好的软件发布流程应该是:
新员工在第一天入职就能push改动到production
新员工在第一天入职就能学会怎么从production撤销一个错误的改动
整个deployment流程是可预测的,也是可追溯的
那么,如果你到了一个新公司,推开门发现那是一个蛮荒之地,应该怎么办呢?这篇先理一下基本的概念,然后后面分节描述一下讲到的这些工具具体要怎么配置怎么用。
代码repo是放在哪里: (git, hg, …),
hook到repo的一套有review功能的管理系统: (ReviewBoard,
Gitlab,
gerrit, bitbucket, github, …),
hook到repo的一套CI管理系统: (Jenkins, Travis CI, …),
自动部署代码到服务器的系统 (Puppet,
chef, clusto, …).
你选择的工具当然对后面的流程有很大的影响。我们公司是采用
提交到本地repo。
运行RBTools生成一个Reviewboard的
代码通过了review拿到提交许可后,把代码merge然后push到Gitlab上的
Jenkins拿到change后做自动测试,然后部署到test服务器,发邮件通知QA
QA或者是开发者自己玩一下test服务器,发现没有问题,手动运行Jenkins脚本。脚本会对代码打tag,并部署改动到staging服务器,发邮件通知QA和PO
PO确认某个版本的所有代码都到了staging,QA做回归测试
测试通过后,手动运行Jenkins脚本,脚本会部署某个staging服务器的版本到production服务器
部署完毕后,Jenkins运行相应的冒烟测试,测试通过后邮件关键人士,表明production音容宛在
整个流程里面,如果你是一个靠谱的开发者,需要花时间参与的步骤很少。但是如果是一个习惯不好的开发者,可能被review代码的人,Jenkins的自动测试,QA的集成测试或者是回归测试不断修理,惨痛的教训一定会让你成长起来的。
Reviewboard上被通过的代码被push上Gitlab的
静态扫描工具
单元测试
有报错发邮件通知事主。没有报错, 部署
部署test服务器后,运行集成测试集
有人手工触发staging的build:
merge
部署
部署服务器后,运行集成测试集
有人手工触发production的build:
merge
部署
after deployment, runs integration tests against production
这里很多具体的步骤需要通过Jenkins和它的插件甚至是自己写的各种脚本来配合完成
一些可能会有用的思路:
项目组足够小,成员能力足够好,可以不用review代码直接checkin到公共repo(成员能力足够好至少意味着,他有写靠谱的UT)
你构建出来的系统,每个不同的build应该可以很容易的绑定不同的工具:
静态扫描工具是很好 (比如 pylint, pep8或者jshint),但最好项目一开始就用它们。如果是旧项目不要往上套,费时费力
如果是用precommit的hook来跑测试,开发者本地可以不跑
如果是有特别要求的项目(安全性,健壮性等),可以很容易绑定其他的工具
每个项目对应不同的deployment环境有不同的build配置
三驾马车的服务器配置 (test, staging, production)什么时候应该祭出?个人经验是,如果研发团队超过3人了,再怎么省也得有两个(test+production)。如果有专职的QA团队,并且希望有稳定的版本部署出去,那三种环境的配置几乎是必须的。
手动触发test到staging以及staging到production主要是为了手动测试的时间窗,让版本发布更可控。你也可以结合项目的具体情况决定要不要把这两步也自动化。
如果是用了Jenkins,上面这些就非常方便了,因为说白了每个build不过就是当特定条件满足时执行的一堆特定脚本而已:当然,如果你发现公司还在用Ubuntu 12.04做build server,可能也没有那么方便。
能不能允许”加急”? 和很多大公司比,这套流程虽然已经精简了,但是总有时候我们有非常”紧急的”改动,能不能不走这套流程直接上? 简单的回答就是,不能。如果你发现了有人要求加急,一定是目前的流程太慢。这种情况,一定是有什么东西坏掉了吧。比如之前的代码check不严格,很严重的错误很容易就到了production,或者你的员工们写的UT跑一年都跑不完或者是在build server上根本没法跑。
为什么不自动部署? 是,这里描述的流程只有到test服务器是自动部署的,后面到staging和production都是手动部署。因为据说,把自动merge和自动测试的代码部署到production服务器,是一个很容易让你半夜接到电话的举动,而且很多CEO鬓角的白头发都是因为这样的部署长出来的。当然如果你的manager已经在他老板那里夸口说你来了整个手动测试team都可以解散了,我就只能祝你好运了。
静态扫描的工具(无论是lint还是style的检查),常常都会给团队带来比UT更好的提升:很多时候你在review的时候要不断告诉同事特别是新手同事你这段代码连style都不对,对两个人都是伤害…如果有个无情的机器用不妥协地负责做这件事情,嗯哼…
Hope you have fun when setting up the pipeline for your company.
Posted by Lenciel Li
Apr 22nd,
2014 2:49 am
ci,
deployment,
tips,
tutorials
那么什么是一个好的发布流程呢?Github(别忘了它本身也是一家软件公司)的CTO在介绍Boxen的时候说过,他们公司新员工从拿电脑到可以开始编码只要30分钟,这给混过几家10w+员工公司的我带来的震撼特别强烈。
所以我觉得,一个好的软件发布流程应该是:
新员工在第一天入职就能push改动到production
新员工在第一天入职就能学会怎么从production撤销一个错误的改动
整个deployment流程是可预测的,也是可追溯的
那么,如果你到了一个新公司,推开门发现那是一个蛮荒之地,应该怎么办呢?这篇先理一下基本的概念,然后后面分节描述一下讲到的这些工具具体要怎么配置怎么用。
善其器
先check一下东西齐不齐活:代码repo是放在哪里: (git, hg, …),
hook到repo的一套有review功能的管理系统: (ReviewBoard,
Gitlab,
gerrit, bitbucket, github, …),
hook到repo的一套CI管理系统: (Jenkins, Travis CI, …),
自动部署代码到服务器的系统 (Puppet,
chef, clusto, …).
你选择的工具当然对后面的流程有很大的影响。我们公司是采用
git+
Gitlab+
Reviewboard+
Jenkins+
fabric来做部署。在搭建这套东西之前我也试过很多其他的东西,有的东西我放弃了是因为太复杂不够轻量(比如Puppet),有的东西我放弃了是因为,长得太丑(比如Gerrit)。
开发者视角
假设你今天入职,写了段代码,从你的视角看到的deployment流程:提交到本地repo。
运行RBTools生成一个Reviewboard的
review request
代码通过了review拿到提交许可后,把代码merge然后push到Gitlab上的
alpha分支
Jenkins拿到change后做自动测试,然后部署到test服务器,发邮件通知QA
QA或者是开发者自己玩一下test服务器,发现没有问题,手动运行Jenkins脚本。脚本会对代码打tag,并部署改动到staging服务器,发邮件通知QA和PO
PO确认某个版本的所有代码都到了staging,QA做回归测试
测试通过后,手动运行Jenkins脚本,脚本会部署某个staging服务器的版本到production服务器
部署完毕后,Jenkins运行相应的冒烟测试,测试通过后邮件关键人士,表明production音容宛在
整个流程里面,如果你是一个靠谱的开发者,需要花时间参与的步骤很少。但是如果是一个习惯不好的开发者,可能被review代码的人,Jenkins的自动测试,QA的集成测试或者是回归测试不断修理,惨痛的教训一定会让你成长起来的。
机器视角
很多重复性的事情,都是机器在干:Reviewboard上被通过的代码被push上Gitlab的
alpha分支后,Jenkins自动运行:
静态扫描工具
单元测试
有报错发邮件通知事主。没有报错, 部署
alpha分支到test服务器
部署test服务器后,运行集成测试集
有人手工触发staging的build:
merge
alpha分支到
staging分支
部署
staging分支到staging服务器
部署服务器后,运行集成测试集
有人手工触发production的build:
merge
staging分支到
production分支
部署
production分支到production服务器
after deployment, runs integration tests against production
这里很多具体的步骤需要通过Jenkins和它的插件甚至是自己写的各种脚本来配合完成
考虑扩展性
未知的未来,你可能会发现项目换了开发语言,项目换了JS框架,项目自动化测试改成手动了…在架构整套部署系统的时候,要做好和具体语言具体流程的解耦。一些可能会有用的思路:
项目组足够小,成员能力足够好,可以不用review代码直接checkin到公共repo(成员能力足够好至少意味着,他有写靠谱的UT)
你构建出来的系统,每个不同的build应该可以很容易的绑定不同的工具:
静态扫描工具是很好 (比如 pylint, pep8或者jshint),但最好项目一开始就用它们。如果是旧项目不要往上套,费时费力
如果是用precommit的hook来跑测试,开发者本地可以不跑
如果是有特别要求的项目(安全性,健壮性等),可以很容易绑定其他的工具
每个项目对应不同的deployment环境有不同的build配置
三驾马车的服务器配置 (test, staging, production)什么时候应该祭出?个人经验是,如果研发团队超过3人了,再怎么省也得有两个(test+production)。如果有专职的QA团队,并且希望有稳定的版本部署出去,那三种环境的配置几乎是必须的。
手动触发test到staging以及staging到production主要是为了手动测试的时间窗,让版本发布更可控。你也可以结合项目的具体情况决定要不要把这两步也自动化。
如果是用了Jenkins,上面这些就非常方便了,因为说白了每个build不过就是当特定条件满足时执行的一堆特定脚本而已:当然,如果你发现公司还在用Ubuntu 12.04做build server,可能也没有那么方便。
Rants
什么时候需要考虑上这种流程? 如果是三个人的车库队伍,然后就队伍里面又没人有兴趣做对运维,那就算了吧。如果是正经开门做生意的公司,都该上。能不能允许”加急”? 和很多大公司比,这套流程虽然已经精简了,但是总有时候我们有非常”紧急的”改动,能不能不走这套流程直接上? 简单的回答就是,不能。如果你发现了有人要求加急,一定是目前的流程太慢。这种情况,一定是有什么东西坏掉了吧。比如之前的代码check不严格,很严重的错误很容易就到了production,或者你的员工们写的UT跑一年都跑不完或者是在build server上根本没法跑。
为什么不自动部署? 是,这里描述的流程只有到test服务器是自动部署的,后面到staging和production都是手动部署。因为据说,把自动merge和自动测试的代码部署到production服务器,是一个很容易让你半夜接到电话的举动,而且很多CEO鬓角的白头发都是因为这样的部署长出来的。当然如果你的manager已经在他老板那里夸口说你来了整个手动测试team都可以解散了,我就只能祝你好运了。
静态扫描的工具(无论是lint还是style的检查),常常都会给团队带来比UT更好的提升:很多时候你在review的时候要不断告诉同事特别是新手同事你这段代码连style都不对,对两个人都是伤害…如果有个无情的机器用不妥协地负责做这件事情,嗯哼…
Hope you have fun when setting up the pipeline for your company.
Posted by Lenciel Li
Apr 22nd,
2014 2:49 am
ci,
deployment,
tips,
tutorials
相关文章推荐
- js可以解码utf-8编码,我一直以为decodeURIComponent只能解码16进制呢,原理???
- 第4题
- 简单的正则
- [翻译]Swift编程语言——初始化
- oracle max()函数和min()函数
- php序列化,反序列化
- 身边——不要因为过去毁掉现在
- [翻译]Swift编程语言——继承
- 火狐浏览器 上运行的一个bug
- erlang进程监控:link和monitor
- mysql的reset命令
- VC中导出Office的类库, 用于操作Office
- C++基数排序(清楚明了完美详细的实现)
- [翻译]Swift编程语言——下标
- Linux_1.5_makefile工程管理
- VoltDB 源码分析 之 接收请求
- 创业这么热,为何站长消失了?
- Java抓取网页数据(原来的页面+Javascript返回数据)
- java设计模式演示示例
- Swift之 ? 和 !