好不容易小白将系统开发完成，对于发布到服务器端并没有什么经验，于是在下班后又找到老菜。
小白：老大，不好意思又要麻烦你了，项目已经弄完，但要发布上线我还一头雾水，有空帮我讲解一下吗？
老菜：嗯，系统上线并不一件简单的事情，它可大可小。如果准备不充分，有可能会很多问题出现。你认为写好代码后要怎么发布？
小白：呃，完成开发后，上传到服务器，然后浏览器可以正常访问...
老菜：看来得普及一下上线的相关知识才行。
正规的产品上线一般可以按下面几个步骤来进行：
1. 开发人员自测（开发环境）
2. 测试人员测试（测试环境上）
3. 预生产环境测试
4. 生产环境测试
但根据我所接触的众多公司来看，没有测试人员的公司就占了多数，各公司的BOSS们甚至技术负责人都没有测试的意识，将产品测试交给开发人员或业务人员进行，其产生的后果怎么样就不得而知了。往小方面说用户体验不好，往大方面说可能更新后造成数据丢失，生产环境停机一段时间的情况。
对于开发人员自测，很多程序员都没有这个习惯，多数都是写完代码，自己以为肯定没有问题，然后往服务器上一扔就完事了，等其他同事或客户使用时进行测试，很多时候会出现500或各种bug，问起来都是因为粗心、没注意到或不小心造成的，有时等得到反馈时已经过上好长一段时间了，系统挂了多久都不知道。以前所在公司就遇过有技术人员一个小问题用了超长时间才开发出来，提交了不知多少次到测试环境都不通过，bug反复出现，被测试经理骂的狗血淋头的情况，我在旁边看着都差点忍不住上去怼上一份。可以看得出来，没有自测也是造成测试与开发矛盾的重要原因之一。
当然包括我在内，以前也没有养成自测的习惯，没有测试人员的约束，写好代码就往生产环境上扔，出现故障就在生产环境上调测或还原代码，再慢慢改的情况。以前也以为有没有测试都无所谓，最近几年一直待在有测试团队的公司里就不一样的，有了约束以后，虽然更新效率和速度打大折扣，但代码质量和稳定得到了飞跃性的提升。平时码代码也会习惯性完成后用各种参数跑一下，而使用测试的思维去写代码以后，代码的安全性、严谨性得到了很大的提升。
自测它是一种态度，它也是一种习惯。
一般有测试岗位的公司，都会创建一套测试环境专门给测试人员来进行测试，因为测试与开发共用一个环境时，数据很多时候就会造成混乱，其中一方辛辛苦苦建的数据，另一方拿来就用，又或者技术人员习惯直接打开数据库改数据，某些数据状态突然改变了，而测试人员以为是bug，造成不必要的困扰。一般来说，开发人员在开发环境上自测没有问题以后，才会将代码打包提交给测试人员更新到测试环境上。这个更新频率一般都在固定时间，而不是非常频繁，除非有重大bug测试人员无法继续下去，因为每一个版本的更新，测试人员都会从头到尾，按写好的测试用例全部重新跑一次，频繁的更新会造成测试人员工作量非常大。
测试前，标准来说测试人员一般分制定测试规范，做好测试计划和写测试用例，测试阶段会分为功能测试（可能会有功能1、功能2、功能3等多次测试）、UI测试、兼容性测试、性能测试、安全性测、UAT测试等，完成后会提交一份测试报告。不过很多时候测试规范、计划和报告都会被省略了，测试用例有时也可能会被略过，每家公司根据自己的需要也会进行对应的调整。
专业的测试是一个枯燥、重复、非常有耐心且敬业的职位，也是我很佩服的一个岗位。
很多公司产品开发完后是直接上线的，并没有预生产环境进行测试，好多一些重大的安全事故就是这样造成的。比如说没留意sql语句，不小心将生产环境的数据表给清空了；比如说更新后生产环境直接崩溃等情况在工作中时有发生。今年我在的公司也试过发生比较严重的问题，合作公司的小伙伴开发时代码循环写错了，没有经过全面测试就直接发布，APP发版后造成我方生产环境业务接口访问量暴增，短短几天访问量暴涨到6千万，服务器流量、CPU、内存等全部满负荷运行，影响到了其他合作公司业务的正常运行，由于生产环境不能停，服务器端只能通过快速扩容服务器组为高可用群组解决，客户端通过快速发布新版替换。
如果服务器并不是太多的影响下，通常预生产环境和生产环境放在一个服务器里，它只是一个数据库与程序的拷贝。条件充足时，会在本地搭建一个和生产环境一模一样的环境，来做发布前测试。预生产环境测试，可以帮我们避开很多服务器环境因素（配置或包不一致等情况）、数据库结构或配置因素（数据库结构调整未更新或记录参数改变后未同步等情况）和sql语句缺陷等问题造成的重大错误。
对于重大版本或变更更新时，预生产环境测试是有严格的更新步骤要求的。在整个预发布测试过程中，必须实时记录下每一个步骤的操作。对于重大更新，下面的步骤有时可能需要反复操作多次，这样才能保障更新到生产环境是完全无误的。
1)本地测试环境上测试通过，准备好更新代码包、数据库更新脚本、服务器配置更新脚本和修改说明文档；
2)清空预生产测试旧的数据库与程序（对于小版本更新可以直接在旧环境上进行，不必做这一步操作；另外如果数据库数据量比较大时，可继续使用旧环境数据）；
3)备份预生产测试环境里的代码、数据库与相关配置文件；
4)获取生产环境中的代码、数据库与相关配置文件，并将它们更新到预生产测试环境中，搭建好可以正常运行；
5)开始发布，新服务器配置文件；
6)更新数据库脚本；
7)更新代码包；
8)运行前后端程序，进行全面测试（所有功能都必须跑过一次），检查程序是否可以正常运行；
9)如果此次更新不会对原系统产生破坏性变更，程序正常后就可以按预发布部署到生产环境上。
10)如果需要录入或变更相关配置数据，可以让相关维护人员登陆操作录入或修改内容，并测试通过；
11)导出维护人员录入的数据脚本；
12)再次还原生产环境的代码、数据库与相关配置文件到预生产测试环境中；
13)执行第5步到第7步的操作，并将第11步导出的数据脚本更新到数据库中；
14)执行第8步操作，确认没有问题后，发布到生产环境中。
正常来说，更新到生产环境的代码是测试过没有问题的，但有可能有些功能只能在生产环境上才能进行测试，所以一般发布都会选一个晚深人夜，没有什么客户使用时来进行的。更新以后需要快速进行测试，保证系统上线后运行正常没有问题。
常见的更新是热更新，即直接上传更新；也有使用svn等自动化工具进行同步更新，更新完成后，svn的勾子自动将代码同步到其他服务器上，并重启指的服务；还可以关闭高可用其中一个对外访问的节点来更新测试，等这个节点内部测试没有问题，再自动同步到其他节点上；如果是微服务架构，还可以使用微服务自动安装发布，自动同步注册更新的功能......不同的企业，服务架构不一样，更新的步骤与方式也不同。
前面的内容听起来好像有点复杂，有点多，不过对于你这个小站点来说，就不用那么操作了。你首先要做的是购买好域名，做好域名备案相关工作；然后购买一台云服务器，按我博客里的教程安装配置好服务器；最后将你的代码发布到服务器上去就可以了。
你按下面链接去搭建的话，你的程序大体上运行不会出现什么问题，下面配置是bate版的服务器环境搭建，是我研究运维配置好的服务器自己学习后写的，配置好后能正常的访问不会有太大的问题。如果想要应对高并发，需要在这个基础上进行调优处理，另外uwsgi最好使用xml配置，因为xml和ini所使用的包是不一样的，运行时效率和稳定性相差比较大，我们服务器处理每秒7百多并发就是使用xml配置的。
本文转自 AllEmpty 博客园博客，原文链接：http://www.cnblogs.com/EmptyFS/p/8149856.html，如需转载请自行联系原作者
