背景

手机客户端按一定周期发版，但是客户不一定会及时更新到最新版本，所以需要服务端能支持旧版手机客户端。

服务端支持旧版手机客户端的方式主要有：

• 相同的接口支持不同版本手机端的请求，需要服务端接口做好兼容
• 不同的接口支持不同版本手机端的请求，需要服务端根据版本号调用不同的接口

第2种方式的实现方式主要有：

• 服务端只部署一套代码，根据版本号引入相应的控制器处理手机端的请求
• 服务端根据版本号部署多套代码，根据版本号将手机端的请求转发到相应的上游服务

由于当时服务端接口修改了返回值结构，不能兼容旧版本手机端，而且需要上线新版本代码，所以采用部署多套代码的方式。
重构完成后，即可采用部署一套代码的方式。

Nginx配置

以下是配置例子，里面只有和版本有关的地方，如果与线上服务器配置的有差异，则以线上服务器的为准。

server {
    listen 8191;
    server_name     api.test.cn;
    root            /home/wwwroot/testlist-1.9.1/API;
    access_log      /home/wwwlogs/testlist-api-1.9.1-access.log;
    error_log       /home/wwwlogs/testlist-api-1.9.1-error.log;
}
server {
    listen 8192;
    server_name     api.test.cn;
    root            /home/wwwroot/testlist-1.9.2/API;
    access_log      /home/wwwlogs/testlist-api-1.9.2-access.log;
    error_log       /home/wwwlogs/testlist-api-1.9.2-error.log;
}
server {
    listen 8193;
    server_name     api.test.cn;
    root            /home/wwwroot/testlist-1.9.3/API;
    access_log      /home/wwwlogs/testlist-api-1.9.3-access.log;
    error_log       /home/wwwlogs/testlist-api-1.9.3-error.log;
}
server {
    listen 8194;
    server_name     api.test.cn;
    root            /home/wwwroot/testlist-1.9.4/API;
    access_log      /home/wwwlogs/testlist-api-1.9.4-access.log;
    error_log       /home/wwwlogs/testlist-api-1.9.4-error.log;
}
server {
    listen 8195;
    server_name     api.test.cn;
    root            /home/wwwroot/testlist-1.9.5/API;
    access_log      /home/wwwlogs/testlist-api-1.9.5-access.log;
    error_log       /home/wwwlogs/testlist-api-1.9.5-error.log;
}
server {
    listen 8196;
    server_name     api.test.cn;
    root            /home/wwwroot/testlist-1.9.6/API;
    access_log      /home/wwwlogs/testlist-api-1.9.6-access.log;
    error_log       /home/wwwlogs/testlist-api-1.9.6-error.log;
}
server {
    listen 80;
    server_name     api.test.cn;
    root            /home/wwwroot/testlist/API;
    access_log      /home/wwwlogs/testlist-api-access.log;
    error_log       /home/wwwlogs/testlist-api-error.log;

    set $version_port '8196';
    if ($http_version ~ '^1\.([0-8]\.[0-9]|9\.[0-1])(\.[0-9]*)?$') {
        set $version_port '8191';
    }
    if ($http_version ~ '^1\.9\.2(\.[0-9]*)?$') {
        set $version_port '8192';
    }
    if ($http_version ~ '^1\.9\.3(\.[0-9]*)?$') {
        set $version_port '8193';
    }
    if ($http_version ~ '^1\.9\.4(\.[0-9]*)?$') {
        set $version_port '8194';
    }
    if ($http_version ~ '^1\.9\.5(\.[0-9]*)?$') {
        set $version_port '8195';
    }
    if ($http_version ~ '^1\.9\.6(\.[0-9]*)?$') {
        set $version_port '8196';
    }
    location / {
        proxy_pass  http://127.0.0.1:$version_port ;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Real-Port $remote_port;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

部署流程

dev分支开发完成后，合并到master分支。
可以某个功能点开发完成就立即合并，这样review代码的时候容易检查到问题。

以下以部署1.9.6版为例。

合并到master分支后，基于master分支新建生产分支1.9.6和开发分支1.9.6-dev。
然后将生产分支的代码部署到线上服务器，部署过程主要有以下工作步骤：

• 通过ftp工具（例如bcompare）上传代码到线上服务器的新目录，例如：testlist-1.9.6
• 修改代码里的配置文件，例如：Application/Common/Conf/config.php 里的数据库配置
• 删除upload目录，并新建符号链接到testlist-upload：rm -rf upload && ln -s ../testlist-upload upload
• 新建Nginx服务配置，在 /usr/local/nginx/conf/vhost/api.test.cn.conf 里复制一个端口号为8195的
• 修改端口号为8196，修改web根路径为 testlist-1.9.6/API，修改日志文件的文件名版本号为1.9.6
• 修改Nginx服务配置，在上述文件里找到端口号为80和443的
• 复制一个1.9.5相关的版本号判断，改为1.9.6的版本号判断，同时修改$version_port的初始值为8196
• 加载Nginx的新配置：lnmp nginx reload
• 如果需要增加数据表或者字段，就通过phpMyAdmin或者别的工具做好数据表和字段的准备

以上步骤完成后，即可通过新版手机端测试各个接口功能是否正常。
如果PC端已经在内网测试完成，即可将线上PC端指向1.9.6版：rm -f testlist && ln -s testlist-1.9.6 testlist

部署好之后，当需要在这个版本中修改功能或者修复Bug时，先在相应的开发分支1.9.6-dev中开发。
开发完成后在内网测试，然后合并到生产分支1.9.6中，并部署所修改代码到线上服务器的相应目录里。
如果所做修改需要应用到将来版本中，则通过git cherry-pick命令，将其挑选到开发分支dev中；
也可以先挑选到生产分支master中，再合并到开发分支dev中。
如果所做修改需要应用到其他已有版本中，则一样地挑选到其他已有版本中，并部署到线上服务器的相应目录里。