入门指引 表1 服务快速入门指引 服务 入门指引 整体流程类 使用CodeArts快速搭建基于E CS 部署的代码开发流水线 使用CodeArts快速搭建基于CCE部署的代码开发流水线 需求管理 创建Scrum项目并新建工作项 创建IPD系统设备类项目并新建工作项 软件建模 软件建模快速入门 代码托管 完成一次Scrum项目下的JAVA代码开发 管理员配置CodeArts Repo代码仓库的策略设置 流水线 通过流水线生成软件包并部署到主机 代码检查 快速检查CodeArts Repo代码仓库中的代码质量 编译构建 使用编译构建服务Ant构建并上传软件包至软件发布库 使用编译构建服务的Cmake构建并上传软件包至软件发布库 使用编译构建服务的Maven构建上传软件包和推送镜像 制品仓库 上传软件包到CodeArts Artifact软件发布库 上传私有组件到CodeArts Artifact中的Maven私有依赖库 部署 通过部署服务创建Tomcat应用并部署到ECS 测试计划 快速执行一次测试计划(CodeArts TestPlan)并查看测试报告 性能测试 性能测试快速入门 漏洞管理服务 如何使用漏洞管理服务 CodeArts IDE Online CodeArts IDE Online入门流程 5分钟创建并启动IDE实例 CodeArts IDE CodeArts IDE快速入门 Codearts 盘古助手 使用CodeArts 盘古助手生成代码及对应单元测试 开源镜像站 快速上手开源镜像站 开源治理服务 快速创建一个二进制成分分析任务 联接 使用空模板快速开始 使用组合应用模板快速开始

实践案例指引 表1 服务最佳实践指引 服务 入门指引 整体流程类 使用CodeArts管理电子商城项目开发流程 软件开发生产线安全配置概述 CodeArts权限配置最佳实践 需求管理 使用IPD系统设备类项目管理智能手表研发项目的原始需求 使用IPD系统设备类项目管理智能手表研发项目的缺陷 使用IPD系统设备类管理智能手表研发项目的基线评审 使用IPD系统设备类管理智能手表研发项目的特性树 使用看板项目对商城管理项目进行需求规划 代码托管 批量迁移GitLab内网仓库到Repo 如何批量将本地仓库导入Repo 流水线 通过微服务变更流水线修复项目BUG并快速发布 配置准出条件并对代码检查结果进行校验 通过流水线参数串联编译构建服务和部署服务 通过流水线生成标签名并通过上下文传递为代码仓库创建标签 基于Kubernetes原生Service的场景完成微服务蓝绿发布 代码检查 使用预置规则检查GitCode代码仓中的代码质量 使用预置规则检查通用Git代码仓中的代码质量 使用自定义规则检查CodeArts Repo代码仓中的代码质量 不上传代码到云服务的情况下使用代码检查服务 使用自定义执行机执行代码检查任务 CodeArts Check通过调用API执行MR增量检查 使用Jenkins插件集成CodeArts Check执行代码检查 编译构建 基于Maven构建产物制作Docker镜像并发布到镜像仓 使用Maven构建上传软件包至私有依赖库 使用Maven构建实现私有依赖包的上传及下载引用 使用NPM构建上传软件包至软件发布库 使用自定义执行机执行Maven构建 使用Maven构建上传软件包和推送镜像到SWR 使用Maven构建执行多任务构建工程 基于私有依赖库使用Maven构建并上传软件包 使用自定义构建环境执行构建任务 对C/C++构建工程进行构建加速 制品仓库 通过编译构建任务发布Maven组件并按照版本归档至私有依赖库 通过编译构建任务发布/获取NPM私有组件 通过编译构建任务发布/获取Go私有组件 通过编译构建任务发布/获取PyPI私有组件 通过Linux命令行上传/获取RPM私有组件 通过Linux命令行上传/获取Debian私有组件 批量迁移Maven/NPM/PyPI组件至私有依赖库 批量迁移jfrog仓库至私有依赖库 部署 通过代理主机在内网部署应用 基于Nginx实现应用的灰度发布 基于Kubernetes Nginx-Ingress实现应用的灰度发布 通过自托管资源池部署应用至云下IDC 通过自托管资源池实现跨Region虚拟机部署 测试计划 基于接口自动化用例和关键字驱动的电商平台测试 基于需求策略使用测试设计 性能测试 城市政务一网通办系统性能测试 JMeter测试工程原生性能压测 全局变量使用全流程 漏洞管理服务 扫描具有复杂访问机制的网站漏洞 手动探索文件录制指导 使用CodeArts Inspector服务对内网主机进行扫描 CodeArts IDE Online 基于CodeArts IDE Online快速开发、部署微服务 基于CodeArts IDE Online快速开发、发布 WeLink 应用 基于CodeArts IDE Online、TensorFlow和Jupyter Notebook开发深度学习模型 CodeArts IDE 使用 CodeArts IDE for C/C++ 开发OpenGl示例工程 使用 CodeArts IDE for Java 开发简单的Java工程 效能洞察 通过项目经理驾驶舱查看项目状况及项目工作负荷 联接 Jira与CodeArts Req数据双向同步

为DBA Leader配置权限 DBA Leader仅需要配置流水线权限。 在“权限管理”页面，单击“创建角色”。如下图所示，新增角色“DBA Leader”角色。 图1 DBA Leader权限配置页面 在“权限管理”页面，单击左侧“DBA Leader”，单击“编辑”，为“DBA Leader”配置权限。 请按照下图，在“通用权限”配置权限。 图2 配置“DBA Leader”的“通用权限” 请按照下图，在“流水线”配置权限。 图3 DBA Leader的“流水线”权限

持续交付流程安全 在进行持续交付的过程中，可以通过设置私密参数、制品安全扫描、配置主机安全组操作，保证流程中的信息安全。 表3 持续交付流程安全 安全配置 说明 配置建议 参考资料 设置私密参数 编译构建、部署、流水线、测试计划服务支持私密参数功能。私密参数会被服务加密存储，使用时解密，同时在运行日志里不可见。 建议将包含敏感信息的参数设置为私密参数，以防止敏感信息泄露。 配置构建任务参数 配置部署服务应用的参数 配置流水线参数 接口自动化用例敏感参数配置 制品安全扫描 制品仓库服务提供制品安全扫描功能，支持对构建产物进行 漏洞扫描 ，并且能记录开源漏洞扫描结果，提供流水线安全门禁，管控制品质量。 建议定期对关键制品进行安全扫描。 制品安全扫描 配置主机安全组 用户使用官方资源池执行部署时，部署服务支持通过指定IP连接用户主机执行部署脚本。 用户可以通过配置主机安全组，建立部署服务与主机之间的访问策略。 建议配置安全组，限制目标主机、代理主机仅能与部署服务官方资源池的对外开放IP进行通信，增强部署服务的安全性。 配置安全组

运营安全 CodeArts具备精细化权限控制和审计追溯能力，以确保数据资产的安全。 表1 运营安全 安全配置 说明 配置建议 参考资料 精细化权限管控 CodeArts提供租户级权限、项目级权限、实例级权限三层权限模型，实现权限的清晰管理和控制。 建议管理员结合业务需要，遵从权限最小化原则，对成员分配权限。 CodeArts鉴权管理 审计日志 CodeArts各服务对接 云审计 服务（ CTS ），提供操作记录的收集、存储和查询功能。 建议开通CTS以支撑安全分析、合规审计、资源跟踪和问题定位等场景。 各服务支持审计日志的操作请参考： 需求管理服务 代码检查服务 编译构建服务 部署服务 流水线服务 测试计划服务 开通CTS请参考CTS入门指引。 IP白名单管控 代码托管、制品仓库服务支持设置IP白名单，限制对代码、制品等数据资产的访问，仅允许白名单内的IP访问。 建议设置信任的IP地址为IP白名单，减少未经授权用户或恶意攻击者进入系统的风险，降低遭受暴力破解、DDoS攻击等的可能性。 设置代码仓库IP白名单 设置制品仓库IP白名单 安全水印 代码托管提供水印设置功能，支持在源代码浏览页面添加访问者水印，提高代码页面展示的安全性，辅助溯源追责。 建议打开水印设置，保护代码仓库的知识产权。 代码仓库水印设置

代码安全 代码托管服务 （CodeArts Repo）通过提供访问令牌、部署密钥、保护分支管理等能力，为代码资产安全保驾护航。 表2 代码安全 安全配置 说明 配置建议 参考资料 访问令牌 CodeArts Repo为每个用户提供生成访问令牌功能，令牌仅在生成时显示一次，并且可以设置有效期，默认有效期1个月，最长有效期为1年。 建议在授权个人仓库访问权限给第三方时，创建访问令牌并设置有效期，避免暴露账号密码。 配置访问令牌 部署密钥 CodeArts Repo支持为代码仓库添加部署密钥，通过部署密钥访问代码仓库时只有只读权限。 建议在构建等对代码仓库只读场景下，使用部署密钥克隆代码仓，尽可能避免密钥泄露等影响代码仓安全。 配置部署密钥 保护分支管理 在代码仓库中可以设置保护分支，防止此分支被修改或误删。 建议将主干分支设置为保护分支，仅能通过合并请求的方式将代码合入主干分支，且禁止任何人对保护分支做强制推送。 配置保护分支 可见范围管理 CodeArts Repo支持对代码仓库设置以下可见范围。 私有（仓库仅对仓库成员可见，仓库成员可读写和访问仓库） 公开 项目内成员只读 租户内成员只读 所有访客只读 建议结合业务需要，在新建仓库时选择相应的可见范围，或为已创建的代码仓库调整可见范围。 管理员也可以根据需要设置是否可以创建可见范围为“公开”的代码仓库。 设置仓库可见范围请参考新建仓库。 管理员设置是否创建可见范围为“公开”的代码仓库请调整仓库公开性。 提交规则管理 CodeArts Repo支持为代码仓库设置提交规则，用户可以选择服务提供的提交规则，也可以自定义提交规则。 建议结合业务需要，为每个仓库设置提交规则，防止代码被随意修改。 配置提交规则

预置流水线简介 示例项目中预置以下5个流水线任务，可根据需要查看并使用。 表1 预置流水线任务 预置流水线任务 任务说明 phoenix-workflow 基本的流水线任务。 phoenix-workflow-test 测试环境对应的流水线任务。 phoenix-workflow-work Worker功能对应的流水线任务。 phoenix-workflow-result Result功能对应的流水线任务。 phoenix-workflow-vote Vote功能对应的流水线任务。

测试助手Cindy测试代码文件 如图1 查询当前项目下的IR需求，输入“查询当前项目下的IR需求”，产品助手Pony即可查询当前项目下的所有IR需求。 图1 查询当前项目下的IR需求 如图2 唤醒Cindy编写代码测试用例，输入指令“针对需求ID为IR20250603495544的需求进行测试”，唤醒测试助手Cindy，并让Cindy对开发助手David编写代码的代码编写测试用例。单击“继续执行”，Cindy便会进行四维导图的设计。 图2 唤醒Cindy编写代码测试用例 如图3 查看Cindy生成的测试用例，根据提示，单击“继续执行”，即可完成测试用例的生成，并预览生成的测试用例。 图3 查看Cindy生成的测试用例 如图4 将生成的测试用例加入测试套，单击“继续执行”，并回复“好的，整合测试套”，即可把Cindy生成的测试用例加入测试套。 图4 将生成的测试用例加入测试套 父主题： 实施步骤

为PM组配置权限 进入“权限管理”页面，单击“创建角色”。例如图1 新增“项管Leader”角色所示，新增“项管Leader”角色，并复制为产品Leader配置权限的权限。 图1 新增“项管Leader”角色 单击左侧“项管Leader”，单击“编辑”，为“项管Leader”配置权限。 在复制“产品Leader”权限的基础上，仅需要修改“需求管理&缺陷管理”权限，其余权限与“产品Leader”保持一致，如图2 项管Leader的“需求管理&缺陷管理”权限所示。 图2 项管Leader的“需求管理&缺陷管理”权限 父主题： 实施步骤

为项目经理配置权限 项目经理不需要配置“代码托管”、“代码检查服务”和“测试计划”配置权限。 在“权限管理”页面，单击左侧“项目经理”，单击“编辑”，为“项目经理”配置权限。 请按照下图，在“通用权限”和“需求管理&缺陷管理”配置权限。 图1 Devops Leader的“通用权限”和“需求管理&缺陷管理”权限 请按照下图，在“流水线”、“编译构建”、“部署”和“制品仓库”配置权限。 图2 Devops Leader的“流水线”、“编译构建”、“部署”和“制品仓库”权限 请按照下图，在“插件市场”配置权限。 图3 Devops Leader的“插件市场”权限 父主题： 实施步骤

HE2E DevOps框架简介 HE2E DevOps实施框架是CodeArts结合自身经验与业界先进的实践提出了一套可操作可落地的敏捷开发方法论。 图1 HE2E DevOps实施框架 表1 HE2E DevOps实施框架 阶段 说明 规划和设计 步骤①和②是业务（或者是客户）与技术之间进行产品规划，梳理产品整体脉络，以及进行产品规划实施设计，并控制需求粒度与拆分的过程。 软件开发的本质是为了解决问题，提供用户价值的，而不仅是为了提供功能。影响地图就是用来鉴别用户需求是什么，深层的根因是什么。 用户故事就是目标和需求的载体，以用户的场景来讲故事，便于在客户、业务与开发之间进行信息的传递。在这个过程中，独立的需求条目的堆积，很容易导致只能看到各个需求条目，不能从整个解决方案思考需求。用户故事以用户使用的场景为主线，将大的阶段点，及其细分的活动，以树状的结构进行梳理和展现，既可以看到独立的需求条目，又能够看到整体需求场景。 计划和跟踪 步骤③~⑩是Scrum框架过程，是主要的管理实践。 Scrum定义了一个相对完整的敏捷过程管理的框架。在CodeArts中，将Scrum的框架与团队日常的开发活动融合起来。主要的过程产物包括产品故事列表、迭代故事列表、潜在可交付的产品增量、以及过程中产生的问题列表；核心的团队活动包括迭代计划会议、每日站会、迭代演示会议、迭代回顾会议等会议、以及团队的日常更新。 同时，借鉴Kanban方法中的精益思想，可视化价值流，发现并解决阻塞与瓶颈，加速价值流交付，并加快反馈回路，持续进行改进。 迭代开发 持续交付 从步骤⑪开始，进入到工程实践，也就是通常说的CI/CD过程。 持续交付以代码仓库为基础，除了传统意义的代码资产安全与管控、多人并行开发、版本与基线管理外，也体现了团队的协作与沟通。 代码检查（即静态扫描）、自动化的构建、各阶段的自动化测试、以及自动化部署过程，都被串联在流水线上。 除了代码检查、构建、测试、部署等动态的阶段与活动，还有制品管理、环境管理（包括开发环境、测试环境、准生产环境，以及生产环境等）。 持续交付流水线就是将整个持续交付中，都有哪些阶段，分别运行在什么环境，每个阶段执行什么活动，准入与准出的质量门禁，以及每个阶段的输入与输出的制品进行管理。

方案架构 汽车零部件配件电子商城由5个微服务组件构成。 图2 凤凰商城技术架构图 表2 产品构成 微服务组件 说明 Web用户端服务器（对应样例代码中的“Vote”功能） 业务逻辑：用户可以通过浏览器访问此服务的WebUI。当用户在特定商品上单击“Like”时，服务将用户所选择物品的记录保存在Redis缓存中。 技术栈：Python、Flask框架。 应用服务器：Gunicorn。 Web管理端服务器（对应样例代码中的“Result”功能） 业务逻辑：用户可以通过浏览器访问此服务的WebUI，会动态显示用户端UI上用户单击“Like”的统计数据，此数据来自PostgreSQL数据库。 技术栈：Node.js、express框架。 应用服务器：server.js。 后台订单批处理程序（对应样例代码中的“Worker”功能） 业务逻辑：此服务为后台进程，会监控Redis缓存中物品记录，并将新纪录取出并保存在PostgreSQL数据库中，以便管理端UI可以抽取数据进行统计显示。 技术栈：.net core或者Java（此服务提供两种技术栈实现了同样的功能，可根据需要修改配置选择其中一个作为运行时进程）。 订单缓存 业务逻辑：此服务作为用户端UI服务的数据持久化服务存在。 技术栈：Redis。 订单数据库 业务逻辑：此服务作为管理端UI服务的数据源。 技术栈：PostgreSQL。 项目研发过程中涉及到以下成员。 表3 项目角色列表 项目成员 项目角色 工作职责 Sarah 项目管理员 负责项目整体规划、项目团队的组建。 Maggie 项目经理 负责管理项目交付计划。 Chris 开发人员 负责项目代码的开发、编译、部署及验证。 Billy 测试人员 负责编写测试用例并执行。

开发助手David编写代码 如图1 在IDE查询待处理的IR需求所示，在IDE输入查询待处理的IR需求。 图1 在IDE查询待处理的IR需求 如图2 David进行代码开发所示，单击“是，处理museverse头像功能需求”，继续单击“批准”，David会继续获取需求的详情。 图2 David进行代码开发 单击“立即开发”，David会继续进行代码开发。 图3 David进行代码开发 如下图，David在右侧持续输出代码开发的内容。 图4 David开发代码的界面 如图5 David完成代码开发界面所示，David开发完代码后，您可以在界面左侧返回代码开发涉及的特性清单。 图5 David完成代码开发界面 如下图，单击“暂不提交”，用户可再检查代码文件。 图6 暂不提交代码文件 如下图，在终端输入命令npm run build:mp-weixin，执行build:mp-weixin脚本。 图7 执行运行脚本的命令 执行上述命令后，即可预览生成的效果。单击头像，上传本地文件，即可上传头像文件，完成头像的自定义功能。 图8 生成预览效果 父主题： 实施步骤

开发助手David修复检视意见 如下图所示，用户输入指令“查询待处理的MR”，继续单击“批准”，即可查询待处理的MR。 图1 查询待处理的MR 用户查询出的代码仓库ID后，单击“批准”，即可继续查询MR。 图2 查询待处理的MR 如下图所示，查询到还未合入的合并请求“MR30”。输入“处理MR30的检视意见”，David将会处理5的3条检视意见。 图3 查询还未处理的MR列表 用户根据提示，单击“批准”，即可修改“MR30”的检视意见。如下图所示，右侧将实时展示修改的代码。 图4 修改检视意见 当MR的检视意见修改完成后，输入“是”，可对修改后的代码进行代码检视。 图5 对修改后的代码做代码检视 如下图，在终端输入命令npm run build:mp-weixin，执行build:mp-weixin脚本。 图6 执行运行脚本的命令 执行上述命令后，即可预览生成的效果，头像正常显示。 图7 生成预览效果 预览效果无误，输入“是，提交代码”，可提交修改后的代码。 图8 提交修改后的代码 父主题： 实施步骤

通过合并请求合并代码 开发人员Chris在完成代码开发与自测后，提交分支合并请求，项目经理Maggie审核合并请求后完成合入。 Chris提交合并请求。 在代码仓库“phoenix-sample”中选择“合并请求”页签，单击“新建合并请求”。 源分支选择“Feature-Store”，目标分支选择“master”，单击“下一步”。 参照下表编辑合并请求详情。 表2 合并请求配置 配置项 示例 标题 添加门店网络列表。 合并人 单击，在弹框中勾选“Maggie”，单击“确定”。 审核人 单击，在弹框中勾选“Maggie”，单击“确定”。 单击“新建合并请求”完成合并请求的创建。 新建成功，页面中显示合并请求的详情。 Maggie审核合并请求。 进入代码仓库“phoenix-sample”，选择“合并请求”页签，可找到由开发人员Chris创建的合并请求。 单击该请求，查看合并请求详情。 可在页面中留下评审意见。单击审核门禁中“通过”完成审核。 图4 审核门禁 单击“合入”，将分支合入“master”。 提示成功，完成合入。