代码迭代的几种方式

1. 直接替换代码
这种适用于本身的博客，多数是托管在虚拟空间上，没有git一类的进行版本管理，一些很技术很低端的公司，也会这样进行迭代，在测试服务器上，数据正常了，而后在正式服务器上，直接覆盖代码，完成版本迭代。

这样作除了增长自信，省时间，其余的基本都没什么好处，不推荐。

延伸： 你甚至能够在服务器上，复制一份正式用的代码，到一个htdocs下的新目录，而后用一个端口或者新域名指向这个目录，将准备迭代的代码覆盖到这个目录，测试没有bug以后，在能够复制到正式的目录，或者直接用apache/nginx指向此目录。

2. git进行分支控制

在测试服务器上，甚至是其余git仓库，开发人员在本地开发，测试，而后将代码提交到仓库中，在正式服务器上，也有一个git，有两个分支，用户访问的正式文件目录是master分支，而后有一个develop分支，从develop分支远程pull代码，再将develop分支的代码合并到master分支，若是有bug，小bug能够在本地修复，执行相同流程进行合并到master分支，完成修复，若是有大型bug，能够回滚代码，修复以后，执行相同的合并流程，完成更新。

延伸： git是一种很强大的工具，能够有更多应用，参加Git Flow http://blog.jobbole.com/76867/
高度使用git flow能解决更多状况，例如上线一个版本以后，下一个迭代计划开发10个功能，在开发了2.5个功能的时候，线上代码发现bug，须要修复，这种状况下，咱们不能将开发中的2.5个功能合并到线上，因此单纯的develop/master分支不能知足须要，git flow能够解决这样的问题。

3. nginx分发一部分流量，灰度上线
在大流量的网站，通常是多台服务器，此时可使用其中一台服务器，进行灰度上线，即将代码提交到此服务器，而后使用nginx/apache控制，分发一部分流量到此服务器，检测代码运行状况和日志，若是有bug,能够继续用nginx/apache将流量今后台服务器关停，修复bug以后，继续给此服务器分发流量，无bug状况下，总体更迭。

其余我也不太熟悉了，这几种状况均可以进行不少详细的操做和权限管理，防止破坏或者操做失误致使问题。

来自http://river0314.lofter.com/p... 个人原创文章