大家是如何发布网站或服务的？

Question

提一些更为具体、简单的问题！如果你发布 web 网站，你可以有两种常见形式，一种是使用 ftp 客户端采取“上传”的方式，另一种是使用 svn 采取“checkout”的方式。当然这里的两个名词儿都是举例，你完全可以使用其它类似机制。例如自己开发一个可以更好地比较远程文件跟本地文件差别的客户端，或者使用别的版本管理系统，等等。总之，发布网站是“一键”方式。而且所使用的系统要仅仅发布有所有修改的问题。比如说一个网站下游3000个文件，其中只有35个修改了，那么这个“一键”发布动作就只copy这35个文件，不应该发布多余的文件。

Answer 1

分布式部署环境，通常都会有一个非常简单的分布式任务管理程序支持。那么编写一个几行的脚本，然后提交给 master 机器，就会被所有的 woker 机执行了。这就执行发布动作。分布式部署，比如说有10台服务器，你可以随时把其中3台机器的电源关掉，或者仅仅更新其中5台机器的版本，也不会影响系统服务。相信你知道这个道理。一般来说，分布式系统发布的“回滚”的说法出现在一些有许多闲钱、闲人的公司。对于其它公司而言，如果发布遇到问题，重新发布一下之前的版本就行了。纠结于“回滚”反而会是有一堆的bug的。

Answer 2

如果你还想追到“根源”，其实最初的发布在于——ghost自动化。我们可以做一个ghost文件，然后交给网管，告诉他“你把这个ip列表下的30台机器给我ghost一下”。他会告诉你“好的，10分钟以后就能用了”。这是所有系统发布的最根本的保障。只不过“10分钟太慢”。而重新发布一个服务通常只需要等待1~2分钟，重新发布一个插件通常只需要10秒钟。所以不常用ghost方式。

Answer 3

那么，大家都是如何协调源码管理、持续集成、增量发布、出错回滚的？如何解决多人并行发布的问题？都使用了什么工具？ 源码管理，就是你上面提到的vss、svn咯，所以代码变动必然要进行统一管理
至于你讲的持续集成、增量发布，这个有什么好讲的呢？客户用了你的软件，发现bug；或者客户提出需求变更、增加新需求，都是需要响应的嘛。出错回滚，这个就需要有一个好的更新机制了。
我们通常是这样：
待发布目录（每次要更新的东东，单独创建一个文件夹，文件夹以日期命名，这样保证上次发布的东东单独留档，如果本次发布出现异常，直接拿上一次的东西做新一次发布，也就是还原上次版本）
更新目录（从待发布目录拷贝最新待发布项，供客户端更新）
（上面这个回滚是基于c/s的，b/s的同样可以借鉴。概括一句话就是，发布新版本前备份上次的东东，以便版本回滚）至于你讲的分布式部署，可以考虑搞一个一键发布
一键发布分三步：
1、获取最新代码、编译
2、生成更新文件、拷贝到分布式服务器
3、重启分布式服务器iis（这个目前需要手工重启，批处理统一重启，搞不定）

Answer 4

找专门人员发布，每次上传文件先提交文档，记录文件MD5值，上传到哪个服务器，做好回滚准备（主要是回滚SQL和旧文件）
由专门人员统计并行发布是否有文件冲突，如果有的话需要由开发人员需要做代码合并因为问的是网站或者服务，所以要发布要通知客户并且停止服务，所以一般是深夜.....除非重大更新，否则开发找不到人的以上是理想状况
现实总是紧急而且残酷的.....

Answer 5

没有自动发布工具，只能oneclick方式release发布