小型企业上线架构方案
1、开发人员需在个人电脑搭建LAMP环境测试开发好的网站代码，并且在办公室或IDC机房的测试环境测试通过，最好有专职测试人员。
2、程序代码上线规定时间，由网站业务性质而定，原则就是影响用户体验最小。
3、代码上线之前需备份，网站程序出了问题方便回退，另外，从上线技巧上将，上传代码时尽可能先传到服务器网站临时目录，传完整后一步mv过去，或者通过ln做软连接。
线上更新代码的思路。如果严格更新，把应用服务器从集群节点平滑下线，然后更新。
4、尽量由运维人员管理上线，对于代码的功能性，开发人员更在意，而对于代码的性能优化和上线后服务器的稳定，运维更在意服务器的稳定，因此，如果网站宕机问题归运维管，就要让运维上线，这样更规范科学。否则，开发随意更新，出了问题运维负责，这样就错了，运维永远无法抬头。
中型企业上线解决方案
一般是规范运维人员操作步骤，制定统一的上线操作脚本备份文件名称、备份文件路径。使操作人性化，统一化，自动化。
web代码的上线流程：
1、开发组内部测试
2、测试组内外网测试
3.1、重要升级—》运维组备份
3.2、普通升级—》上线
4、回滚后上线—-》运维组代码回滚
4.1.2、用户应用
4.1.2.2、有问题—–》运维组代码回滚
4.1.2.3、上线
大型企业上线解决方案
ITIL,BSW规范。
大型企业java代码上线流程图
svn服务器上主要管理：
1.程序代码
2.服务的配置
3.项目文档，设计文档，运维部署优化文档
上线时，大型集群环境一般有数台及其集群，因此，同时需要更新或者分批更新。
1.本地开发人员从svn中取代码。当天上线的天机到trunk，否则，长期项目单开分支开发，然后再合并主线（trunk）
2.办公内网开发测试时，由开发人员或配置管理员通过部署平台jenkins实现统一部署，（即在部署平台上控制开发及其从svn取代码，编译，打包，发布到开发机，包名如dep.war）
3.开发人员通知或和测试人员一起测试程序，没有问题后，由配置管理员打上新的tag标记
4.配置管理员，根据上步的tag标记，checkout出上线代码，并配置好IDC测试环境的所有配置，执行编译，打包(maven,ant)(pho不需要)，然后发布到IDC内的统一分发服务器，这里要注意，不同环境的配置文件是随代码同时发布的。
5.配置管理员或SA上线人员，把分发的程序代码内容推送到相关测试服务器，然后通知开发及测试人员进行测试。如果有问题向上回退，继续修改。
6.如果IDC测试没有问题，继续打好tag标记，此时，配置管理员，根据上步的tag标记，checkout出测试好的代码，并配置好IDC正式环境的所有配置，执行编译，打包（maven,ant），然后发布到IDC内的统一分发服务器主机，准备批量发布。
7.配置管理员或者SA上线人员，把分发的内容推送得到相关正式服务器，然后通知开发及测试人员进行测试。如果有问题直接发布回滚指令。
IDC正式上线的过程对于JAVA程序，可以是AB组上线的思路，即平滑下线一般的服务器，然后发布更新代码，重启然后测试，无问题后，挂上更新后的服务器，同时在平滑下线另一半的服务器，然后发布更新代码测试（或者直接发布后，重启，挂上线）
PHP程序代码上线的具体方案
对于php上线方法：发布代码时（也需要测试流程）可以直接发布到正式临时目录，然后mv或更改link的方式发布到正式线目录，不需要重启http服务。
JAVA程序代码上线的具体方案
较大公司需要分组平滑上线，例如，首先从负载均衡器上摘掉一半的服务器，发布代码后，重启服务器测试，没问题后，挂上上好线的一半，再下另外一半。如果前端有DN智能解析，上线还可以分地区上线若干服务器，逐渐普及得到全国的服务器，这个被称为灰度发布。
代码上线解决方案注意事项
1.上线的流程里，版本测试环境–》IDC测试环境–》正式生产环境，所有的环境中的所有软件均应版本统一，其次，尽量单一，否则将后患无穷，开发测试成功，IDCC测试就可能有问题。
例如：操作系统、web服务器，jdk，php，tomcat,resin等版本
2.开发团队小组办公室内部测试环境测试（该测试环境属于开发小组维护，或定时自动更新代码），代码有问题返回给某开发人员重新开发。
3.有专门的测试工程师，程序有问题直接返回给开发人员（此时返回的一般为程序的bug，称为bug库），无问题进行IDC测试
4.IDC测试由测试人员和运维人员参与，叫IDCtest,进行程序的压力测试，有问题直接返回给开发人员，无问题进行线上环境上线
5.数台服务器代码分发上线方案（java）:
5.1.假设同业务服务器有6台，将服务器分为a、b两组，a组三台,b组三台,先对a组进行从负载均衡器上平滑下线，b组正常提供服务，避免服务器因上线影响业务。
5.2.下线过程是通过脚本将a组服务器从rs池(lvs,nginx,haproxy,f5等均有平滑方案)中踢出，避免负载均衡器将请求发送给a组服务器（此时的时间应该为网站流量少时，一般为晚上）
5.3.将代码分发到a组服务器的站点目录下，对a组服务器上线并重启服务，并由专业的测试人员进行访问测试，测试成功后，挂上a组的服务器，同时下线b组服务器，b组代码上线操作测试等和a组相同，期间也要观察上线提供服务的服务器状态，有问题时及时回滚。
6.如果是php程序，则上线可以简单化，直接将上线代码（最好全量）发布到所有上线服务器的特定目录后，分发完成后，一次性mv或ln到站点目录，当然测试也是少不了的，测试出了人员测试外，还有各种测试脚本测试各个相关业务接口
7.大多数门户公司的前端页面都已经静态化或者cache了，因此，动态的部分访问平时就不会特别多，流量低谷时就更少了，再加上是平滑上下线，因此基本上是对用户体验无影响的。
8.svn上包含代码和配置
8.1 svn上存放程序代码（不含资源，大公司网站资源和程序分离的），尽可能全量上线
8.2 存放所有服务的配置文件（lamp环境，如:apache的httpd.conf配置文件）
8.2.1 开发小组测试环境使用的配置文件
8.2.2 办公测试环境使用的配置文件
8.2.3 IDC测试环境使用的配置文件
8.2.4 线上应用使用的配置文件
在上线不同环境时，由配置管理员协调上线
什么是配置管理员？
就是在开发和运维中间起一个连接纽带的一个职位，这个职位一般在大公司里会设置，负责svn的管理，上线管理，申请，协调等工作
自动化部署和上线代码管理平台
对于门户网站或重视规范或开发能力较强的公司也许会结合系统服务和web界面管理来更科学更自动的进行上线代码管理，如开发一个自动化代码上线部署平台，其实就是一个web管理界面（界面底层调用相关脚本实现分发推送代码以及重启服务器），然后普通的初级上线人员就可以再平台里实现仅仅点鼠标、敲回车，就能实现平滑上线和平滑回滚代码了。
开发自化部署平台的思路很多，例如：可以通过nagiios的被动模式实现上线管理平台原理思路：
实际上就是生成配置在分发服务器上执行命令请求，应用服务器，然后脚本在应用服务器处理完毕后回传结果到web界面显示
开发人员和运维人员业务变更管理平台
业务变更管理平台优点：
1.变更管理制度流程有利于业务稳定
2.保留变更业务历史，便于核查发现的问题
3.故障跟踪平台，有利于跟踪问题的解决进度，而不是半途而废
4.相关常用软件：
4.1 FIRA用户缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪和敏捷管理等工作领域
4.2 mantis是一款php开源bug跟踪系统，比较适合中小型项目的管理及跟踪，具有多特性包括：易于安装，易于操作，基于web，支持任何可运行php的平台（windows,linux,max,solaris,as4000/i5等），已经被翻译成68种语言，支持多个项目，为每一个项目设置不同的用户访问级别，跟踪缺陷变更历史，定制我的视图页面，提供全文搜索功能，内置报表生成功能（包括图形报表），通过email报告缺陷，用户可以监视特殊对待bug，附件可以保存在web服务器上或数据库中（还可以备份到ftp服务器上）,自定义缺陷处理工作流，支持输出格式包括csv、microsoftExcel、microsoftWord,集成源代码控制(svn与cvs)，集成wiki知识库与聊天工具（可选/不可选），支持多种数据库（mysql,mssql,postgresq,oracle,db2）,提供webService(soap接口)，提供wap访问
灰度：
专业名词叫bucket test ,就是桶检测，抽一部分用户去检测。这个有几种方式，一个是按流量比例来抽，按流量比例来抽就是随机命中的，有可能有百分之百的用户有可能都会被命中。还有种情况是根据用户来抽，比若说根据用户的cookie来判断是不是该进入到桶里面。一般都是针对核心业务的。