软件发布实战 -- 集成

作为一个程序员, 每天开心的新程序,让所有的测试通,最后打浏览器,输入“localhost/newapp”, 看到开发的功能展现在眼前, 那种愉悦和满足不言而喻。

但是有没有想过如何发布让其他人共享你的成果呢?

当然!使用heroku,输入下面的命令就可以轻松的帮你完成。

1
git push heroku master

那如果同时要发布6 ,7个项目呢?项目之间可能共用数据库,共享若干代码。情况似乎就不那么简单。

需要考虑的因素很多,其中集成无疑是非常重要的,下面两点,可见一斑。

1、 与其他项目的集成

一个很简单的例子。我们的项目的唯一入口是另一个项目中一个连接

1
2
old link: http://host/show?name=jiangpeng
new link: http://host/show

需求是把old link改成new link,以前name参数是必传的,否则就会失败,现在是可选择的。 我们对自己的代码库非常熟悉,很快将验证必选的逻辑去掉。接下来就要去修改另一个代码库,那是个陈旧的用Perl完成的代码,修改完成之后甚至不知道怎么运行测试,而且CI还是红的,没法build出package,也没法提交。 过了两天才顺利的做完,build出最新的版本,deploy到cloud上,功能完美,QA竖起大拇指说做的不错,没有bug!

等到发布的时候只要把最新的包部署到production上面。这样就可以了么? 不行!

当前对于两个工程的修改在发布时是有依赖的。如果Perl工程先发布,就必然导致在我们工程发布之前的这个时间段,我们的功能将无法访问。通常,发布会持续两三天,也就是说最坏的情况,三天之内我们的应用都不可用。 这对于要求7*24小时在线的应用来说是不可接受的。 其实这个问题是可以避免,在cloud上我们有E2E的测试,但是由于要在那个环境上做BAT,所以恰好关掉了cloud的自动部署。 虽然只是这么微小的改变都有可能导致产品无法访问的巨大后果,这就是集成考虑不全面的后果。

2、与数据库的集成 发布从大的方面可以分为数据库与代码库两个部分,数据库先于代码库发布,如果发布持续3天,通常第一天第一步就是应用所有的数据库修改,然后陆续的发布不同项目的代码。 如果只是增加新列或表,这个过程没有问题。如果是修改列名呢? 按照前面的发布顺序,数据库发布之后,代码发布之前,应用必然异常,会提示数据库列不存在。以下的几个方案可以考虑实施:

  • 不要在最开始就执行数据库的修改,可以将修改列名这一个操作放在发布对应代码之前。这种方案其实就是缩短两者之间的时间差,期望在这个时间段内没有用户访问。
  • 与Business的人商量,如果允许产品下线,那么采用步骤1即可。通常Business的人对这种要求都会比较谨慎的思考,所以提出这样的建议前,也需要想清楚可否避免。

与发布相关的集成点有的时候需要dev在开发结阶段不要仅仅局限于代码功能完成本身,而需要从发布的角度仔细想想才会避免. 当然更加科学的做法是通过足够的自动化测试来保证,纯粹靠程序员的思考,很难保证每一次都不出问题。

《软件开发沉思录–ThoughtWorks文集》中的第一章:Solving the Business Software “Last Mile”,更加详细和理论的阐述了大型项目发布的问题,不论是否参与过这样的发布, 都值得学习一下。

comments powered by Disqus