我的第一个python web开发框架(19)——产品发布相关事项

  • 时间:
  • 浏览:0

  某些某些公司产品开发你还可不能否 是直接上线的,并不能自己预生产环境进行测试,好多某些重大的安全事故可是我原先造成的。比如说没留意sql话语,不小心将生产环境的数据表给清空了;比如说更新后生产环境直接崩溃等具体情况在工作中时有地处。今年我在的公司也试过地处比较严重的难题,媒体商务合作公司的小伙伴开发时代码循环写错了,不能自己经过全面测试就直接发布,APP发版后造成我方生产环境业务接口访问量暴增,短短几天访问量暴涨到6千万,服务器流量、CPU、内存等详细满负荷运行,影响到了某些媒体商务合作公司业务的正常运行,不可能 生产环境非要停,服务器端非要通过快速扩容服务器组为高可用群组处理,客户端通过快速发布新版替换。

  3. 预生产环境测试

  python服务器环境搭建(1)——本地服务器准备

  1. 开发人员自测(开发环境)

  4. 生产环境测试

    本文转自 AllEmpty 博客园博客,原文链接:http://www.cnblogs.com/EmptyFS/p/8149856.html,如需转载请自行联系原作者

  老菜:嗯,系统上线从不一件简单的事情,它可大可小。不可能 准备不充分,有不可能 会某些某些难题出現。你认为写好代码后要为何会 发布?

  python服务器环境搭建(2)——安装相关软件

  2. 测试人员测试(测试环境上)

  1)本地测试环境上测试通过,准备好更新代码包、数据库更新脚本、服务器配置更新脚本和修改说明文档;

2)清空预生产测试旧的数据库与应用程序(对于小版本更新也能直接在旧环境上进行,从不做你這個步操作;另外不可能 数据库数据量比较大时,可继续使用旧环境数据);

3)备份预生产测试环境里的代码、数据库与相关配置文件;

4)获取生产环境中的代码、数据库与相关配置文件,并将它们更新到预生产测试环境中,搭建好也能正常运行

5)你还可不能否 现在现在开始英文发布,新服务器配置文件;

6)更新数据库脚本;

7)更新代码包;

8)运行前后端应用程序,进行全面测试(所有功能都须要跑过一次),检查应用程序不是也能正常运行;

9)不可能 此次更新不需要对原系统产生破坏性变更,应用程序正常后就也能按预发布部署到生产环境上。

10)不可能 须要录入或变更相关配置数据,也能让相关维护人员登陆操作录入或修改内容,并测试通过;

11)导出维护人员录入的数据脚本;

12)再次还原生产环境的代码、数据库与相关配置文件到预生产测试环境中;

13)执行第5步到第7步的操作,并将第11步导出的数据脚本更新到数据库中;

14)执行第8步操作,确认不能自己难题后,发布到生产环境中。

  小白:老大,不好意思又要麻烦你了,项目不可能 弄完,但要发布上线我还一头雾水,有空让我 讲解一下吗?

  前面的内容听起来好像很重复杂化,很重多,不过对于你你這個小站点来说,就不需要不能自己操作了。你首不能自己做的是购买好域名,做好域名备案相关工作;只要购买一台云服务器,按我博客里的教程安装配置好服务器;最后将你的代码发布到服务器上去就也能了。

  正常来说,更新到生产环境的代码是测试过不能自己难题的,但有不可能 某些功能非要在生产环境上也能进行测试,某些某些一般发布后要选原先晚深人夜,没哪些客户使用时来进行的。更新你还可不能否 须要快速进行测试,保证系统上线后运行正常不能自己难题。

  当然包括我在内,你还可不能否 可是我能自己养成自测的习惯,不能自己测试人员的约束,写好代码就往生产环境上扔,出現故障就在生产环境上调测或还原代码,再慢慢改的具体情况。你还可不能否 也以为有不能自己测试都无所谓,最近几年时不时 待在有测试团队的公司里就不一样的,有了约束你还可不能否 ,着实更新效率和效率打大折扣,但代码质量和稳定得到了飞跃性的提升。平时码代码也会习惯性完成后用各种参数跑一下,而使用测试的思维去写代码你还可不能否 ,代码的安全性、严谨性得到了很大的提升。

  常见的更新是热更新,即直接上传更新;有的是使用svn等自动化工具进行同步更新,更新完成后,svn的勾子自动将代码同步到某些服务器上,并重启指的服务;还也能关闭高可用其中原先对外访问的节点来更新测试,等你這個节点内部人员测试不能自己难题,再自动同步到某些节点上;不可能 是微服务架构,还也能使用微服务自动安装发布,自动同步注册更新的功能......不同的企业,服务架构不一样,更新的步骤与依据 可是我同。

  好不容易小白将系统开发完成,对于发布到服务器端并没哪些经验,于是在下班后又找到老菜。

  专业的测试是原先枯燥、重复、非常有耐心且敬业的职位,也是我很佩服的原先岗位。

  一般有测试岗位的公司,后要创建一套测试环境专门给测试人员来进行测试,不可能 测试与开发共用原先环境时,数据某些某些你还可不能否 就会造成混乱,其中一方辛辛酸苦 建的数据,我本人拿来就用,又不可能 技术人员习惯直接打开数据库改数据,某些数据具体情况时不时 改变了,而测试人员以为是bug,造成从从不的困扰。一般来说,开发人员在开发环境上自测不能自己难题你还可不能否 ,才会将代码打包提交给测试人员更新到测试环境上。你這個更新频率一般有的是固定时间,而有的是非常频繁,除非有重大bug测试人员无法继续下去,不可能 每原先版本的更新,测试人员后要从头到尾,按写好的测试用例详细重新跑一次,频繁的更新会造成测试人员工作量非常大。

  老菜:看来得普及一下上线的相关知识才行。

  对于重大版本或变更更新时,预生产环境测试是有严格的更新步骤要求的。在整个预发布测试过程中,须要实时记录下每原先步骤的操作。对于重大更新,下面的步骤有时不可能 须要反复操作多次,原先也能保障更新到生产环境是详细无误的。

  python服务器环境搭建(3)——参数配置

  小白:呃,完成开发后,上传到服务器,只要浏览器也能正常访问...

  对于开发人员自测,某些某些应用程序员都不能自己你這個习惯,多数有的是写完代码,我本人以为肯定不能自己难题,只要往服务器上一扔就完事了,等某些同事或客户使用时进行测试,某些某些你还可不能否 会出現50或各种bug,问起来有的是不可能 粗心、没注意到或不小心造成的,有时等得到反馈时不可能 过上好长一段时间了,系统挂了多久都告诉我。你还可不能否 所在公司就遇过有技术人员原先小难题用了超长时间才开发出来,提交了不知几个次到测试环境有的是通过,bug反复出現,被测试经理骂的狗血淋头的具体情况,我在旁边看着都差点忍不住上去怼上一份。也能看得出来,不能自己自测也是造成测试与开发矛盾的重要原困之一。

  测试前,标准来说测试人员一般分制定测试规范,做好测试计划和写测试用例,测试阶段会分为功能测试(不可能 会有功能1、功能2、功能3等多次测试)、UI测试、兼容性测试、性能测试、安全性测、UAT测试等,完成后要提交一份测试报告。不过某些某些你还可不能否 测试规范、计划和报告后要被省略了,测试用例有时可是我可能 会被略过,每家公司根据我本人的须要也会进行对应的调整。

  正规的产品上线一般也能按下面几个步骤来进行:

  但根据我所接触的众多公司来看,不能自己测试人员的公司就占了多数,各公司的BOSS们甚至技术负责人都不能自己测试的意识,将产品测试交给开发人员或业务人员进行,其产生的后果为何会 样就不得而知了。往小方面说用户体验不好,往大方面说不可能 更新后造成数据丢失,生产环境停机一段时间的具体情况。

  不可能 服务器从有的是那么来越多的影响下,通常预生产环境与生产环境放满原先服务器里,它可是我原先数据库与应用程序的拷贝。条件宽裕时,会在本地搭建原先与生产环境一模一样的环境,来做发布前测试。预生产环境测试,也能帮亲戚亲戚某些人避开某些某些服务器环境因素(配置或包不一致等具体情况)、数据库形态学 或配置因素(数据库形态学 调整未更新或记录参数改变后未同步等具体情况)和sql话语缺乏等难题造成的重大错误。

  自测它是你這個态度,它也是你這個习惯。

  你按下面链接去搭建话语,你的应用程序大体上运行不需要出現哪些难题,下面配置是bate版的服务器环境搭建,是我研究运维配置好的服务器我本人学习后写的,配置好也能正常的访问不需要有那么来越多的难题。不可能 你还可不能否应对高并发,须要在你這個基础上进行调优处理,另外uwsgi最好使用xml配置,不可能 xml和ini所使用的包是不一样的,运行时效率和稳定性相差比较大,亲戚亲戚某些人服务器处理每秒7百多并发可是我使用xml配置的。