基于前后端分离的模式，有以下思考和实践，并对Devops知识的复习：
1.需求介入
2.DevOps
1.需求理解和功能设计
需求介入除了需求拆解和功能设计，还可以做几个事情，
首先是需求场景的设计，有感于BDD的想法，从业务角度设计的业务测试场景，用纯业务的语言或者自然语言编写，用于设计回顾和回归的e2e测试；
然后是功能设计的UI，前后端分离的应用，不管使用VueUI/ReactUI，对应的UI设计工具Axure/Sketch etc都有对应模版，可以生成对应的前端html和css，方便前端开发、业务功能沟通和回顾、页面风格统一、UI自动化测试。
让同事做过小调研，包括功能UI设计素材管理、UI设计工具链、UI设计业界规范，有几方面的思考。
作用于易用性设计
基于UI界面作为需求讨论于功能设计的认识，以小程序为例，分析微信、百度、阿里对页面是怎么规范的，怎么样的UI才有较好的视觉效果、具有较好的易用性、典型好的例子的界面是怎样的，CSS又是怎样设计的。需求变更的调整通过界面反馈效率高。
作用于UI自动化测试
UI自动化测试是吃力不讨好的事情，遍历测试是不依赖业务数据逻辑进行UI自动化测试的一个折衷（App尝试了AppCrawler），大致的思路是针对所有页面元素遍历定位和操作，判断页面显示和报错是否正常。此时，设计好的页面UI的元素和整体页面切片是作为深度学习语料（闲鱼的FireEye）可以用于智能的UI自动化测试。
2.DevOps
完整的 DevOps，包括了 DevOps 的生命周期，下图来展示 DevOps 的生命周期以及它和软件开发生命周期之间的关系。
什么是 CI/CD 流水线？
CI 代表持续集成（Continuous Integration），CD 代表持续交付（Continuous Delivery）和持续部署（Continuous Deployment）。也可以将它们看作是类似于软件开发生命周期的过程。
如上图所示，该流水线展示了一个软件在其最终交付给客户或者投入上线之前，它在其生命周期内各个阶段中的移动过程。
假如构建一款前后端分离的应用程序，并将它部署在 服务器上，假设现在开发团队已经将代码提交到版本控制系统（如：Git，SVN）。
构建阶段
接下来，代码将会经历构建阶段，这也是 CI/CD 流水线的第一阶段。在此之前，开发者已经将他们的代码加上合适的标签，并提交到版本控制系统中了。
假如后端是 Java 语言，那么还需要先进行代码编译。因此，代码在通过版本控制阶段之后，会先在构建阶段予以编译。该阶段会从代码库的各个分支中获取到所有的功能代码，合并后最终通过一个编译器来编译它们。这整个过程都被称为「构建阶段」。
该阶段有几方面的工作：
1.代码静态扫描
目标是依据业务内容选择扫描规则，避免常见问题，统一代码风格，度量代码质量，为CodeReview做准备，业界很多优秀的代码扫描工具，如sonar、p3c、eslint。
后端的SQL主要考虑索引建立和SQL优化，mysqladvisor工具可以一试 。
2.监控代码变更
获取代码变更清单是测试覆盖的前提。
测试阶段
构建阶段结束后，将会继续进入到代码的「测试阶段」。在这个阶段中，更多会做的是单元测试。此阶段的关键是TDD的思维，Unit test 既可以作为代码质量衡量的标准，也可以和代码注释等作为项目资产积累。统一的单元测试标准或者框架是必须的，而合适的Mock也非常重要，提供测试数据的挡板应为单元测试标准之一。
工具上，前端js可以考虑mocha、jasmine…headless类的puppeteer，后端java可以junit，单元测试覆盖率作为此阶段的输出物，codereview的材料。工具可选Sonar+Cobertura 。
部署阶段
测试阶段完成后，就要进入「部署阶段」了。在该阶段，代码将会被部署到准生产环境服务器（staging server）或者测试环境服务器（test server）中。此时需要做环境的冒烟，包括检查网关、防火墙、DB连通性、Web服务、其他技术参数等等自动化的检查脚本。
自动测试阶段
代码部署成功后，需要运行自动化测试包括 UI 、接口、安全、性能，当然还有手工测试。该阶段结束后，如果所有的测试都通过了，那么才可以将其部署到生产环境中了。
自动化测试代码也需要关注代码风格、断言数等，代码风格可以通过注释的方式构建测试脚本与程序或业务场景的关联。
接口方面基于结构化的数据管理，包括表数据、接口元数据、调用关系、数据例子，更好做服务订阅-发布；安全除了AppScan，专项的攻击扫描（ 如SQLi、XSS、日志登记等），人工的渗透攻击（主要从业务逻辑的角度）。
（数据服务中心的IDEA，数据的来源一方面可以来源业务数据脱敏，一方面来源开源领域数据/OWASP payloads，一方面来源Fuzzer Generator，一方面来源于不同系统的数据收集后的复用）
性能监控部署在测试环境，不管LoadRunner、Jmeter、Locust，针对调用多、数据量大的接口的性能测试，需保证质量监控的指标反馈的及时性。
部署到生产环境
可能在每一个阶段的执行过程中遇到一些错误，通过缺陷管理系统反馈开发团队中，以便他们能够及时修复这些错误。当开发团队修复完成后，就可以将代码重新提交到版本控制系统中，然后再次从头开始执行该流水线。
开发计划、测试案例、测试问题的管理，包括问题解决时效、是否瓶颈、开发进度管理等，需求变更和代码变更的测试补充。
同时，测试问题反馈，需求描述，开发进度，项目质量，测试覆盖，结合工作量，人数，上下游系统等特征来建项目质量管理模型，希望挖掘或预测项目质量洼地。
度量和验证阶段
1.测试覆盖
测试覆盖作为质量目标没有任何意义，而我们应该把它作为一种发现未被测试覆盖的代码的手段。
分析未覆盖部分的代码，从而反推在前期测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？需求/设计不够清晰，测试设计的理解有误，工程方法应用后的造成的策略性放弃等等，之后进行补充测试用例设计。
检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。
代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去，可以作为开发自我审视的重要工具之一。
2.重要指标统计
接口服务调用数、服务器监控、业务量等。
Reference：
https://www.infoq.cn/article/WHt0wFMDRrBU-dtkh1Xp
总结：
版本控制
代码静态扫描
80%以上的单元测试覆盖率
漏洞（Vulnerability）扫描
开源工具扫描
环境自动创建
集成测试
性能测试
每次提交都触发：构建、部署和自动化测试
自动化变更请求
未来的趋势
使用AI加速/优化的DevOps将开始被逐渐应用。基于AI的预测性可以被用在CI或者CD栋流水线过程中，确保交付流程的有效性。
容器化应用不在是新鲜事物了。DevOps和多云架构加速了容器相关的技术在大型企业中的使用。越来越巨大的软件开发和部署规模也进一步提高了容器生产环境集群的规模和复杂性。Kubernets的广泛使用也进一步加速了应用容器化的进程。
Functions-as-a-Service (FaaS) 将会崭露头角。随着越来越多的专业人士在生产环境中广泛的使用容器技术。相信FaaS也会逐渐被应用起来，它也比称之为无服务器计算。
DevSecOps会变得更加重要。随着企业应用DevOps的范围逐渐扩大化，将安全性和合规性无缝的集成到DevOps转型过程中也得到了广泛的接受。主流的DevOps实践者会把安全性视为代码，安全团队会在DevOps工作流中和各种团队携手打造安全性。
自动化将会依然非常重要。企业越来越意识到在软件开发周中提高响应速度、运维的可恢复性、更快的上市时间的重要性；这需要将软件开发和运维工作通过自动化更好的链接起来。组织在复杂的生态系统中扩大自动化的应用还是有些难度。