检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
超期缺陷数:所选项目在当前时刻的已经超期还未完成的缺陷数,与所选时间段无关。 新增缺陷数:所选项目在所选时间段内新创建的缺陷。 修复缺陷数:所选项目在所选时间段内修复的缺陷数 缺陷修复周期:所选项目在所选时间段内完成的缺陷的平均修复时长。 缺陷修复速率:所选项目在所选时间段内单位时间平均修复的缺陷数。 缺陷按时修
具体内容如下: 时间盒是设定WIP数量限制的技术:WIP是已经开始但还没有完成的工作清单,开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项,因此时间盒是为每个冲刺设定WIP数量限制。 时间盒可以强制排列优先级:我们需要先执行高优先级的工作,时间盒可以强制我们按优先
实际工时:团队成员工作项的实际工时总计。 代码合入排名 - 度量指定时间段内团队用户提交的所有代码变更量。 团队用户在时间段内的代码变更量,代码变更量等于代码新增量减去代码删除量。 需求趋势 - 度量指定时间段内交付需求、存量需求每天的数量,从时间趋势上反映存量需求是否逐步减少并趋于相对稳定。 交
“华北-北京一”与“华东-上海二”区域已暂停新用户新购服务(详情请参见华北-北京一区域变更通知、华东上海二区域变更通知)。 如果被授权租户的注册时间在暂停时间之后,那么该租户将无法访问上述区域。 处理方法 被授权的租户通过提交工单,申请区域的配额后。授权方重新发出授权。 父主题: 整体咨询类问题
第二,用户转换率和网站的响应时间进行关联的结果基本是,响应时间越高,性能越差,转换率越低。 之前在知乎上有一个很出名的讨论,有个人分享他把网站的响应时间从10秒提高到2秒,效率提高500%的心得和过程。当时很多人评论他讲得好,但还有更多人批判这个问题,原因就是为什么你最初能够容忍一个响应时间为10秒
度量组织所有项目平均需求开发周期。 关闭时间在所选时间段内的平均需求开发周期。 近6个月平均需求开发周期趋势 天 度量组织所有项目近6个月平均需求开发周期。 关闭时间在近6个月内需求的平均需求开发周期。 需求开发周期项目对比 天 度量组织各个项目在所选时间段内平均需求开发周期。 关闭时间在所选时间段内各个项目平均需求开发周期。
续费概述 续费简介 CodeArts相关的订单到期后会影响CodeArts各服务的使用。如果您想继续使用,需要在指定的时间内续费订单。 CodeArts套餐到期后,如果未及时续费,代码仓库、构建任务、部署任务等资源会自动释放,数据丢失且不可恢复。CodeArts套餐到期后的状态说明,请参见到期后影响。
本章为您介绍使用CodeArts时常用的基本概念。 项目 项目是通过一定的流程,由一系列协同和受控的活动组成,项目的目标是满足特定需求,并受时间成本和资源的约束。 CodeArts项目中可以完成需求管理、代码管理、代码检查、编译构建、制品管理、部署、测试等一系列操作。 资源池 资源池是自定义执行机的集合。 通过资
每个团队都应该根据自己的需求做出选择。我们不应该关注形式,而应该关注结果:部署应该是无风险、按需进行的一键式操作。 持续交付 持续交付(CD) 是指,所有开发人员都在主干上进行小批量工作,或者在短时间存在的特性分支上工作,并且定期向主干合并,同时始终让主干保持可发布状态,并能做到在正常的工作时段里按需进行一键式
检查、构建等任务使用。 建议一台主机中只安装一个Agent,如果安装多个Agent可能在执行任务时导致Agent下线。 一个Agent同一时间只能执行一个任务。 前提条件 完成本操作的用户拥有资源池的“所有者”或“管理者”权限。 已完成新建CodeArts资源池。 拥有满足以下条件的主机。
三段式的用户故事,核心是从用户角度出发描述问题,站在用户的立场思考问题。 好的用户故事讨论的是为谁做和为什么做,而不仅仅是做什么。作为Who,我想要What,以便于Why。有了Who、Why、What的信息,How就变得呼之欲出了。以往我们上来就写需求的,往往注意到的是What(干什么
新增开发缺陷:创建时间在所选时间范围内的开发缺陷数量。 存量开发缺陷:状态为除去已关闭之外的开发数量。 代码合入次数趋势 - 度量指定时间段每天的代码提交次数,从时间上反映代码提交的频率。 在时间段内的代码提交次数。 代码变更量趋势 - 度量指定时间段内每天的代码量,从时间趋势上反映代码产出。
上限为1000GB。 计费公式 单价*存储容量*购买时长 计费周期 根据购买时长确定(以GMT+08:00时间为准)。一个计费周期的起点是您开通或续费知识库存储扩展的时间(精确到秒),终点则是到期日的23:59:59。 例如,如果您在2023/03/08 15:50:04购买时
选择“执行计划”页签。 打开“启用定时执行”开关,根据需要选择执行日与执行时间,关闭“代码变化才执行”,保存任务。 本文档中勾选“全选”,执行时间为“12:00”(本文中使用默认时区,可以根据实际需要修改时区)。 验证配置结果:根据配置时间查看构建任务是否自动执行,本节不再赘述。 父主题: 实施步骤
com/increase-rate-limit 原因分析 构建任务中使用的基础镜像源为DockerHub。由于DockerHub的限制,短时间内拉取次数较多时将受限无法拉取,因此可能会造成构建失败。 处理方法 可首先制作基础依赖镜像,推送到容器镜像服务中,以供正式构建时获取。 新建构建任务。
度量所选项目所选分支在所选时间内代码变更的行数。 代码仓库对应分支在时间段内的新增代码行数减去删除代码行。 代码合入次数 - 度量所选项目所选分支在所选时间内代码合入的次数。 代码仓库对应分支在时间段内的代码合入次数。 代码合入频率 次/天 度量所选项目所选分支在所选时间内单位时间代码合入的次数。
按普遍的理解,开发是技术域的事,按需发布是业务域的。本文就分别从这两个领域来简单论述持续交付流水线。 技术域 “客户并不一定需要每一个green build,PM/发布经理按业务需求可选择任意一个,在任何时候自动化交付给客户;在部署、交付、发布的上下文里,dev和ops的最高境界是无为,赋
那么,敏捷改善了些什么? 前置时间:传统开发法依循计划、分析、设计、程序开发、测试再进行修改整合后发布的步骤进行,是一种顺序性的开发模式,当前一个步骤用掉越多时间时,后面步骤的前置时间就会越长,而形成时间上越多的浪费。反观敏捷开发,实行的是一种务实的做法,当收集到足够一次迭代
代速度很快,测试时间留得很少,所有工作量的评估只评估开发完的事情,没有评估从开发到测试,乃至上线的时间点。环境本身也有问题,测试环境部署时间比较长,测试人员在α、β生产各个节点上面做部署,然后做验证,使得部署耗费了很多时间。 下面让我们再看看测试,测试最重要的是要做什么。这里有两个关键的焦点:
单次购买上限为100个。 计费公式 单价*数量*购买时长 计费周期 根据购买时长确定(以GMT+08:00时间为准)。一个计费周期的起点是您开通或续费代码安全检查增强包的时间(精确到秒),终点则是到期日的23:59:59。 例如,如果您在2023/03/08 15:50:04购买