好不容易小白将系统开发完成,对于发布到服务器端并无什么经验,因而在下班后又找到老菜。html
小白:老大,很差意思又要麻烦你了,项目已经弄完,但要发布上线我还一头雾水,有空帮我讲解一下吗?python
老菜:嗯,系统上线并不一件简单的事情,它可大可小。若是准备不充分,有可能会不少问题出现。你认为写好代码后要怎么发布?程序员
小白:呃,完成开发后,上传到服务器,而后浏览器能够正常访问...sql
老菜:看来得普及一下上线的相关知识才行。数据库
正规的产品上线通常能够按下面几个步骤来进行:后端
1. 开发人员自测(开发环境)浏览器
2. 测试人员测试(测试环境上)安全
3. 预生产环境测试服务器
4. 生产环境测试架构
但根据我所接触的众多公司来看,没有测试人员的公司就占了多数,各公司的BOSS们甚至技术负责人都没有测试的意识,将产品测试交给开发人员或业务人员进行,其产生的后果怎么样就不得而知了。往小方面说用户体验很差,往大方面说可能更新后形成数据丢失,生产环境停机一段时间的状况。
对于开发人员自测,不少程序员都没有这个习惯,多数都是写完代码,本身觉得确定没有问题,而后往服务器上一扔就完事了,等其余同事或客户使用时进行测试,不少时候会出现500或各类bug,问起来都是由于粗心、没注意到或不当心形成的,有时等获得反馈时已通过上好长一段时间了,系统挂了多久都不知道。之前所在公司就遇过有技术人员一个小问题用了超长时间才开发出来,提交了不知多少次到测试环境都不经过,bug反复出现,被测试经理骂的狗血淋头的状况,我在旁边看着都差点忍不住上去怼上一份。能够看得出来,没有自测也是形成测试与开发矛盾的重要缘由之一。
固然包括我在内,之前也没有养成自测的习惯,没有测试人员的约束,写好代码就往生产环境上扔,出现故障就在生产环境上调测或还原代码,再慢慢改的状况。之前也觉得有没有测试都无所谓,最近几年一直待在有测试团队的公司里就不同的,有了约束之后,虽然更新效率和速度打大折扣,但代码质量和稳定获得了飞跃性的提高。平时码代码也会习惯性完成后用各类参数跑一下,而使用测试的思惟去写代码之后,代码的安全性、严谨性获得了很大的提高。
自测它是一种态度,它也是一种习惯。
通常有测试岗位的公司,都会建立一套测试环境专门给测试人员来进行测试,由于测试与开发共用一个环境时,数据不少时候就会形成混乱,其中一方辛辛苦苦建的数据,另外一方拿来就用,又或者技术人员习惯直接打开数据库改数据,某些数据状态忽然改变了,而测试人员觉得是bug,形成没必要要的困扰。通常来讲,开发人员在开发环境上自测没有问题之后,才会将代码打包提交给测试人员更新到测试环境上。这个更新频率通常都在固定时间,而不是很是频繁,除非有重大bug测试人员没法继续下去,由于每个版本的更新,测试人员都会从头至尾,按写好的测试用例所有从新跑一次,频繁的更新会形成测试人员工做量很是大。
测试前,标准来讲测试人员通常分制定测试规范,作好测试计划和写测试用例,测试阶段会分为功能测试(可能会有功能一、功能二、功能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 本文欢迎转载,但未经做者赞成必须保留此段声明,且在文章页面明显位置给出原文链接,不然视为侵权。
python开发QQ群:669058475(本群已满)、733466321(能够加2群) 做者博客:http://www.cnblogs.com/EmptyFS/