便宜VPS网目前有没有DevOps解决方案能保证整个软件包生命周期的安全？
有的，比如JFrog的DevOps解决方案，近期JFrog收购了Vdoo之后，他们的产品对于安全性更多了一层保障，能够做到保证软件生命周期的安全。
具体表现在能够使用高级算法适用性扫描进行上下文威胁分析，优先考虑跨多个向量的关键安全漏洞；能够在新漏洞、恶意软件、漏洞利用、后门、供应链风险和其他威胁公开之前自动检测；能够跨多个攻击向量的可行缓解建议切入底线，避免团队在必须筛选数千个可能的漏洞时出现“警觉疲劳”和噪音；能够将安全性扩展到设备/IoT 上的嵌入式软件，以及固件扫描和唯一识别已编译 C/C++ 应用程序组件中的漏洞；能够将发现的任何安全风险与 40 多种（迄今为止）不同的安全标准和法规相匹配等。
有没有类似teambition、JIRA免费的项目管理软件？
现在常用的项目管理工具有：CORNERSTONE、Teambition、ones、tapd、zentao
最推荐的一种：CORNERSTONE项目管理工具
推荐理由：
CORNERSTONE能够用来处理任何类型的项目协作的工具，应用于运行和维护涉及到你的业务和企业的最困难任务，即使是对最初级的用户都能有所帮助，可满足不同团队规模的需求。
1.存储在云端，或者可以自己架设，基于 B/S 架构；
CORNERSTONE有网页版，并支持mac、windows、ios、Android多端同步，并支持私有部署功能。
2.任务管理、任务可以设置优先级；
CORNERSTONE可以给每个任务设置“优先级”、“责任人”、“任务类型”、“开始/截止时间”等多种任务属性，并支持自定义配置任务属性。
3.任务可以排序，可以分配给成员，完成的任务默认不显示；
任务支持排序：CORNERSTONE的任务支持7种视图显示，可以按照我的任务、未开始任务、已完成任务等多种属性排序。
任务分配到人：上面已经说过了，任务可以设置“责任人”，如果一个任务需要多个人参与，也可以添加参与人。
完成的任务默认不显示：CORNERSTONE的项目应用，可以在【我的任务】查看自己的所有当前的任务，任务完成后可在【已完成任务】查看自己已完成的任务。
4.知识管理；
WIKI是一种在网络上开放且可供多人协同创作的超文本系统，WIKI站点可以有多人（甚至任何访问者）维护，每个人都可以发表自己的意见，或者对共同的主题进行扩展或者探讨。
CORNERSTONE的WIKI模块可以帮助成员同步记录项目信息，也可创建知识库和企业信息库，方便其他成员查看。
创建知识库/创建页面
创建知识库
点击“WIKI”进入WIKI页面；
点击\"+\"号创建知识库。
对访问权限进行设置
可创建富文本、Markdown、思维导图以及表格。
富文本
富文本格式是一种非常流行的文件结构，很多文字编辑器都支持它。一般的格式设置，比如字体和段落设置，页面设置等等信息都可以存在RTF格式中，它能在一定程度上实现word与wps文件之间的互访。
CORNERSTONE提供富文本格式，方便操作人员进行直接将Word等格式的文本内容粘贴到富文本。
点击创建富文本，可以直接进行文本编辑，插入链接、格式修改等，右侧提供页面大纲，可以对内容大纲进行概览
可直接复制Word文本内容粘贴到富文本，支持大多数格式设置，方便编辑
Markdown
Markdown是一种可以使用普通文本编辑器编写的标记语言，通过简单的标记语法，它可以使普通文本内容具有一定的格式。 1、创建Markdown
创建Markdown，工具栏提供常用的编辑格式：字体加粗、引用、有序排列等，同时可插入链接或图片；
2、发布后文档会显示创建者、创建时间、修改时间等信息。
3、可生成PDF文件
思维导图
WIKI支持思维导图的创建，可用于关键目标任务分解、梳理结构、头脑风暴等。自定义颜色区分层级，简单操作即可添加子目录，方便快捷。同时可一键生成任务/需求/测试用例/测试计划等，与项目相关联。
创建一个思维导图；
可通过放大或缩小查看全部框架或局部细节；
一键生成生成任务
点击右侧的“生成任务”进入任务创建页面；
任务创建过程与任务面板的任务创建过程一致，可对责任人、状态、优先级等进行初始设置。
任务生成成功
任务生成成功后标题会显示“已关联”
在思维导图生成的任务也会显示在任务列表里。
更新对象
修改后点击“更新对象”，思维导图会根据任务状态发生变更。
另外，WIKI针对思维导图还提供一键生产需求/缺陷/测试用例/测试计划等功能，操作流程与一键生成任务的流程相似。
最后，CORNERSTONE支持多语言版本，满足不同企业需求。
CORNERSTONE
全行业覆盖的一站式项目协作平台
阿里云 云效Devops流水线Flow自动化部署Docker项目
Dockerfile
1、新建流水线
2、选择模板
4、选择阿里云容器镜像服务仓库构建镜像
5、添加新任务选择Docker部署
6、选择主机
7、部署脚本
8、保存并运行发布
9、回滚操作
基于阿里云打造「云原生」Web应用——「懒猪行」Web应用开发实践
作者：阿里云MVP 刘远程
背景
『懒猪行』专注于境外自由行S2B业务，涉及分销、终端用户服务、供应链等多个服务环节，随着业务规模的不端增加，我们一直在 探索 Web应用开发的最佳实践，以加快Web应用的迭代效率，为B/C端用户创造更多价值。
云原生
近几年，Spring Cloud为代表的微服务架构越来越火热，吸引了大量创业公司『入坑』。微服务系统的开发与单体应用的开发相比，从团队组织、运维、开发方式等多个方面带来了颠覆式的变化。从2018年开始以Istio、SOFAMesh等为代表的Service Mesh方案逐渐走上舞台，并被称为『下一代微服务架构』。
如果把以容器技术和Service Mesh为基础的IT架构定义为云原生架构，那么Dubbo、Spring Cloud为代表的分布式架构将是促进云原生架构诞生的『中间产物』。
就在18年，云原生计算基金会（CNCF）为云原生技术重新定义：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
『云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。』
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
『这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频繁并可预测的重大变更。』
这种新颖架构方式，不仅提供了完善的软件持续交付链方案，也为我们的应用组织方式带来了巨大的想象空间，甚至在将来可能给整个软件行业带来颠覆式的革命。有一点是显而易见的：原本强耦合在一起的应用被拆分，变身成为能够实现完整子集功能的可插拔式微服务，通过有机的组织让其与其它微服务共同对外提供服务；就如同组装 汽车 的发动机和座椅等，它可以来自全球供应链不同的厂商。以云原生的设计哲学来总结，云原生应用具备微服务， 健康 报告，遥测数据，弹性声明式（非反应式）等特征。
云原生所带来的效果非常明显，但完整的实践确是很容易让人知难而退，因为单Kubernetes一项，从入门到掌握也需要花费3个月左右的时间。但幸运的是，阿里云等公有云平台已经为我们准备好了容器服务（Kubernetes版）产品，并支持通过Kubernetes进行应用的容器化管理。
所有的微服务都和 Envoy sidecar 集成在一起，被集成服务所有的出入流量都被 sidecar 所劫持，这样就为外部控制准备了所需的 Hook，然后就可以利用 Istio 控制平面为应用提供服务路由、遥测数据收集以及策略实施等功能。
懒猪行的架构设计（简化）
在新的架构中，使用了大量的阿里云产品，这鉴于我们过去的经验，阿里云产品在运维上为我们节省了不少精力。
以上架构，是我们走向『云原生』的第一步，距离成熟还有非常大的发展空间，云原生的发展也在发展的起步阶段。按架构，把所有需要持久化的数据，如：文件、图片、数据库等存储到阿里云OSS、RDS及Redis产品，而应用则运行在以K8s管理调度的容器集群中。
阿里云DevOps工具链
阿里云在云原生架构整个生命周期都提供了完善的支持：
部署到Kubernetes_部署到Kubernetes_选择部署方式_用户指南_CodePipeline-阿里云
推荐阅读：
[1] Service Mesher社区：ServiceMesher · Service Mesh|服务网格中文社区
[2] Kubernetes Handbook：序言 · Kubernetes Handbook - Kubernetes中文指南/云原生应用架构实践手册 by Jimmy Song(宋净超)
MVP招募进行中，点击「链接」
为什么DevOps的必然趋势是BizDevOps
一、人工智能的崛起
手工测试将不再是一天中的例行惯例，这一时代已经不远了。当人工智能与 DevOps 自动化相结合时，流程执行方式发生了变化。
人工智能利用日志和活动报告来预测代码执行情况。在使用人工智能的能力时，自动化验收测试、实施测试以及功能测试对于组织来说就更容易了。所以，软件发布过程变得越来越完美，越来越高效，越来越迅速，因为持续交付是有保证的。
据最近的专家预测，随着人工智能驱动的应用程序的不断增加，工作流中将会出现越来越多的 DevOps 理念。DevOps 将成为管理多个生产链模型的测试和维护的首选方案。
二、在 DevOps 中使用无服务器计算
DevOps 可以通过无服务器计算来达到新的水平。这类应用依赖于称为 BaaS（Backend as a Service，后端即服务）的第三方服务，或者依赖于在临时容器内运行的称为 FaaS（Function as a Service，函数即服务）的定制代码。
无服务器是指运行系统的公司或个人不必租用或购买运行后端代码的虚拟机。
无服务器计算的主要优势在于，它允许开发者可以自由地专注于应用程序的开发方面，而不需要考虑其他事情。无须升级现有服务器，也能快速、方便地部署。这将需要更少的时间，也不需要花费一分钱。
三、利用 DevSecOps 控制安全漏洞
大部分 DevOps 公司都在转向 DevSecOps，这是因为最近与安全漏洞相关事件增多。IT 公司将 DevSecOps 视为众多 DevOps 最佳实践之一。
将 DevSecOps 视为一种应用安全的方式，从一开始就在代码的各个方面构建了安全性。
在开发期间采取的安全措施将导致在此过程中加强合作。这样做会使该过程更加高效、更无错误、更有效。预期今后几年将有更多的人采用 DevSecOps。
通过提高自动化程度来节省时间。
快速检测错误，增强安全性，节省时间：自动化可以提供所有这些功能以及更多。这样，整个软件开发周期就不再需要手工作业。毫无疑问，工业化将在 2021 年扮演重要角色。
所以，DevOps 有六个特性，它们是：
持续优化和反馈
持续检测
持续部署和发布
持续测试
协作开发
持续的业务计划
四、基于云的原生 DevOps 的重要性日益增加
在使用云原生的 DevOps 时，要确保更好的用户体验、更好的转型和创新管理。这正是自动管理云服务的配置、监控和部署所需的技术。
使用云自动化，软件发布得更快。这样，一个光明的未来就在等待基于云的技术的到来。甲骨文认为，到 2025 年，80% 的企业工作负载都会转移到云端上。
另外，美国空军已经接受了云计算的原则，并采用敏捷的方式来开发在多种云格式下运行的应用。网格服务使用的增长
通过采用微服务，组织可以获得一些好处。开发人员使用微服务来提高可移植性，即使这并没有让 DevOps 团队的工作变得更容易。运营商需要管理大型多云和混合部署。
微服务的出现导致了服务网络的使用增加，有望降低部署的复杂性。服务网络提供了对微服务网络及其相互作用进行观察和管理的能力。这种构成提供了一个完整的服务视图。这对 SRE 和 DevOps 开发者满足端到端认证、访问控制、金丝雀部署和 A/B 测试等复杂操作需求非常有用。
你将看到采用率和产品的增长，因为它们是微服务成功运行的关键因素。服务网格是企业从单体转向微服务时必须跨越的十字路口。
【经验分享】软件测试用例管理
本文涉及到测试用例的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。
有人说：测试用例还不知道？不就是描述测试步骤吗？
这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。
测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在他设计的测试用例上。
专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。
虽然从格式上来说，基本就定型了：
关于这部分，网络上的教程只多不少，就不赘述了。
只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力 。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。
就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。
写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。
由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。
把这些结构化好的测试点文档化，就是我们所说的测试用例了。
所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。
测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。
但随着敏捷时代的兴起，有一种声音开始冲击这种认知。
早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。
如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”
对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel
但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。
事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。
如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：TestLink，或收费的独立平台: 如：TestRail
我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。
Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。
Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。
synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 TestLink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。
TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。
TestLink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。
TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。
综合考虑，虽然 TestLink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：
出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。
从官网介绍上可以看出，TM4J 还是比较现代化的：
首先我们看看利用 TM4J 如何来编写测试用例。
层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。
点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。
切换到 Test Scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。
另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page
通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。
计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。
测试计划的创建本身操作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。
还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。
测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。
通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。
在新建完测试周期名称、描述以及详情之后。
进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。
这一步操作使得测试用例具备了项目属性。
最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。
通过查找来关联已经做好的测试计划。
创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。
对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行操作。统一平台的好处便是在此了。
虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。
TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。
最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。
