检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
根据项目需求,对工作项变更的通知方式、工作项状态的流转方式等进行自定义设置。 开发代码 通过分支来进行代码的编写,包括创建分支、代码提交、合并分支等操作。 检查代码 对代码进行静态扫描,根据修复建议优化代码,提高代码质量。 构建应用 构建环境镜像、将代码编译打包成软件包。 部署应用 将构建好的环境镜
专业版升级为铂金版 铂金版增加人数 续费降配 铂金版减少人数 提交续费订单,在新的订单周期内生效。 说明: 续费降配后,当前订单周期内不可再变更规格,进入新的续费周期后可变更规格。 如果由高版本降为低版本,进入降配后的周期时,已使用的存储空间资源可能会被冻结。 例如:由专业版降级至基础版,降级前已
Why——为什么这样解决是合理的,比其他解决方法更好? 合并请求的提交要清晰 一个好的合并请求不只是代码的事情,还牵涉到代码审查者对代码的审查,所以开发者不仅要写出好的代码,还需要考虑如何让其他人更清晰的理解自己的想法和思路,这是一个用代码做交流的过程。 进行较小的合并请求。 每个合并请求只做一件事情。
本章为您介绍使用CodeArts时常用的基本概念。 项目 项目是通过一定的流程,由一系列协同和受控的活动组成,项目的目标是满足特定需求,并受时间成本和资源的约束。 CodeArts项目中可以完成需求管理、代码管理、代码检查、编译构建、制品管理、部署、测试等一系列操作。 资源池 资源池是自定义执行机的集合。 通
入。 开箱即用的洞察分析平台 提供100+开箱即用的指标库,覆盖需求、缺陷、代码、构建、测试、部署、发布端到端主题领域,同时可以基于强大的洞察平台进行自定义指标和数据探索。 灵活可扩展的自定义报表 提供丰富的数据分析图表类型和强大的自定义报表能力,满足企业定制化的场景诉求,从而构
们相信,在以华为云为代表的国内厂商的共同努力下,我国的软件工程能力将会得到显著的提升,我国的DevOps产品的能力也会得到迅速的提高,从而帮助中国企业落地DevOps,推动中国企业从DevOps的初始级和基础级的阶段,向全面级、优秀级、卓越级转变,全方位的促进国内软件产业发展,打
在导航栏中单击用户名,选择“租户设置”。 单击导航“通用设置 > 全局设置”。 根据需要进行水印开启或关闭操作。 可单击服务名称旁的开关,开启或关闭对应服务的水印 可单击“全部开启”或“全部关闭”,开启或关闭所有服务的水印。 父主题: 其它管理操作
时”查看成员的实际工时分布。 用户可以单击成员右侧的图标,筛选项目成员进行查看、对比;也可以单击图标进行排序。 从以上步骤的图中可以看到爱丽丝的工作项为饱和状态,单击成员名称前的图标,可以查看该成员的需求和缺陷的分布区间。 单击某天的数据模块,可以查看该成员当天涉及的工作项、预计工时和实际工时。
提供针对于代码质量安全、Web漏洞、主机漏洞、开源漏洞及合规、移动应用安全等多种安全合规检查能力。 华为多年研发实践能力及规范外溢 华为多年研发优秀实践沉淀的工具能力外溢,支持IPD、DevSecOps、敏捷、精益看板、CI/CD持续交付等多种主流研发模式。 覆盖嵌入式、云服务、微服务、移动应用等
您可以在“费用中心 > 账单管理”查看与CodeArts相关的流水和明细账单,以便了解您的消费情况。如需了解具体操作步骤,请参见费用账单。 欠费 当使用CodeArts的同时,购买了其它服务的按需计费资源时,可能会产生计费。当账户的可用额度小于待结算的账单,即被判定为账户欠费。欠费后,可能会影响
添加CodeArts项目成员 管理CodeArts权限 管理CodeArts资源池 新建CodeArts服务扩展点 管理CodeArts中的个人设置 其它管理操作
、但未添加管理员为成员的项目列表。 如果想要查看更详细的项目信息,可根据需要勾选项目,单击加入项目即可。 图1 未加入的项目列表 在“已加入的项目列表”页签中,可以查看已加入的项目列表。 在“项目成员列表”页签中,可以查看全部项目(包括管理员已加入和未加入的项目)、以及每个项目的成员列表。
当两个拥有华为账号的企业A、B合作开发一个项目时,在企业A的账号中创建CodeArts项目后,可以向该项目中添加企业B的账号中的IAM用户。 本节中涉及两个账号A、B,账号A的IAM用户a创建了CodeArts项目X,邀请账号B的IAM用户b成为CodeArts项目X的成员。 本节中
缺乏自动化的持续集成工具。 推荐搭配 需求管理、代码托管、编译构建、测试计划、部署、流水线。 实现结果 开发人员高效协作,项目开发周期可控可观,快速响应客户需求。 传统企业互联网+转型 研发挑战 传统企业在进行互联网+转型的过程中,由于软件开发能力较低,无法有效地度量软件的进度、生
有价值的产品,快速试错,并通过不停的迭代最终找到产品的正确方向。 这个思路很好,但如何确认backlog中的内容是“最小的”而且“可用”的产品却是件很困难的事情。 团队一起讨论初始产品需求的时候,常常会因为团队成员的理解不同而花费大量的时间进行梳理。即使每次讨论都将结果用文档记录