代码发布的3种方式

如果多服务器的话，代码发布要做到高效，不出错，还是要花点心思的。下面说3种方法，都是我使用过的。

一，sftp配合rsync

这种方法是我最早使用的一种方法，通过sftp传其中一台服务器，然后通过rsync同步到其他服务器。

优点：传代码只要传到其中一台，通过rsync进行同步。

缺点：

1，sftp上传的时候，还是要人为参与的，如果上传错误，并且没有及时发现，还是比较严重的。

2，rsync是有时间间隔的，多多少少有点时间差

二，自己写脚本进行上传

使用这种方法，最好测试服务器和正式服务器之间不需要密码登录，直接scp就能从测试服务器到正式服务器，不然shell会比较复杂，要用到expect。

在测试服务器上，通过shell脚本，把最近修改过的文件找出来，需要上传时，同时传到多个服务器。

优点：实时性比较高，人为因素比较少，shell脚本多测试几次，基本上不会有什么问题。

缺点：

1，对shell要有一定的了解，有一定的学习成本。

2，开发到发布，时间跨度比较长的话，用这种方法不怎么合适了，可能会出现大量的文件要上传。

三，git双远程服务端模式

1，单git远程服务端的优，缺点

我现在了解到的，大部分都是单远程服务端的模式，开发者，测试服务器，正式服务器都共用一个git远程服务端。

缺点：单远程服务端要求传到git上传的代码， 要是能运行的。并且在正式服务器从git服务端pull代码的时候，千万不要在有人传代码。不然就会乱了。如果开发人员众多的话，很难去管理。git同步也是有时间差的。

优点：单点模式比较简单，结构清晰

2，双git远程服务端的优，缺点

在我看来，不管代码是否能运行，都应当能提交到git远程服务端。假如在开发一块东西，没有提交到远程服务器，放在本地的git服务端，突然哪一天硬盘坏了，就郁闷了。

缺点：需要搭建二个git远程服务端，管理比较麻烦一点。git同步也是有时间差的。

优点：2个git服务端，一个给开发用，不管代码能不能运行都可以提交。一个做为正式服务器发布代码用。平时分开，上线的时候，确保本地，二个git远程服务端代码一致就行了。