代码上线

    

代码上线

 

1.1 早期手动部署代码

 

纯手动scp上传代码

 

纯手动登陆,Git pull或者SVN update

 

纯手动xftp上传代码

 

开发发送压缩包,rz上传,解压部署代码

 

1.1.1 缺点

 

全程运维参与,占用大量时间

 

如果节点多,上线速度慢

 

人为失误多,目录管理混乱

 

回滚不及时,或者难以回退

 

SVN目录组织结构说明:

 

1 tree /home/oldboy/svn/

 

2 home /oldboy/svn/

 

3 |–branch #分支为测试使用,几个以上的项目必须开分支,测试需要本分支通过,主线合并到分支通过,才能合并到主线进行测试

 

4 |–tags #版本记录用 5 –trunk #主线,与正式先相对应,当天不上线文件不允许提交 

 

以上为SVN开发人员目录情况

 

1.2 小型公司代码上线案例

 

 

 

1.2.1 现状分析

 

小型公司一般只有几个开发人员,且网站核心程序大多数都是PHP语言开发。为了方便会直接通过FTP直接上传程序代码到线上服务器,随时随地上线更新

 

1.2.2 特点问题

 

01.发布快且及时,随时随地就可以发布代码

 

02.开发人员发布的代码不经过测试人员的测试,且用户访问页面刷新页面即改变,也可能刷新瞬间程序在更新,到时无法访问,对网站用户的体验比较差,如果开发写错了代码,造成的影响就更大了,这是拿用户作为测试的上线方案

 

03.据统计,网站中50%以上的故障是开发和开发程序的代码有关(开发写错了一个循环代码导致了死循环,此时大量的用户访问这个程序,就能把服务器资源耗尽,搞死服务器)

 

04.在中小公司,网站出了问题,一般是运维人员的问题(如网站宕机)但这种情况呢下,问题大多可能由开人员或者代码引起的,这里比较好的策略是开发项目负责制思想

 

1.2.3 架构方案建议(项目负责制)

 

 

01.开发人员需在个人电脑搭建LNMP环境[xampp 一键化集成lamp]测试开发好的网站代码,并在办公室或IDC机房的测试环境测试通过,最好有专职测试人员

 

02.程序代码上线规定时间如三天上线一次,若网站需经常更新可每天下午17点上线,这个看网站业务性质而定,原则即影响用户体验最小(用户体验最好)

 

03.代码上线之前需备份,网站程序出了问题方便回退;另外上传代码时尽可能先传到服务器网站临时目录,传完整后一步mv过去,或通过ln做软链接

 

04.尽量由运维人员管理上线,因为开发人员更在意代码的功能性,而运维更在意服务器的稳定。故网站宕机归运维管就要让运维上线,否则开发随意更新,出了问题运维负责,运维将无法抬头

 

 

1.3 中型公司代码上线案例

 

 

 

1.3.1 现状分析

 

中型企业上线,一般是规范运维人员操作步骤,指定统一的上线操作脚本,备份文件名称,备份文件路径,使操作人性化、统一化、自动化

 

1.4 大型公司代码上线案例

 

大型企业上线一般制度和流程控制较多,比较严谨,下图为某大型企业上线解决方案

 

 

 

上线分为两部分:

 

 

 

1.4.1 架构方案建议

 

 

1)上线的流程里,办公室测试环境-->IDC测试环境-->正式生产环境,所有环境中的所有软件均应版本统一,其次尽量单一否则将后患无穷。开发测试成功,IDC测试就可能有问题(如操作系统,web服务器,jdk,php,tomcat,resin等版本)

 

2)开发团队小组办公内部测试环境测试,代码有问题返回给某开发人员重新开发

 

3)有专门的测试工程师,程序有问题直接返回给开发人员(此时返回的一般为程序的BUG,称为BUG),无问题进行IDC测试

 

4) IDC测试由测试人员和运维人员参与,叫IDCtest,进行程序的压力测试,有问题直接返回给开发人员,无问题进行线上环境上线。

 

5)数台服务器代码分发上线方案举例(JAVA程序)

 

 

 

A:假设同业务服务器有6台,将服务器分为A,B两组,A组三台,B组三台,先对A组进行从负载均衡器上平滑下线,B组正常提供服务,避免服务器因上线影响业务。

 

 

 

B:下线过程是通过脚本将A组服务器从RS(LVS,NGINX,HAPROXY,F5等均有平滑方案)中踢出,避免负裁均衡器将请求发送给A组服务器(此时的时间应该为网站流量少时,一般为晚上)

 

 

 

C:将代码分发到A组服务器的站点目录下,对A组服务器上线并重启服务,并由专业的测试人员进行访问测试,测试成功后,挂上A组的服务器,同时下线B组服务器,B组代码上线操作测试等和A组相同,期间也要观察上线提供服务的服务器状况,有问题及时回滚。

 

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

 

7)大多数门户的前端页面都已经静态或者cache了,因上经动态的部分访问平时就不会特别多

 

 

1.5 其他程序代码上线案例

 

1.5.1 Java程序代码上线的具体方案

 

较大的公司需要分组平滑上线,如先从负载均衡器上摘掉一半的服务器,发布更新代码后重启服务器测试,确认没有问题后挂上更新后的服务器;同时再下线另一半的服务器,然后发布更新代码测试(或直接发布后重启,挂上线)

 

如果前段有DNS智能分析,上线可以分地区上线若干服务器,逐渐普及到全国的服务器,即为灰度发布

 

1.5.1.1  IDC正式上线环节

 

分组上线:A、B两线

 

Nginx为例,三套配置文件:2   一套是全部服务器的配置文件3   一套是A的配置文件4   一套是B的配置文件需要哪一套配置文件,直接cpreload nginx服务即可

 

注意:开发环境、测试环境、生产环境统一系统、软件版本、统一路径、IP、主机名等

 

 

 

1.5.1.2 架构方案建议

 

 

1)本地开发人员取svn代码。当天上线提交到trunk,否则,长期项目单开分支开发,然后在合并主线(trunk)

 

2)办公内网开发测试时,由开发人员或配置管理员通过部署平台jenkins实现统一部署(即在部署平台上控制开发机器从svn取代码,编译,打包,发布到开发机,包名如idc_dep.war)

 

3)开发人员通知或和测试人员一起测试程序,没有问题后,由配置管理员打上新的tag标记。这里要注意:不同环境的配置文件是随代码同时发布的。

 

4)配置管理员,根据上一步的tag标记,checkout出上线代码,并配置好IDC测试环境的所有配置,执行编译,打包[mvn,ant] (php不需要打包),然后发布到IDC内的统一分发服务器

 

5)配置管理员或SA上线人员,把分发的程序代码内容推送到相关测试服务器(包名如idc_test.war),然后通知开发及测试人员进行测试。如果有问题向上回退,继续修改

 

6)如果IDC测试没有问题,继续打好tag标记,此时,配置管理员,根据上步的tag标记,checkout出测试好的代码,并配置好IDC正式环境的所有配置,执行编译,打包[mvn,ant] (php不需要打包),然后发布到IDC内的统一分发服务器主机,准备批量发布

 

7)配置管理员或SA上线人员,把分发的内容推送到相关正式服务器(包名如idc_product.war),然后通知开发及测试人员进行测试,如果有问题直接发布回滚指令

 

 

如果是大型门户网站,全国上线,使用灰度发布

 

 

 

1.5.2 php程序代码上线的具体方案

 

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

 

 

原文地址:https://www.cnblogs.com/henrylinux/p/9750870.html