一、代码上线方案

### --- 早起手动部署代码

~~~ 纯手动Scp、Rsync上传代码。
~~~ 纯手动登陆,Git pull 或者 Svn update。
~~~ 纯手动xftp、ftp、filezilla上传代码。
~~~ 开发发送压缩包,rz上传,解压部署代码。
### --- 早起手动部署代码——缺点

~~~ 全程运维参与,占用大量时间。
~~~ 如果节点多,上线速度慢。
~~~ 人为失误多,目录管理混乱。
~~~ 回滚不及时,或者难以回退。

上线方案示意图

|NO.Z.00020|——————————|^^  重要  ^^|_运维

二、合理化上线方案

### --- 合理化上线方案说明

~~~ 开发人员(rd)需在个人电脑搭建LAMP环境测试开发好的网站代码,
~~~ 并且在办公室或 IDC机房的测试环境测试通过,最好有专职测试人员(ts)。
~~~ 程序代码上线要规定时间,例如:三天上线一次,如网站需经常更新可每天下午 20 点上线,
~~~ 这个看网站业务性质而定,原则就是影响用户体验最小。
~~~ 代码上线之前需备份,网站程序出了问题方便回退,另外,从上线技巧上讲,
~~~ 上传代码时尽可能先传到服务器网站临时目录,传完整后一步mv过去,
~~~ 或者通过In做软链接— 线上更新代码的思路。如果严格更新,把应用服务器从集群节点平滑下线,
~~~ 然后更新。尽量由运维人员管理上线,对于代码的功能性,开发人员更在意,
~~~ 而对于代码的性能优化和上线后服务器的稳定,运维更在意服务器的稳定,
~~~ 因此,如果网站宕机问题归运维管,就要让运维上线,这样更规范科学。
~~~ 否则,开发随意更新,出了问题运维负责,这样就错了,运维永远无法抬头。

web代码规范化上线流程

|NO.Z.00020|——————————|^^  重要  ^^|_开发人员_02

三、大型企业上线制度和流程

### --- JAVA代码环境上线时,有数台机器同时需要更新或者分批更新 

~~~ 本地开发人员取svn代码。当天上线提交到trunk,否则,长期项目单开分支开发,然后在合并主线(trunk)
~~~ 办公内网开发测试时,由开发人员或配置管理员通过部署平台jenkins实现统一部署,(即在部署平台上控制开发机器从svn取代码,编译,打包,发布到开发机,包名如idc_dep.war).
~~~ 开发人员通知或和测试人员一起测试程序,没有问题后,由配置管理员打上新的tag标记。这里要注意,不同环境的配置文件是随代码同时发布的。
~~~ 配置管理员,根据上一步的tag标记,checkout出上线代码,并配置好IDC测试环境的所有配置,执行编译,打包(mvn,ant)(php不需要打包),然后发布到IDC内的统一分发服务器。
~~~ 配置管理员或SA上线人员,把分发的程序代码内容推送到相关测试服务器(包名如idc_test.war),然后通知开发及测试人员进行测试。如果有问题向上回退,继续修改。
~~~ 如果IDC测试没有问题,继续打好tag标记,此时,配置管理员,根据上步的tag标记,checkout出测试好的代码,并配置好IDC正式环境的所有配置,执行编译,打包(mvn,ant)(php不需要打包),然后发布到IDC内的统一分发服务器主机,准备批量发布。
~~~ 配置管理员或SA上线人员,把分发的内容推送到相关正式服务器(包名如idc_product.war),然后通知开发及测试人员进行测试。如果有问题直接发布回滚指令。
~~~ IDC正式上线的过程对于JAVA程序,可以是AB组分组上线的思路,即平滑下线一半的服务器,然后发布更新代码,重启测试,无问题后,挂上更新后的服务器,同时再平滑下线另一半的服务器,然后发布更新代码测试(或者直接发布后,重启,挂上线)
### --- php程序代码上线的具体方案

~~~ 对于PHP上线方法:发布代码时(也需要测试流程)可以直接发布到正式线临时目录 ,
~~~ 然后mv或更改link的方式发布到正式上线目录 ,不需要重启http服务。这是新朗,赶集的上线方案。
### --- Java程序代码上线的具体方案

~~~ 对于java上线方法:较大公司需要分组平滑上线(如从负载均衡器上摘掉一半的服务器),
~~~ 发布代码后,重启服务器测试,没问题后,挂上上好线的一半,再下另外一半。
~~~ 如果前端有DNS智能解析,上线还可以分地区上线若干服务器,逐渐普及到全国的服务器,这个被称为“灰度发布”,在后面门户网站上线的知识里我们在讲解。

四、代码上线解决方案和注意事项

### --- 代码上线

~~~ # 上线的流程里,办公室测试环境-->IDC测试环境-->正式生产环境,所有环境中的所有软件均应版本统一,其次尽量单一,否则将后患无穷,开发测试成功,IDC测试就可能有问题(如:操作系统,web服务器,jdk,php,tomcat,resin等版本)
~~~ 开发团队小组办公内部测试环境测试(该测试环境属于开发小组维护,或定时自动更新代码),代码有问题返回给某开发人员重新开发。
~~~ 有专门的测试工程师,程序有问题直接返回给开发人员(此时返回的一般为程序的BUG,称为BUG库),无问题进行IDC测试
~~~ IDC测试由测试人员和运维人员参与,叫IDCtest,进行程序的压力测试,有问题直接返回给开发人员,无问题进行线上环境上线。
### --- 数台服务器代码分发上线方案举例(JAVA程序)

~~~ A:假设同业务服务器有6台,将服务器分为A,B两组,A组三台,B组三台,先对A组进行从负载均衡器上平滑下线,B组正常提供服务,避免服务器因上线影响业务。
~~~ B:下线过程是通过脚本将A组服务器从RS池(LVS,NGINX,HAPROXY,F5等均有平滑方案)中踢出,避免负裁均衡器将请求发送给A组服务器(此时的时间应该为网站流量少时,一般为晚上)
~~~ C:将代码分发到A组服务器的站点目录下,对A组服务器上线并重启服务,并由专业的测试人员进行访问测试,测试成功后,挂上A组的服务器,同时下线B组服务器,B组代码上线操作测试等和A组相同,期间也要观察上线提供服务的服务器状况,有问题及时回滚。
### --- PHP程序上线

~~~ 如果是PHP程序,则上线可以简单化,直接将上线代码(最好全量)
~~~ 发布到所有上线服务器的特定目录后,分发完成后,一次性mv或ln到站点目录,
~~~ 当然测试也是少不了的。测试除了人员测试外,还有各种测试脚本测试各个相关业务接口。











Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

                                                                                                                                                   ——W.S.Landor