十四五规划纲要中指出，要加快数字化发展、建设数字中国，以数字化转型整体驱动生产方式、生活方式和治理方式变革。新形势下，数字化建设被提到了前所未有的高度，是实现创新驱动发展的重要抓手。然而，数字化建设过程中，企业常面临业务变化快、协作流程繁、能力沉淀难等诸多问题，只有提前整体布局规划，以科学方法论和专业管理工具对数字化战略进行落地，才能更好地帮助企业实现数字化转型。

  猪齿鱼效能管理平台，由上海汉得信息技术股份有限公司（以下简称上海汉得）自主研发推出，通过提供体系化方法论和协作、测试、DevOps及容器工具，帮助企业拉通需求、设计、开发、部署、测试和运营流程，一站式提高管理效率和质量，助力团队效能更快更强更稳定，帮助企业推动数智化转型升级。

  本周四，由上海汉得和上海熙上网络科技有限公司共同推出的“企业数字化建设路径与效能提升实践分享”线上直播，将邀请猪齿鱼资深业务架构师程沛女士分享企业数字化建设整体框架设计、方法论、效能提升利器与应用实践，为企业数字化建设提供思考方向。欢迎扫码报名。

直播介绍​

直播时间： 2021年12月16日（周四） 19:30-21:00

直播地址： 腾讯会议 ID：583-107-754 或直接点击：https://meeting.tencent.com/dw/QhDhkbnicp0E

主讲人： 程沛 猪齿鱼资深业务架构师

建议参会人员： 各公司技术总监、研发主管、项目总监、实施顾问、信息中心负责人等

您将收获：

• 企业数字化建设的方法论和五大武器
• 数字化效能提升的要诀

数字化大潮正席卷全球，我们诚邀您和您的团队参加本次线上直播，共同探讨企业数字化建设与效能提升话题！

2021年11月11日，数智化效能平台猪齿鱼 Choerodon发布 V1.1版本，多项功能新增或优化，多管齐下，全面提升团队工作效能！ ​ 通过提供体系化方法论和协作、测试、DevOps及容器工具，猪齿鱼帮助企业拉通需求、设计、开发、部署、测试和运营流程，贯穿端到端全流程，助力团队效能更快更强更稳定，帮助企业一站式提高管理效率和质量，推动数智化转型升级。

本次猪齿鱼 V1.1 版本在团队协作和DevOps方面新增和优化了多项功能：

• 全新上线的工作日历，使工作日程尽在掌握，让工作安排有条不紊；
• 新增项目及组织的工时日历，便于团队和项目管理者更好地​评估和管理工作量，为提升团队效率添砖加瓦；
• 新增组织层甘特图，帮助团队建立系统思维，从而更好地​管理和优化项目过程；
• DevOps模块新增外接代码仓库，提升仓库安全性，并在部署模块新增应用中心，支持集中查看和管理容器部署与主机部署后​生成的所有应用与资源，使DevOps模块功能更强大更易用。​

猪齿鱼项目群、开发、测试等其它功能模块，也都进行了不同程度的修改和优化，欢迎大家前往试用。

免费试用链接：https://choerodon.com.cn/register-organization/#/

猪齿鱼效能平台 V1.1 主要新特性

1. 新增在线工作日历，支持Outlook、Google等本地日历订阅，快速掌握工作项安排​

猪齿鱼工作日历将个人工作项及不同项目工作项以时间维度集中在一处，在在线日历中查看工作，使团队间能够快速同步工作。工作日历更是项目工作项可视化的利器，使业务任务和项目协作变得更加透明可视化​，一目了然自己的日程安排。

图：猪齿鱼-工作日历

之前的版本中，猪齿鱼已提供相关功能，可以从待办列表、看板、故事地图或路线图等角度规划项目团队的整体计划，以及追踪项目的整体进度。本次猪齿鱼V1.1版本更进一步，能够从个人角度出发，聚焦用户个人每天各个时段需要完成的事情，其中包括参与的不同项目的工作项，以及在各个项目中“我经办的工作项”和“我参与的工作项”，帮助您及时发现有时间冲突的任务，提高工作效率。

图：猪齿鱼-查看工作日历任务

除了可以在猪齿鱼上查看工作项，您还可以将工作日历订阅到本地Outlook等日历应用中，更好地掌控工作时间。

图：猪齿鱼-可将工作日历订阅到本地Outlook

2. 工时支持日历形式展示及日志查看，工作进度一目了然​

企业管理者对项目成本投入和实际利润产出日益关注，猪齿鱼工时日历帮助企业管理者清晰准确地跟踪项目成员的工作时间，追踪员工的闲置时间及资源工作情况，管理者轻松掌握团队的工作进度，核算准确的人力成本，实现精细化管理。本次版本在原有的工时登记功能还增加了工时日志功能，帮助企业管理者查看对应工时的工作项。

图：猪齿鱼-工时日历

对于项目团队成员，为了避免忘记登记工时的情况，本次版本增加了每日工作提醒，帮助团队成员跟进个人工作项。 ​

3. 协作模块优化甘特图功能，帮助管理者多角度评估项目​

为了使甘特图更便于项目计划管理，本次版本的甘特图在原有的基础上新增了以下功能：

• 支持查看多个迭代的工作项，支持按冲刺视图查看，支持按史诗视图查看，从全局角度及多维度查看工作项进度；
• 支持自定义工作项顺序，自定义列字段，针对工作项详情增加系统字段“实际开始时间”、“实际结束时间”，便于管理者根据团队需求，自定义甘特图查看维度，快速评估工作进度；
• 在猪齿鱼的组织层也增加了甘特图功能，并且显示资源冲突，帮助管理者合理规划组织资源，提高组织团队的资源利用率。

图：猪齿鱼-甘特图

4. DevOps部分新增及优化了开发、部署、测试功能，具体如下：​

开发

• 应用服务模块新增支持创建应用服务时配置外部GitLab仓库，并且支持从GitLab-Group中批量迁移代码仓库至Choerodon平台，保障更安全更稳定的仓库访问；
• 流水线模块CD阶段新增支持容器部署与主机部署任务；

部署

• 为提升产品持续交付能力，新增应用中心功能，集中查看和管理容器部署与主机部署后​生成的所有应用与资源；
• 应用中心模块-主机应用详情，新增支持查看各种通用进程的详情；
• 新增支持快速批量部署HZERO应用；
• 新增支持在主机中部署其他类型制品；

测试

• 覆盖功能测试及API测试功能，保证产品质量，用例库支持批量删除测试用例；
• 测试计划导入用例支持按照用例优先级筛选；
• API测试任务编排新增支持添加自定义脚本；
• API测试任务新增支持多层目录分类管理；
• API测试任务任务配置全局变量中新增支持添加变量描述。

​ 更多具体的猪齿鱼V1.1 changelog，请访问：https://open.hand-china.com/document-center/doc/product/10177/10608?doc_id=168636&doc_code=134015#%E5%8D%8F%E4%BD%9C。 ​

以上就是猪齿鱼数智化效能平台V1.1版本主要功能，欢迎访问猪齿鱼官网 https://choerodon.io/zh/ 申请免费试用，或致电400 168 4263 转 81072 联系我们了解更多。 ​

关于猪齿鱼​

猪齿鱼Choerodon数智化效能平台，提供体系化方法论和协作、测试、DevOps及容器工具，帮助企业拉通需求、设计、开发、部署、测试和运营流程，一站式提高管理效率和质量。从团队协同到DevOps工具链、从平台工具到体系化方法论，猪齿鱼全面满足协同管理与工程效率需求，贯穿端到端全流程，助力团队效能更快更强更稳定，帮助企业推动数智化转型升级。

校验系统的正确性和可靠性时，仅靠用例场景无法覆盖全生产环境下的所有场景，需要一套引流工具，在系统正式上线前用线上的请求测试待上线系统，在正常请求下了解是否有报错、在数倍请求下了解系统的性能瓶颈。常用的引流工具有GoReplay、tcpcopy等。

猪齿鱼效能平台自动化测试模块流量回归测试功能，主要使用GoReplay录制产品界面中的操作产生的HTTP请求及响应用于生成流量文件，然后将其导入Choerodon平台生成用例进行管理与执行。本文通过GoReplay的介绍及GoReplay在猪齿鱼效能平台中的实践，帮助大家理解猪齿鱼流量回归测试的概念及使用。

关于GoReplay

GoReplay，原名叫gor，因为其易上手，且功能比较全所以我们使用GoReplay进行流量录制。GoReplay是在投入生产之前使用真实流量测试应用程序最简单和最安全的方式。

随着应用程序的增长，测试所需的工作量也呈指数增长。GoReplay提供了重复使用现有流量进行测试的简单想法，这使得它非常强大。可以分析和记录应用程序流量，且不影响应用，消除了将第三方组件置于关键路径中带来的风险。

GoReplay的安装​

1. 下载地址：https://github.com/buger/goreplay/releases

2. 然后在环境中输入指令：

--wget https://github.com/buger/goreplay/releases/download/v1.1.0/gor_1.1.0_x64.tar.gz

这样我们就能获取到gor_1.1.0_x64.tar.gz压缩文件，。

3. 然后对其解压输入指令:

--tar vxf gor_1.1.0_x64.tar.gz

文件解压过分我们得到了一个gor文件；我们将gor文件移动到path环境下，这样我们就可以使用gor命令进行流量录制了。

GoReplay的基本指令​

• --input-raw - 用于捕获HTTP流量，您应该指定IP地址或接口和应用程序端口。
• --input-file- 接受之前使用的文件--output-file。
• --input-tcp - 如果您决定将来自多个转发器Gor实例的流量转发给它，则由Gor聚合实例使用。

可用输出：

• --output-http - 重放HTTP流量到给定的端点，接受基础URL。

• --output-file - 记录传入的流量到文件。

• --output-tcp- 将传入数据转发给另一个Gor实例。

• --output-stdout - 用于调试，输出所有数据到stdout。

GoReplay在猪齿鱼平台的实践

1. 录制流量​

1.1 首先我们先在服务器中安装Gor_1.1.0；

1.2 然后输入命令以下命令:

sudo nohup gor --input-raw :8080 \ # 监听服务的端口（默认网关的端口为8080） -http-allow-method GET \ # 只录制GET,POST,PUT,DELETE四种方法的请求 -http-allow-method POST \ -http-allow-method PUT \ -http-allow-method DELETE \ -input-raw-track-response \ # 捕获响应报文 -input-raw-timestamp-type PCAP_TSTAMP_HOST \ # 指定时间戳格式 -input-raw-buffer-size 32mb \ # 控制用于持有TCP包的系统缓存大小 -prettify-http \ # 自动解码 Content-Encoding:gzip 和 Transfer-Encoding:chunked的请求和响应 -output-file-append \ # 追加到文件，使得最终只生成一个.gor文件 -output-file requests.gor & # 指定结果文件名称

这些命令的含义是监听服务的端口并开始录制指定的请求类型的请求，例如这里录制的请求类型是：GET,PSOT,PUT和DELETE。捕获响应报文并把这些请求追加到文件，像这里生成的文件名叫“requests.gor”。

1.3 在命令执行后，输出如下：

这里显示的【1】19436是gor程序的进程PID，在我们录制完成后可以利用此PID进行终止gor。

1.4 这时gor已经开始进行流量录制了，此时测试人员可以开始在被测系统进行测试，此段时间的测试发出的请求会被录制。

测试人员在正式录制相关的功能之前，建议刷新页面以请求 self 接口获取当前用户信息，这个接口的响应便于之后导入流量文件时解析用例，如果既没有录制到 self 接口，也没有在导入时提供用户信息获取接口，则在无法解析请求所属用户的情况下，请求生成的用例会被忽略。

1.5 在录制一段时间的流量后，我们执行以下命令终止gor的录制输入一下命令：

sudo kill -15 ${gor进程PID}

像我们这里的输入sudo kill -15 ${19436}命令就可以终止gor进程。

1.6 此时,可以看到执行录制指令的目录下，得到一份文件名为 requests.gor 的流量文件。到此，录制完毕。

2.导入流量文件​

2.1 我们进入猪齿鱼流量回归测试页面：

2.2 点击流量回归测试右上方的导入流量文件，进入流量导入界面：

2.3选择选择用于放置生成用例的目录，我们这里选择的是测试合集目录，点击上传按钮，上传我们刚才录制的requests.gor文件，确定上传文件后，下方会立刻生成一条文件的导入记录。

如果导入用例为0条，可能有以下原因：

①录制期间，被测系统未关闭主键加密功能；

②录制期间，未请求 self 接口获取用户信息，且导入时未提供用户信息获取接口；

③提供用户信息获取接口，但是录制的流量文件时间过长，超过了用户的 Token 过期时间，导致流量文件中涉及到的请求的认证信息已经过期了，无法识别用户，所以无法生成用例；

④所有的请求都不是 json 类型的请求

⑤所有的请求的方法都不是 GET、POST、PUT或DELETE

2.4 待文件导入成功后，所选的目录下将会生成对应的用例。列表中会展示各个用例对应的路径、请求方式、菜单、用户以及请求时间。

• 路径：即用例中请求的路径。
• 请求方式：即用例中请求的请求方式。
• 菜单：即用例中对应请求所属的菜单。
• 用户：即在录制过程中，执行此次请求的用户名。
• 请求时间：即录制过程中，该请求对应的执行时间。

3.用例批量处理​

3.1 由于我们通过导入流量文件得到的用例内，各个请求使用的ID参数在之后的执行过程中会产生变化。因此我们需要通过用例批量处理的功能将用例内各个请求路径、请求参数、请求体中的ID参数替换为变量。

在此之前，我们还需要选择一个POST类型的请求，将其响应体中生成的ID作为变量提取出来，以供后续的用例进行引用。

首先在页面左侧的树结构内选中一个流量回归集合，而后点击顶部的用例批量处理按钮，右侧会出现批量处理的页面。

3.2使用搜索栏进行用例筛选，支持的搜索方式有：

• 输入搜索条件查询：可搜索任意内容，下方的列表中将会显示出路径、请求与响应中含有搜索值的对应用例。
• 快速筛选：预置的快速筛选为含数值用例，可直接搜索出路径、请求与响应中含有数值的所有用例，用于帮助进一步缩小ID查询范围。同时，保存的自定义筛选条件也将存放到快速筛选的下拉框中。
• 请求方式筛选：允许筛出GET、POST、PUT与DELETE类型的用例请求。
• 用例状态筛选：支持筛选出处理完成或未处理状态的用例请求。
• 正则筛选：支持使用正则表达式来筛选出满足条件的用例请求。
• 目录筛选：支持筛选出各个目录下的用例请求。
• 菜单筛选：支持筛选出对应菜单下的用例请求。
• 具体字段：用于指定搜索值的定位生效区域。支持定位到：路径、请求头、请求参数、请求体、响应头与响应体。

3.3提取页面中的变量，在此界面中，需要将生成ID的用例请求找到，并将其响应体中的ID参数作为变量提取出来。具体步骤如下：

​ 1.通过搜索栏中的各个选项定位到目标用例。

此处的一般步骤为： - 在快速筛选的搜索栏中选择含数值用例，先筛出所有含有数值的用例。 - 在具体字段中，选择为：POST，以筛出目标用例。 - 选择想要处理的功能块所在的菜单，或在搜索条件中输入相关内容，来进一步缩小搜索的范围。 - 最后，在筛出的用例请求中逐一找出目标用例。

​ 2.勾选出一个目标用例，点击下方的添加变量提取的按钮，右侧会弹出变量提取的界面。

1. 选择提取的来源：一般为响应体JSON，此处需根据提取的目标变量的位置与格式而定；支持选择响应体JSON、响应体XML、响应体文本与响应头。

2. 输入变量名称：此处输入的变量名称，会作为后续用例引用的变量。

3. 选择器：需通过选择器定位到提取的变量所在的位置。

变量提取成功后，还需要对请求中使用了ID参数的用例进行批量的ID替换，将其替换为提取出的变量。 使用此功能，可以批量地将可以配置的参数提取为变量，例如提取请求中常见的项目ID、租户ID或者其它的资源ID。

• 值替换功能：

  • 选择替换区域：支持选择路径、请求参数、请求头、请求体、响应头、响应体；用于定位所有选中的用例需要进行替换的具体区域。

  • 输入源值：即之前的ID参数的准确值。后续会将这个ID数值替换为已经提取出的变量。

  • 输入替换值：在此输入需要引用的变量即可。

    例：之前提取出的变量名称为id，此处就输入：${id}

• 用例状态替换：直接在下拉框中选择需要将所选的用例请求变为的目标状态；对于已经处理完成的用例请求，直接批量将其置为处理完成的状态即可。回到列表之后，这些用例的状态就变为了处理完成。

总结

猪齿鱼全场景效能平台流量回归测试通过GoReplay批量录制产品界面操作，并将得到的用例进行集中管理，便于后续进行批量的回归测试，从很大程度上减轻了测试人员编写脚本、收集测试数据等重复且耗时的工作，提升团队的测试效能。

参考资料

• https://www.cnblogs.com/sunsky303/p/9072871.html

• https://blog.csdn.net/xqtesting/article/details/109722583

欢迎免费试用SaaS企业版

试用链接：https://choerodon.com.cn/register-organization/#/

关于Choerodon猪齿鱼

Choerodon猪齿鱼是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更多内容​

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：https://openforum.hand-china.com/
• 操作指引：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124615&doc_code=119767
• 用户手册：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124273&doc_code=118818

Choerodon猪齿鱼官方社区用户交流群，此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得，群同步更新版本更新等信息，大家可以加群讨论交流。

请添加Choerodon猪齿鱼小助手微信：hand-c7n

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

Atlassian 宣布将在2024年2月2日完全停止销售支持服务器产品线，全面发展云端业务，终止销售的产品有：Jira Software Server、Jira Core Server、Jira Service Desk Service等，这意味着 Jira 服务器产品将不再为使用者提供支持和错误的修复。对于中国的 Jira 服务器使用者来说，如果选择上云，服务器在国外，将面临访问速度变慢及数据安全的风险。 ​

最终的选择只有两种：

• 提早续订Server版本，继续使用至2024年，但会面临无支持的状态；
• 提前选择替换工具。

Choerodon猪齿鱼 与 JIRA​

Choerodon猪齿鱼 与 Jira 在很多方面很相似，都可以作为项目与事务跟踪的工具，广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域，同样适用于中小型团队和大型企业。 Jira 主要采用Scrum或看板模型进行项目管理，Choerodon猪齿鱼不仅包含Scrum、Kanban的敏捷框架，还覆盖故事地图、SAFe等敏捷框架进行敏捷协作管理，并支持持续交付、容器环境、微服务、DevOps、知识库、多组织等能力来帮助研发组织完成软件端到端的生命周期管理。

除了完整的研发管理闭环，Choerodon猪齿鱼还提供敏捷协作、DevOps全链路、自动化测试三款适用于项目管理、开发管理、测试管理的解决方案，提供可插拔的方式，满足不同研发团队的项目管理需求。

• 敏捷协作：深度贯彻敏捷研发理念，提供对需求管理、敏捷迭代、知识库各个维度的协同管理，促进团队成员沟通交流，降低项目管理成本，提高沟通协作效率。 ​
• DevOps全链路：结合Gitlab、SonarQube进行代码管理，提供自动化可编排的持续交付流水线，规范开发流程，并借助可视化、自动化的部署流水线实现多环境的容器化部署，打通持续集成与持续部署，并通过集成Kubernetes实现对环境资源的统一管理与监控，提高团队持续交付效率。 ​
• 自动化测试：贯穿项目管理、敏捷开发等DevOps全流程，提供敏捷化的持续测试工具，包括功能测试、API测试、性能测试、流量重放、UI测试，提高团队测试效率，保证质量。

对比分析​

团队管理​

项目管理​

规模化敏捷​

自动化测试​

DevOps管理​

部署方式及客户服务​

总结​

Jira 作为最早进入中国市场的项目管理工具，确实为加速项目效率提供了卓越贡献，目前国内的效能软件层出不穷，选择更适合企业的软件是管理者们最关注的事情。从对比分析我们可以看出 Choerodon猪齿鱼完整的端到端全链路管理，不仅覆盖了Jira 的事务与项目跟踪功能，还从组织框架、自动化测试等方面扩展多团队和多场景的项目管理。 虽然Jira 也可以通过第三方插件来扩展功能，但除了较高的额外费用外，还需要对工具进行学习和维护。

关于Choerodon猪齿鱼​

Choerodon猪齿鱼是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。 ​

更多内容​

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献： ​

• 官网：http://choerodon.io
• 论坛：https://openforum.hand-china.com/
• 操作指引：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124615&doc_code=119767
• 用户手册：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124273&doc_code=118818

Choerodon猪齿鱼官方社区用户交流群，此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得，群同步更新版本更新等信息，大家可以加群讨论交流。 ​

请添加Choerodon猪齿鱼小助手微信：hand-c7n

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。 ​

​

​

​

​

​

​

​

​

​

数字化转型的路上，难免有很多磕磕绊绊：

业务变化快，需求响应慢？

协作流程繁，质量难把控？

能力沉淀难，反复造轮子？

容器云微服务架构融合难 ？

.......

Choerodon 猪齿鱼来帮你~

猪齿鱼 SaaS 版发布

Choerodon猪齿鱼企业级全场景云原生能效平台，致力于提高企业研发效能，拉通需求-设计-开发-部署-测试-运营流程，提供一体化的企业研发管理解决方案，帮助企业落地敏捷和DevOps，助力企业数字化。猪齿鱼SaaS版已于近日正式上线！想体验猪齿鱼的您，可以正式向部署烦恼 say goodbye 啦~

主要功能如下：

查 看 解 决 方 案 和 试 用： https://choerodon.com.cn/register-organization/#/

协作​

基于敏捷SCRUM和大规模敏捷SAFe理念，结合汉得20多年项目管理实践，建立了高效协同的项目/研发管理模式，支持团队的异地协同及项目间协同。

通过史诗、特性、故事、任务的多层结构，有效管理团队计划；通过冲刺管理每一阶段的任务，让工作更聚焦；通过看板可视化团队任务，让工作更透明；通过甘特图、协作图表、绩效、项目报告等图表方式，辅助团队更直观、便捷地及时获取项目情况，并进行风险预判。通过任务的聚焦与透明，促进团队成员紧密协作，提高沟通效率、降低管理成本。

目前平台有8000+个项目正在使用协作模块进行项目管理，大大提高了内部研发团队、外部交付团队及营销团队的工作效率。

需求​

贯穿着产品的整个生命周期，包括项目内部及外部用户的需求收集、需求审核、分析、拆解及开发进度的跟进。

需求管理配合工作流，配置审核节点及流程，即可应用于工单管理；不仅仅是工单和需求，在产品迭代过程中的bug，也可通过需求收集渠道进行统一管理分类。目前汉得中台研发20多条自研产品线均通过需求管理功能收集产品需求和bug，保证产品与市场需求并进。

项目群大规模敏捷​

大规模敏捷SAFe为多团队协作的场景提供了跨团队高效协同的解决方案，通过猪齿鱼项目群对多团队业务需求整理、产品开发路线图、产品间依赖关系、并行开发等进行统筹管理，帮助多团队间提高协作性，降低团队间的管理复杂性。

目前汉得平台产品研发中心有30+团队，以大规模敏捷项目群方式进行管理，有效支持了多条产品线每月稳定发布产品新版本。

开发​

结合Gitlab、代码管理，提供自动化可编排的持续交付流水线，规范开发流程，缩短应用服务开发周期，同时提高团队效率，高效持续地向测试团队或者用户交付软件新版本。

目前平均每天的流水线触发量为1700-2000条，平台稳定地支持各团队的产品发布，并且能够保证团队流水线的高效执行。

部署​

借助可视化、自动化的部署流水线实现多环境的容器化部署，打通持续集成与持续部署，并通过集成Kubernetes实现对环境资源的统一管理与监控。

目前已部署4000+应用实例，每天部署平台中部署时长稳定在30S左右完成应用实例部署，保证产品可以随时部署。

测试​

贯穿项目管理、敏捷开发等DevOps全流程，提供敏捷化的持续测试工具，包括测试用例管理、测试计划、API测试、性能测试、流量回归测试、UI测试、测试分析等，提高团队测试效率，保证软件质量。

猪齿鱼产品作为猪齿鱼SaaS平台的用户之一，产品的自动化测试用例已超过5000个，覆盖率超过90%；猪齿鱼600+个功能点已覆盖了性能测试，以保障产品的稳定与可靠。

容器云​

Choerodon猪齿鱼全面融合各个容器云的集群，可以把各类容器云集群统一托管，帮助组织团队进行稳定部署。目前平台中管理着100+个运行中的集群，以及800+个环境，帮助用户在平台中统一调配资源和管理环境。

文档​

支持线上知识库，团队成员可协同编辑知识、分享知识、沉淀知识，同时，知识可以与任务直接绑定，方便工作过程中直接定位、快速查阅。此外，也支持通过平台进行SVN文档库的快速配置，满足SVN用户的使用习惯需求。

如何获取Choerodon猪齿鱼SaaS版本

Choerodon猪齿鱼SaaS现已上架至汉得开放平台,您可以选择最适合您的企业服务方案。

更多服务支持内容欢迎致电咨询：400-168-4263

欢迎免费试用SaaS企业版

试用链接：https://choerodon.com.cn/register-organization/#/

关于Choerodon猪齿鱼

Choerodon猪齿鱼是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更多内容​

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：https://openforum.hand-china.com/
• 操作指引：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124615&doc_code=119767
• 用户手册：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124273&doc_code=118818

Choerodon猪齿鱼官方社区用户交流群，此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得，群同步更新版本更新等信息，大家可以加群讨论交流。

请添加Choerodon猪齿鱼小助手微信：hand-c7n

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

看板的核心是将状态可视化，一张看板承载着所有卡片，一张卡片代表一个任务，同时看板会被分成几列，每一列代表一个任务可以处于的状态。

在研发项目中，各团队常常用看板管理任务的生命周期，并且不同团队的看板任务流转都是不同的。通过实践，我们收集到不同团队对看板管理的需求

• 项目经理期望知晓团队的整体工作情况，期望可以定制一套符合团队的任务流程；
• 开发团队注重每个人的任务进度及开发量，同步管理代码质量；
• 测试团队针对测试的功能提交缺陷后，缺陷的修复情况如何；
• 产品团队梳理完需求，需求各阶段的状态得到反馈；

针对各团队的需求，Choerodon猪齿鱼的看板管理引入「状态机」功能，用来制定不同的任务流转的工作流程，跟看板中的列对应，针对看板中的每种状态也定义了对应的工作流及处理问题时执行的特定操作。帮助大家专注研发流程，提升研发效率。 ​

🙌Choerodon猪齿鱼「状态机」使用场景​

下图为研发项目的通用研发流程，其中包括项目中需求各阶段的流转历程，以及对代码开发的整个周期管理。

需求管理是研发项目活动中的一个重要过程，可以说需求是产品开发的开端，贯穿着整个产品的生命周期，从一开始的需求收集、到需求设计、开发、测试、最终上线，无论哪个环节都是依赖着需求进行的。 当需求评审通过后，项目进入到开发侧。这时，开发团队需要制定明确的迭代计划，包括product backlog（产品待办，也就是评审通过的需求）的优先级、迭代目的等，随后进入到开发阶段。 开发人员确定任务后，创建对应的开发分支，开发完成后，开发人员本地自测，再合入开发环境测试主分支，安排测试人员进行开发环境测试。最后通过验收测试后，系统发布上线。

定制任务流程​

以这套流程为例，在Choerodon猪齿鱼中如何使用状态机进行任务流程配置呢？ ​

配置看板中的状态与流转​

Choerodon猪齿鱼看板管理契合项目从需求管理到开发、测试、上线的全流程配置。根据示例中的研发项目的整个流程体系，我们首先需要确认看板中有以下信息： 明确迭代的三个阶段： 设计、开发、测试 三个阶段分别对应以下状态节点： 设计： 功能设计、技术设计、设计评审、设计完成； 开发： 待开发、开发中、本地自测、开发完成； 测试： 待测试、staging测试、验收测试、已完成；

不同阶段专注的内容可以汇集到不同的看板。如下，我们可以建立设计看板、开发看板、测试看板。 设计看板与开发看板的连接依靠：设计阶段的设计完成=开发阶段的待开发； 开发看板到测试看板的连接依靠：开发阶段的完成态就是测试阶段的初始态。

当然，如果需要全局维度的查看看板，我们也可以建立全局看板。

根据制定好的看板、列和状态以及场景，配置状态的流转方向可以控制看板中卡片的流转。 以<故事>这个issue类型为例，流转流程如下：

状态的流转状态配置好后，在看板中拖动任务时，任务会根据流程流转。

​

配置​问题类型​

此外，项目上往往存在多个不同类型的需求，对不同的需求有不同的处理流程。例如：

不同的需求同样需要不同的issue类型来梳理，Choerodon猪齿鱼通过不同类型issue的流程管理能力，以帮助项目实现多样化，多情景的流程管理能力。详细配置信息，请参考用户手册「问题类型配置」。

「issue与分支联动」​

开发团队进入到开发阶段后，产生了一条代码分支的生命历程。即：确定任务后，创建对应的开发分支，开发完成后，开发人员本地自测，再合入开发环境测试主分支，安排测试人员进行开发环境测试。从这个流程提炼出了以下和issue相关的联动：

1. 开发人员本地开发分支feature合并入测试环境测试主分支master后，开发完成；
2. 开发完成通知测试人员测试；

例如：根据上诉需求配置如下

Choerodon猪齿鱼支持issue和开发分支联动起来，为团队的DevOps实践提供更好的支持。

「用户故事与开发子任务自动流转联动」​

项目迭代过程中，开发人员专注于所负责的子任务的开发，忽略的用户故事维度的管理和流转，会造成子任务已经完成，但是用户故事依旧在某个状态积压，不能及时进入测试流程。这将会导致这些用户故事没有得到充分的测试，最终会影响到产品的交付质量。Choerodon猪齿鱼的状态机功能支持父子任务进行状态联动，无需人工维护。 例如：开发子任务全部开发完成后，用户故事自动流转到开发完成状态。

「钉钉、企业微信等第三方应用Webhook推送」​

为了方便项目成员能够及时收到任务处理的通知，除邮件、站内信外，Choerodon猪齿鱼支持钉钉、企业微信等其他平台的Webhook消息推送。项目负责人可以在需要及时收到通知的状态节点启用Webhook通知，实时接收任务状态流转的消息推送。 例如：设置向【报告人、经办人】发【邮件、站内信】通知，启动Webhook通知。

了解如何添加Webhook，请参考用户手册「Webhook配置」

「不只是研发项目」​

当然，除了研发类的项目之外，在销售项目、人力资源、市场营销、运营等项目也会有与当前情景匹配的任务管理流程。这里我们拿一个销售管理项目举个栗子🌰： 不同的销售业务对应不同的销售流程，销售总监根据团队需要来规定销售流程。常见的这销售流程如下：

• 潜在商机--> 联系--> 商业接洽-->打单--> 签署合同；

状态机配置如下图：

看板管理如下图：

贯穿着产品的整个生命周期，包括项目内部及外部用户的需求收集、需求审核、分析、拆解及开发进度的跟进。

🤗Choerodon猪齿鱼「状态机」如何使用​

更详细的操作教程，请参考用户手册：

☞如何配置问题类型

☞如何配置状态机

☞如何配置看板

☞如何配置Webhook

欢迎免费试用SaaS企业版

试用链接：https://choerodon.com.cn/register-organization/#/

关于Choerodon猪齿鱼

Choerodon猪齿鱼是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更多内容​

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：https://openforum.hand-china.com/
• 操作指引：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124615&doc_code=119767
• 用户手册：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124273&doc_code=118818

Choerodon猪齿鱼官方社区用户交流群，此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得，群同步更新版本更新等信息，大家可以加群讨论交流。

请添加Choerodon猪齿鱼小助手微信：hand-c7n

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

自汉得宣布发布猪齿鱼以来，已被上千个组织所使用，帮助企业完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。经过一千一百多天的奋战，2021年06月30日，Choerodon猪齿鱼迎来了1.0先行版正式发布，标志着Choerodon猪齿鱼走向的成熟和稳定，欢迎各位升级体验。

• 发布版本：1.0
• 发布时间：2021年06月30日
• 更新范围：全局
• 版本范围：商业版

本文主要内容包括：

• 1.0版本的重大调整

• Choerodon1.0商业版更新说明

1.0版本的重大调整

使用开源组件库Choerodon UI 1.4.0 新主题-风铃紫​

Choerodon UI**开源组件库**（缩写 C7N UI），拥有开箱即用的高质量 React 组件，全链路开发和设计工具体系，帮助企业级中后台产品提升开发效率。自V 0.1.0就开始支撑Choerodon猪齿鱼的前端组件，并在2021年2月4日发布稳定开发正式版 V 1.0，支持平滑升级，目前除了Choerodon猪齿鱼还支撑着HZERO、飞搭等产品的前端组件。

C7N UI信息如下：

官网：https://open-hand.github.io/choerodon-ui/zh GitHub：https://github.com/open-hand/choerodon-ui Gitee：https://gitee.com/open-hand/choerodon-ui

Choerodon猪齿鱼1.0版本全面使用C7N UI 最新版本1.4.0的新主题风铃紫。

Choerodon官网迁移至汉得焱牛开放平台​

汉得焱牛开放平台致力于降低技术中台交付成本和准入门槛，为内外部用户提供更高效、更便捷的一站式服务平台。

Choerodon主页介绍了产品优势、产品功能、解决方案、客户案例等信息，并对比了Choerodon猪齿鱼不同版本的功能差异。

Choerodon主页：https://open.hand-china.com/open-source/choerodon

汉得焱牛开放平台-文档中心集成了汉得自主研发产品的相关文档，致力于打造成汉得的“百科全书”，更集中、更便捷、更统一的满足用户的阅读和查询。

Choerodon文档将商业版、SaaS版的文档迁移至文档中心，提供多样化的服务支持。

Choerodon文档：https://open.hand-china.com/document-center/doc/product/10003/10274?doc_id=39943&doc_code=1723

Choerodon猪齿鱼1.0更新说明

敏捷协作​

新增功能​

• 增加输入提示；
• 子任务支持问题类型转换；

• 增加每人每日工作量图表；
• 增加个人工作量统计；
• 所有问题支持自定义列表字段显示、顺序以及列宽度；
• 新增复制问题时支持字段可选复制；
• 新增快速创建问题时支持选择经办人；

• 项目报告增加一键折叠；
• 问题详情新增支持快速创建缺陷；
• 模块列表增加顺序；
• 问题详情新增显示测试进度；
• 新增问题详情支持复制问题链接；
• 兼容Safari浏览器；
• 新增切换问题类型输入必填字段；

功能优化​

• 配置看板时支持切换看板；
• 优化问题详情关联问题；
• 优化移动问题卡慢的问题；
• 优化评论问题默认倒序显示；
• 快速创建必填项提示优化；
• 优化快速创建子任务后自动打开详情；
• 优化问题详情更多按钮顺序；
• 优化问题评论发送消息；
• 优化状态机页面；
• 优化时间显示格式；
• 优化自定义问题类型值集过多时加载缓慢；
• 优化问题详情附件展示形式；

缺陷修复​

• 修复UI/UX文件上传后无法预览的问题；
• 修复甘特图左右移动时间周期边长的问题；
• 修复状态自定义排序偶发乱序的问题；

知识管理​

功能优化​

• 优化创建文档可以选择创建到根目录；

缺陷修复​

• 修复知识库文档多层级创建时，目录无法左右滚动；
• 修复知识库全屏切换/退出丢失编辑内容；

代码开发​

新增功能​

• 代码管理-分支管理中，新增分支合并触发关联问题状态变更；
• 代码管理-分支管理中，支持开发人员在此关联同组织下其他项目的敏捷问题；
• 代码管理-分支管理页面新增1个分支支持添加多个敏捷问题的功能；
• 代码库管理-权限审批模块，新增批量审批的功能；
• CI流程中Docker构建步骤中新增镜像安全扫描卡点的功能，支持为镜像扫描添加门禁限制；

环境部署​

缺陷修复​

• 修复了部署记录页面中，偶现丢失批量部署的记录的问题；
• 修复了CD阶段的任务精确匹配/排除选择的触发分支显示错误的问题；
• 修复了主机部署的错误信息和任务失败信息未展示的问题；

测试管理​

新增功能​

• 新增测试执行状态变更触发问题状态变更；
• 测试执行支持定位所属文件夹；
• 测试执行执行按文件夹批量分配计划执行人；
• 计划新增关联版本、冲刺；

功能优化​

• 优化测试计划进度展示；
• 创建用例时支持输入自定义编号；
• 优化用例自定义编号规则；

基础功能​

菜单界面调整​

• 将项目汇总在顶部，方便查看；

• 将协作拆分为协作、文档两部分，并对页面菜单层级做了调整；

• 将设置中的菜单做了层级调整；

新增功能​

• 站内信模块新增支持以左侧弹框的形式展示；

功能优化​

• 自定义角色中，将部署-资源菜单下的功能权限细化；

缺陷修复​

• 修复了项目成员分页查询部署配置报错的问题；
• 修复了oauth重置密码长度校验异常的问题；
• 修复了同步ldap定时任务时，偶现停用的问题；

安装或升级​

安装文档：https://open.hand-china.com/publish-center/product/product-detail/10003/version/10426/document?docVersion=1.0&doc_id=125697&doc_code=1734

升级文档：https://open.hand-china.com/publish-center/product/product-detail/10003/version/10426/document?docVersion=1.0&doc_id=126701&doc_code=121227

敏捷协作-发布版本​

• 新增发布版本功能，管理版本实际发布内容；

需求管理​

贯穿着产品的整个生命周期，包括项目内部及外部用户的需求收集、需求审核、分析、拆解及开发进度的跟进。

新增功能​

• 需求审核增加创建需求；
• 需求审核支持导出需求；
• 导出需求增加描述字段；
• 需求池支持自定义列表字段显示、顺序以及列宽度；
• 需求池支持导入需求；

缺陷修复​

• 修复项目成员不能星标需求的问题；

规模化敏捷​

以企业级的大规模敏捷框架SAFe为基础，对多项目并行开发、多团队业务需求整理及产品开发路线图等进行管理，帮助团队提高协作性，降低团队管理的复杂性。

新增功能​

• 版本关联新增与devops联动；
• 路线图支持自定义列表字段显示、顺序以及列宽度；

功能优化​

• 优化PI目标关联特性可选择是否隐藏已关联特性；

缺陷修复​

• 修复迭代日历时间范围不能选择1年的问题；
• 修复ART设置跳转到子项目报错的问题；

自动化测试​

包括接口测试、性能测试、流量回归测试、UI测试，贯穿项目管理、敏捷开发DevOps全流程，提供敏捷化的持续测试工具，提高团队测试效率，保证质量。

新增功能​

• 性能测试-执行性能测试，新增支持为每次执行添加执行备注；
• 性能测试-执行性能测试，新增支持为每次性能测试执行设置持续时长；
• 性能测试-执行性能测试，新增支持永远循环执行选中的测试任务；
• 性能测试模块新增支持手动停止正在执行中的性能测试；

功能优化​

• API测试任务开启定时设置后，加上【定时】的标签；树结构中也加上筛选；

缺陷修复​

• 修复了用例库-创建/修改API测试用例时，点击【保存并执行】，跳转至记录界面后，弹框未收起的问题；

质量管理​

通过报表以图形化的方式直观的展示项目下应用代码质量数据，便于直观展示当前项目的总体代码质量及每个应用的代码质量，以供团队管理参考。

新增功能​

• 单表预览脚本；
• 表设计字段新增unsigned、time、blob、longblob类型支持；
• 表设计添加数据库类型、字段类型大小写、团队邮箱配置；
• 表模块可变更、模块编码可修改、可迁移模块表到其它模块；
• 期初数据导入添加操作选项，支持新建、更新、删除、重置选项；
• 新增自动提交、升级表设计功能；
• 添加PostgreSQL数据库支持；
• 克隆表结构；
• 表设计，表结构字段顺序可修改、可插入字段；
• 批量提交表；

功能优化​

• 表结构页面，备注字段宽度调整优化；
• 生成DDD模型代码，过时注解替换；
• 发布操作改为提交；
• 字段默认值添加EMPTY_STRING（空字符串）支持；
• 不同模块可支持同名表；
• 索引列可在索引列表展示；
• 关联关系区分版本；
• 弹性域字段创建可定制化；

应用市场​

Choerodon应用市场是平台内应用服务组件与常用中间件的管理中心，支持平台下所有项目直接部署便可使用。

新增功能​

• 应用市场中，默认预置MySQL的配置与信息；
• 基础组件部署中，支持部署人员对MySQL进行主机部署与容器部署；

社区参与

感谢以下朋友在社区论坛中提出反馈和意见，在1.0版本更新中作出贡献，感谢大家一直以来的支持。

更加详细的内容，请参阅Release Notes和官网用户手册。

欢迎各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与贡献，帮助Choerodon猪齿鱼不断成长。Choerodon会持续优化，敬请期待。

-▼-

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：https://open.hand-china.com/open-source/choerodon
• 论坛：https://openforum.hand-china.com/
• Github：https://github.com/open-hand/choerodon

Choerodon猪齿鱼官方社区用户交流群，此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得，群同步更新版本更新等信息，大家可以加群讨论交流。

①-Choerodon猪齿鱼官方交流（已满）；

②-Choerodon猪齿鱼官方交流（可加）；扫描下面二维码添加【Choerodon猪齿鱼小助手】，请备注加群；

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

JMeter简介​

JMeter 的特性：

• 对于多种协议的功能测试和性能测试
  • Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
  • SOAP / REST Webservices
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail - SMTP(S), POP3(S) and IMAP(S)
  • Native commands or shell scripts
  • TCP
  • Java Objects
• 提供了测试录制
• 提供 CLI 模式
• 提供 HTML 报告
• 完全的可移植性和百分百的纯 Java
• 提供多线程支持，模拟多用户
• 高扩展性

  这一节内容译自 JMeter 首页： https://jmeter.apache.org/index.html

笔者实验环境​

JMeter是Java语言的实现，也就是纯Java应用，所以JMeter理论上可以运行于任何对应的Java环境可用的环境上。 | 类型 | 值 | | :--------- | :------------------------------------------- | | Java版本 | java version "1.8.0_181" （要求Java8及以上） | | JMeter版本 | 5.4.1 | | 操作系统 | Ubuntu 20.04（GNOME 3.36.5） | | 内核版本 | Linux version 5.8.0-43-generic |

下载​

本文主要介绍 JMeter 的快速入门，故其它环境由读者自行准备

1. 进入官网页面（https://jmeter.apache.org/download_jmeter.cgi）选择合适的镜像源，下载二进制分发文件；
2. 将压缩文件解压到本地后，JMeter 解压后得到的目录的路径称为 JMETER_HOME； ##JMeter文件简单介绍

启动JMeter的用户界面​

进入 JMETER_HOME 目录下的 bin 目录，执行以下命令启动 JMeter 的 GUI 模式：

./jmeter

几秒后，界面打开如下：

JMeter主要概念简介​

JMeter主要功能元素简介（Http测试相关）​

JMeter 界面操作大部分是单击鼠标右键会弹出下拉菜单进行元素的添加

线程组

右键测试计划添加

组件截图：

组件参数说明：

HTTP请求默认值

鼠标右键单击线程组元素，从配置元件(config element)下拉项中添加

这个组件用于为作用范围内的HTTP采样器提供默认值。

组件参数说明：

用户定义的变量​

鼠标右键单击线程组元素，从配置元件中选择添加

这个组件用于在线程中定义变量，可以在其它地方使用 ${variableName} 的语法进行引用。

在下列界面点击 添加 按钮添加一行变量名和值即可定义一个变量。

HTTP采样器​

鼠标右键单击线程组元素，从采样器条目中选择

HTTP采样器可以使用 HTTP 请求的形式对被测系统进行采样（发起请求）。这个组件中很多数据和上文提到的 HTTP请求默认值 组件中的很多属性相同，如果此采样器在 HTTP请求默认值 组件作用范围内，则采样器中为空的属性会填入默认值，不为空的属性会覆盖 HTTP请求默认值 组件中相同的属性（就近）。

组件参数说明：

响应断言​

鼠标右键单击采样器，点击【添加-断言-响应断言】选项添加

响应断言可以为采样器所得的结果进行断言，以逻辑（等于、包含、正则匹配等）对包括响应头、响应码、响应体等在内的内容进行断言，以校验采样器的输出是否符合测试者的预期。

组件参数说明：

JSON变量提取​

右键单击请求，Add -- Post Processors -- Json Extractor 添加 JSON 提取器元素

JSON 提取器可以用于从响应体中的 JSON 结构中提取指定位置的属性为变量。

组件参数说明：

JSON path 写法： $ 符号表示根元素，. 表示取属性，[0] 表示取数组对象的第一个元素 （ [1]就是第二个）。

例如：

{
    "user": {
        "names": ["Jack", "Jacky"],
        "age": 10
    }
}

对于以上 JSON ，使用表达式 $.user.names[0] 即可提取出 Jack 这个值。 更详细的信息可以参考: https://jsonpath.com/

查看结果树元素

这个元素是用于使用 JMeter 界面进行请求执行时查看请求的执行情况的，他可以查看到请求的请求报文和响应报文以及断言情况等信息。详情参考下文。

JMeter使用示例​

接下来，我们使用上面学到的知识，实现这么一个场景：查询 Gitee 上猪齿鱼仓库下的贡献者， 然后提取出指定的一个贡献者名称，用第二个请求获取贡献者的信息。

使用的 Gitee 的两个接口为

• GET https://gitee.com/open-hand/choerodon/contributors_count?ref=0.23.0

响应体结构为（我们需要获取的贡献者名称的 JSON path 为 $.contributors[0].username）：

{
    "status": 1,
    "contributors_count": "16",
    "contributors": [
        {
            "username": "example1"
        }
    ]
}

• GET https://gitee.com/{贡献者名称}

创建测试计划​

打开 Jmeter 会有个默认的测试计划

创建线程组​

右键鼠标单击测试计划，点击 Add > Threads (Users) > Thread Group 添加线程组元素。其中填入以下值：

创建 HTTP 默认值配置元素​

鼠标右键单击线程组，Add > Config Element > Http Request Defaults 添加配置元素。填入值如下：

创建 HTTP 采样器获取贡献者列表​

右键单击线程组，Add > Sampler > HTTP Request 添加采样器（填入path和添加一个parameter）：

添加响应提取器​

右键单击请求采样器，Add > Post Processors > JSON extractor 添加元素如下，因为某些用户在 gitee 并不存在，这里我们将提取 JSON path 为 $.contributors[4].username （也就是第五个贡献者）的用户名值放入变量 contributorName：

添加查看结果树元素到请求下​

右键单击采样器，Add > Listener > View Results Tree 添加查看结果树如下：

添加 HTTP 采样器请求特定的贡献者信息​

右键单击线程组，Add > Sampler > HTTP Request 添加采样器（这里在 path 属性填入 ${contributorName} 用于引用上一个请求提取出的变量）：

添加查看结果树元素到请求下​

右键单击采样器，Add > Listener > View Results Tree 添加查看结果树如下：

点击绿色三角形进行执行​

点击执行按钮后，会提示我们先将文件保存后再执行，选择一个合适的目录保存后，点击执行按钮，此时绿色的执行按钮会变成灰色，同时右上角会开始计时，这表明请求正在执行，等按钮再次变成绿色时，说明执行结束了。

查看执行结果​

点击第一个请求的 查看结果树 元素可以查看这个请求的执行结果：

可以看到响应体的信息为：

查看第二个请求的请求数据，可以看到请求成功，且可以看到请求路径的 ${contributorName} 已经渲染为第一个请求提取到的值 handchoerodon：

总结​

JMeter 提供了 HTTP 采样器，各种断言机制，配置机制以及变量提取机制，可以帮助进行我们模块化的接口测试，使得系统更加健壮。

扩展资料​

• 随机变量
• 边界提取器
• 正则表达式提取器
• 响应时长断言
• 响应体JSON 断言

参考文档​

1. JMeter Get Started
2. JMeter组件说明

此前文章Choerodon猪齿鱼 Agent——基于GitOps的云原生持续交付模型介绍了Choerodon Agent基于helm2版本在Choerodon平台持续交付部署流水线中的作用以及实现原理。

现在最新helm版本已经到helm3，继续使用helm2会面临着如下问题:

1. helm2版本使用的k8s api较老，不利于Choerodon Agent对k8s高版本进行支持
2. helm2架构是client-server架构。其中tiller-pod需要高集群权限，不方便集群中权限管理。同时在Choerodon Agent这边又属于客户端，出现问题后不方便进行调试

因此Choerodon Agent需要支持helm3版本，同时迁移helm2版本下安装的实例。

helm2与helm3区别

1. tiller被删除

如图所示，helm2中部署Release需要经过tiller-pod，但是在helm3就直接通过kubeconfig部署实例

2. helm2中Release是全局资源，在helm3中Release存储在各自的命名空间
3. Values支持JSON Schema校验器，自动检查所有输入的变量格式
4. 移除了用于本地临时搭建Chart Repository的helm serve 命令
5. helm install 不再默认生成一个Release的名称，除非指定了--generate-name
6. Helm Cli个别更名

helm2到helm3的迁移

helm2到helm3的迁移包括如下步骤:

• helm2的配置迁移
• helm2的release迁移
• 清除helm2的配置、release数据以及Tileer deployment

使用helm-2to3进行数据迁移​

安装2to3插件​

helm3 plugin install https://github.com/helm/helm-2to3

插件特性​

支持功能:

• 迁移helm2的配置
• 迁移helm2的releases
• 清除helm2的配置，rel ease 数据以及Tiller deployment

迁移helm2的配置​

首先需要迁移helm2的配置和数据文件夹，包括如下内容:

• Chart starters
• Repositories
• Plugins

通过如下命令开始迁移:

helm3 2to3 move config

迁移helm2的实例​

通过如下命令开始迁 移:

helm3 2to3 convert [ReleaseName]

清除helm2的数据​

如果迁移完成后没有出现错误，就可以通过 此条命令清楚helm2的数据，包括如下内容:

• Configuration(Helm homedirectory)
• v2release data
• Tiller deployment

通过如下命令开始清楚数据:

helm3 2to3 cleanup

注意：如果运行清楚命令，所有被删掉的 数据都不能恢复。所以没必要的话，还是将以前的数据保留下来

Choerodon Agent的升级处理

helm2到helm3的变动非常大，所以Choerdon Agent调用helm也发生巨大变化。其中有两部分需要进行修改

1. helm客户端获取、安装、升级、卸载实例需要重构
2. 需要迁移helm2安装的实例到helm3，不然升级后Choerodon Agent无法继续管理以前的实例

helm客户端重构​

在helm2的时候，Choerodon Agent直接将helm源代码作为Choerodon Agent部分代码进行使用。而在helm3，直接对helm3的源码进行二次开发，然后通过依赖引用。这样做的好处是将helm代码与Choerodon Agent代码解藕，有利于helm相关代码更新升级。

在Choerodon Agent里面，安装或升级实例会对Chart中的资源添加Choeordon Agent相关的label，比如choerodon.io/release、choeroodn.io/command等等，所以helm3的二次开发主要是添加资源label，以安装(Install)操作举例，其他操作(升级、删除)大同小异。

1. 修改模块名称​

进行二次开发，首先需要修改该项目的模块名称，该步骤也是最麻烦的，因为修改后需要修改代码里面所有的包引用路径

如图所示，go.mod文件中的module进行如下修改

github.com/choerodon/helm => github.com/open-hand/helm

然后代码文件中修改引用路径

2. 加入添加label逻辑​

通过断点调试，找到helm3安装逻辑由open-hand-helm/pkg/action/install.go::Run()方法实现，在该方法中插入添加标签步骤。下面省略不必要的代码

func (i *Install) Run(chrt *chart.Chart, vals map[string]interface{}, valsRaw string) (*release.Release, error) {
  // ···省略的步骤是helm对chart包进行校验渲染，生成k8s对象,并保存到resources变量中

    // 以下为修改的内容，遍历resources对象，添加Label
    for _, r := range resources {
        err = action.AddLabel(i.ImagePullSecret, i.Command, i.AppServiceId, r, i.ChartVersion, i.ReleaseName, i.ChartName, i.AgentVersion, "", i.TestLabel, i.IsTest, false, nil)
        if err != nil {
            return nil, err
        }
    }
  // ···省略的步骤是helm将resources更新到集群中
}

接下来看看open-hand-helm/pkg/agent/action/label.go::AddLabel()方法

func AddLabel(imagePullSecret []v1.LocalObjectReference,
    command int64,
    appServiceId int64,
    info *resource.Info,
    version, releaseName, chartName, agentVersion, testLabel, namespace string,
    isTest bool,
    isUpgrade bool,
    clientSet *kubernetes.Clientset) error {
    // 该方法内容比较多，不在这里展示，具体可参考源代码。其作用就是根据不同的资源类型添加不同的Label值
}

3. Choerodon Ag ent 引用二次开发的helm库​

参照helm3源码install命令的初始化方式，将分为以下几个步骤

1. 获取helm配置信息

// 获取helm的配置信息
func getCfg(namespace string) (*action.Configuration, *cli.EnvSettings) {
    settings := cli.New()
    settings.SetNamespace(namespace)
    actionConfig := &action.Configuration{}
    helmDriver := os.Getenv("HELM_DRIVER")
    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), helmDriver, debug); err != nil {
        log.Fatal(err)
    }
    return action config, settings
}

2. 创建Install操作对象

    installClient := action.NewInstall(
        cfg,
        chartPathOptions,
        request.Command,
        request.ImagePullSecrets,
        request.Namespace,
        request.ReleaseName,
        request.ChartName,
        request.ChartVersion,
        request.AppServiceId,
        envkube.AgentVersion,
        "",
        false)

3. 校验chart包并生成values值

    ···
    valueOpts := getValueOpts(request.Values)
    p := getter.All(envSettings)
    vals, err := valueOpts.MergeValues(p)
    if err != nil {
        return nil, err
    }

    // Check chart dependencies to make sure all are present in /charts
    chartRequested, err := loader.Load(cp)
    if err != nil {
        return nil, err
    }

    validInstallableChart, err := isChartInstallable(chartRequested)
    if !validInstallableChart {
        return nil, err
    }
    ···

4. 调用安装方法，执行安装命令

···
responseRelease, err := installClient.Run(chartRequested, vals, request.Values)
···

具体的逻辑可查看choerodon-cluster-agent/pkg/helm/helm.go::InstallRelease()

总结来说就是以下4个步骤:

获取配置对象->生成操作对象->校验chart包并生成values值->执行操作

对已安装的Release进行迁移​

对Release的迁移需要用到helm迁移工具，该工具是直接集成到Choerodon Agent项目代码中的。

在Choeordon Agent的启动逻辑中，接收到的第一个命令是agent_init。该命令负责命名空间的创建和监听，因此Release迁移逻辑也就放到这一步操作中。

整个流程如下图所示：

1. 首先从choerodon-cluster-agent/pkg/command/agent/agent.go::InitAgent()方法开始

func InitAgent(opts *commandutil.Opts, cmd *model.Packet) ([]*model.Packet, *model.Packet) {
// ···省略的步骤是处理初始化的参数

  // 下面的代码开始对需要监听的命名空间进行初始化
    for _, envPara := range agentInitOpts.Envs {
        nsList = append(nsList, envPara.Namespace)
        err := createNamespace(opts, envPara.Namespace, envPara.Releases)
        if err != nil {
            return nil, commandutil.NewResponseError(cmd.Key, cmd.Type, err)
        }
    }

// ···省略的步骤是开启gitops监听、controller监听、以及返回集群信息
}

2. 在choerodon-cluster-agent/pkg/command/agent/agent.go::createNamespace()开始初始化命名空间

func createNamespace(opts *commandutil.Opts, namespaceName string, releases []string) error {
    ns, err := opts.KubeClient.GetKubeClient().CoreV1().Namespaces().Get(namespaceName, metav1.GetOptions{})
    if err != nil {
        // 如果命名空间不存在的话，则创建
        if errors.IsNotFound(err) {
            _, err = opts.KubeClient.GetKubeClient().CoreV1().Namespaces().Create(&corev1.Namespace{
                ObjectMeta: metav1.ObjectMeta{
                    Name:   namespaceName,
                    Labels: map[string]string{model.HelmVersion: "helm3"},
                },
            })
            return err
        }
        return err
    }

    labels := ns.Labels
    annotations := ns.Annotations
    // 如果命名空间存在，则检查labels标签
    if _, ok := labels[model.HelmVersion]; !ok {
    // 开始迁移实例
        return update(opts, releases, namespaceName, labels, annotations)
    }
    return nil
}

3. 在choerodon-cluster-agent/pkg/command/agent/agent.go::update()中迁移实例

func update(opts *commandutil.Opts, releases []string, namespaceName string, labels, annotations map[string]string) error {
    releaseCount := len(releases)
    upgradeCount := 0

    // 此处不对choerodon命名空间下的实例进行迁移处理
    // 安装agent的时候，会直接创建choerodon命名空间而不打上 model.HelmVersion 标签
    // 然后用户直接创建pv,会导致choerodon没有标签也纳入环境管理（如果通过agent安装了prometheus或者cert-manager就会出现问题）
    // 所以直接默认choeordon不需要进行helm迁移
    if namespaceName != "choerodon" && releaseCount != 0 {
        for i := 0; i < releaseCount; i++ {
            getReleaseRequest := &helm.GetReleaseContentRequest{
                ReleaseName: releases[i],
                Namespace:   namespaceName,
            }

            // 查看该实例是否helm3管理，如果是upgradeCount加1，如果不是，进行迁移操作然后再加1
            _, err := opts.HelmClient.GetRelease(getReleaseRequest)
            if err != nil {
                // 实例不存在有可能是实例未迁移，尝试迁移操作
                if strings.Contains(err.Error(), helm.ErrReleaseNotFound) {
                    helm2to3.RunConvert(releases[i])
                    if opts.ClearHelmHistory {
                        helm2to3.RunCleanup(releases[i])
                    }
                    upgradeCount++
                }
            } else {
                // 实例存在表明实例被helm3管理，尝试进行数据清理，然后upgradeCount加1
                if opts.ClearHelmHistory {
                    helm2to3.RunCleanup(releases[i])
                }
                upgradeCount++
            }
        }

        if releaseCount != upgradeCount {
            return fmt.Errorf("env %s : failed to upgrade helm2 to helm3 ", namespaceName)
        }
    }

  // 添加label
    if labels == nil {
        labels = make(map[string]string)
    }

    labels[model.HelmVersion] = "helm3"
    _, err := opts.KubeClient.GetKubeClient().CoreV1().Namespaces().Update(&corev1.Namespace{
        ObjectMeta: metav1.ObjectMeta{
            Name:        namespaceName,
            Labels:      labels,
            Annotations: annotations,
        },
    })
    return err
}

由此完成了Choerodon Agent对Release的迁移逻辑

常见问题解决

1. 有时候Choerodon Agent重启后，会出现启动失败的问题，查看日志有实例迁移失败，tiller-pod不存在错误

该问题可能是实例迁移完成后，命名空间的label添加失败。解决办法是手动给该命名空间添加"choerodon.io/helm-version":"helm3" 标签，以此表示该命名空间的实例迁移已完成，不需要再次迁移

2. 修改资源后，部署失败，且错误信息提示为超时

首先在devops的环境层检查三个commit值是否一致，有如下情况：

• 前两个commit不一致：说明devops在gitlab的webhook回调处理上有问题，应该从gitlab的webhook执行记录以及devops日志进行排查
• 前两个一致，第三个落后于前两个：说明devops同步相关gitops操作已完成，但是在Choerodon Agent同步gitops库上出了问题。

这时先保留一份日志，供开发人员查找分析，然后kubectl -n choerodon delete [podName]删除Choerodon Agent进行重启。

如果重启完成后，Choerodon Agent仍然没有同步gitops库，这时应该考虑该环境库在gitlab的密钥是否与devops数据库中存储的一致。先在本地验证能否通过该密钥拉取gitops库。如果不行，重置该gitops库的密钥，最好的办法就是删掉该环境重新创建。如果可以，那么说明Choerodon Agent与gitlab连接有问题，检查gitlab的端口开发情况以及Choerodon Agent与外部网络的访问连接情况

• 三个commit都一致，但是实例部署失败，且提示访问chart仓库超时：这个问题经常遇到。排查后发现是Choerodon Agent与Chart Museum网络连接有问题

前言​

将 Java 应用容器化虽然更好地解决了可移植性问题，但也存在着一些不友好的情况，比如低版本的JDK（低于Java 8u131）并不能识别 CGroup 资源限制。这将导致JVM读取的是宿主机的全部CPU和内存，一但容器使用资源超过限制则会被 docker 杀死。

在 kubernetes 中，我们会显示在 yaml 文件中配置CPU、内存请求和限制，我们希望容器中的JVM进程能够自动识别到 CGroup 资源限制，获取到正确的内存和CPU信息从而自行动态调整。

JVM 参数配置​

以下操作皆在一台 4C 16G 服务器上进行。

版本低于 8u131​

JDK 版本低于 8u131 版本的 JVM 不会自动识别到 CGroup 资源限制，需要手动设置初始堆大小以及最大堆大小，否则会按照宿主机的全部内存设置默认值：

• 配置最大堆大小 -Xmx，默认值：内存的1/4
• 配置初始堆大小 -Xms，默认值：内存的1/64

未配置JVM参数​

可以看到 Max. Heap Size (Estimated): 3.48G，未能正确识别 CGroup 资源限制

$ docker run --rm -m 2GB openjdk:8u121-alpine java -XshowSettings:vm -version

VM settings:
    Max. Heap Size (Estimated): 3.48G
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (IcedTea 3.3.0) (Alpine 8.121.13-r0)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

配置JVM参数​

配置 -Xmx 和 -Xms 后即可达到我们想要的结果

$ docker run --rm -m 2GB openjdk:8u121-alpine java -XshowSettings:vm -Xmx2000m -Xms2000m -version

VM settings:
    Min. Heap Size: 1.95G
    Max. Heap Size: 1.95G
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (IcedTea 3.3.0) (Alpine 8.121.13-r0)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

8u131 及以上版本​

从 8u131 版本开始支持 UseCGroupMemoryLimitForHeap 和 MaxRAMFraction 这两个选项，用 CGroupMemory 的大小作为 JVM heap size，MAXRAMFraction 是用来控制实际可用的内存数量的，比如设置为 1 的话就是 CGroupMemoryLimit 的全部，设置为 2 的话一半，3 的话就是 1/3，以此类推

| MaxRAMFraction取值 | 堆占比 | 容器内存=1G | 容器内存=2G | 容器内存=4G | 容器内存=8G | 容器内存=16G | | :--------------------: | :--------- | :-------------: | :-------------- | :-------------: | :-------------- | :--------------: || | | | | | | | 1 | ≈90% | 910.50M | 1.78G | 3.56G | 7.11G | 14.22G | | 2 | ≈50% | 455.50M | 910.50M | 1.78G | 3.56G | 7.11G | | 3 | ≈33% | 304.00M | 608.00M | 1.19G | 2.37G | 4.74G | | 4 | ≈25% | 228.00M | 455.50M | 910.50M | 1.78G | 3.56G |

未配置JVM参数​

可以看到 Max. Heap Size (Estimated): 3.48G，未能正确识别 CGroup 资源限制

$ docker run --rm -m 2GB openjdk:8u131-alpine java -XshowSettings:vm  -version

VM settings:
    Max. Heap Size (Estimated): 3.48G
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_131"
OpenJDK Runtime Environment (IcedTea 3.4.0) (Alpine 8.131.11-r2)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

配置JVM参数​

配置 -XX:+UnlockExperimentalVMOptions、-XX:+UseCGroupMemoryLimitForHeap 和 -XX:MaxRAMFraction=1 后即可达到我们想要的结果

$ docker run --rm -m 2GB openjdk:8u131-alpine java -XshowSettings:vm -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction=1 -version

VM settings:
    Max. Heap Size (Estimated): 1.78G
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_131"
OpenJDK Runtime Environment (IcedTea 3.4.0) (Alpine 8.131.11-r2)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

8u191 及以上版本​

从 8u191 开始引入了 java10+ 上的 UseContainerSupport 选项，而且是默认启用的，不用设置。同时 UseCGroupMemoryLimitForHeap 这个就弃用了，不建议继续使用，同时还可以通过 -XX:InitialRAMPercentage、-XX:MaxRAMPercentage、-XX:MinRAMPercentage 这些参数更加细腻的控制 JVM 使用的内存比率。比如一些 Java 程序在运行时会调用外部进程、申请 Native Memory 等，所以即使是在容器中运行 Java 程序，也得预留一些内存给系统的。所以 -XX:MaxRAMPercentage 不能配置得太大。

未配置JVM参数​

可以看到未添加任何 JVM 参数即可正确识别到 CGroup 资源限制

$ docker run --rm -m 2GB openjdk:8u191-alpine java -XshowSettings:vm -version

VM settings:
    Max. Heap Size (Estimated): 455.50M
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_191"
OpenJDK Runtime Environment (IcedTea 3.10.0) (Alpine 8.191.12-r0)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

配置JVM参数​

• 使用 -XX:MaxRAMFraction 参数调整 Max. Heap Size 大小

  $ docker run --rm -m 2GB openjdk:8u191-alpine java -XX:MaxRAMFraction=1 -XshowSettings:vm -version
  
  VM settings:
      Max. Heap Size (Estimated): 1.78G
      Ergonomics Machine Class: server
      Using VM: OpenJDK 64-Bit Server VM
  
  openjdk version "1.8.0_191"
  OpenJDK Runtime Environment (IcedTea 3.10.0) (Alpine 8.191.12-r0)
  OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

• 使用 -XX:InitialRAMPercentage、-XX:MaxRAMPercentage、-XX:MinRAMPercentage 参数更加细腻的控制 JVM 使用的内存比率

  $ docker run --rm -m 2GB openjdk:8u191-alpine java -XX:InitialRAMPercentage=40.0 -XX:MaxRAMPercentage=90.0 -XX:MinRAMPercentage=50.0 -XshowSettings:vm -version
  
  VM settings:
      Max. Heap Size (Estimated): 1.60G
      Ergonomics Machine Class: server
      Using VM: OpenJDK 64-Bit Server VM
  
  openjdk version "1.8.0_191"
  OpenJDK Runtime Environment (IcedTea 3.10.0) (Alpine 8.191.12-r0)
  OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

参考资料​

• http://www.51gjie.com/java/551.html
• https://zhuanlan.zhihu.com/p/140849800
• https://my.oschina.net/neverforget/blog/4779579
• https://sevenyu.top/2019/04/01/java-resources-limit.html
• https://qingmu.io/2018/12/17/How-to-securely-limit-JVM-resources-in-a-container/