作为一个程序员， 每天开心的新程序，让所有的测试通，最后打浏览器，输入“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”，更加详细和理论的阐述了大型项目发布的问题，不论是否参与过这样的发布, 都值得学习一下。