检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
BUILDNUMBER”进行替换。 上传Kubernetes部署文件到软件发布库 将“替换Kubernetes部署文件镜像版本”步骤中修改后的所有“.yaml”文件上传到软件发布库中归档。 上传docker-compose部署文件到软件发布库 将“替换Docker-Compose
成分分析的安全配置类问题如何分析? 组件版本为什么没有被识别出来或识别错误? 成分分析的开源漏洞文件路径如何查看? 成分分析的任务扫描失败怎么办? 扫描到恶意代码如何定位? 如何解决Roles with READONLY_USER或其他角色权限报错问题?
postgres”。 替换基础镜像源地址。 单击导航“代码 > 代码托管”,选择代码仓库“phoenix-sample”。 参照表6编辑代码文件中的基础镜像源地址。 表中的“${dockerServer}”、“${dockerOrg}”仅为参数示例。实际替换镜像源地址时,请参照图
当我们面对敏捷和DevOps的时候,总会不可避免的思考下面这些问题: 敏捷是什么?DevOps是什么?两者有什么区别? 持续集成不是XP里面的么,怎么DevOps也有持续集成? 我们团队之前在做敏捷转型,现在又开始DevOps转型,这两者有什么区别? 其实这些问题并没必要太过纠结,因为敏
如何将snapshot组件上传到Maven私有依赖库? 使用gradle构建任务上传maven包,返回500错误提示,该如何处理? 无法下载依赖的war、jar文件时怎么办? 本地构建Maven组件上传到私有依赖库,返回401错误提示,该如何处理? 客户端下载私有依赖库组件,返回http错误码403提示,该如何处理?
物理看板的优势和劣势 优势 成本低:几乎不需要成本,办公室允许粘贴的玻璃墙、白墙或者白板均可,再准备点便签和笔。 入门快:只要团队想好了怎么做,立刻可以做到工作的可视化,特别适合刚刚使用看板的入门级团队。 更改方便:对于看板的规划,只要有新的想法就可以灵活的变动和快速的实现。比
性能测试服务报告,日志各类报错的含义是什么? 为什么接口返回体有中文或特殊字符时,通过流量录制插件导出后中文或特殊字符显示乱码? 资源不足,执行器无法拉起怎么办?
所说的10秒页面。对于这部分问题CodeArts前端团队会怎么做?这就要回到DevOps的三步法,从左到右的流动,从右到左的反馈,以及持续学习的迭代。 这里的关键是第二步,从CodeArts面临的问题角度来看,就是我们怎么知道产品的每一个服务,每一个页面在什么时候开始发生了性能的
此外还有流程。如果线上发布过程和生产环境之间网络不通,应该怎么做呢?答案是工具并不能解决这个问题,因为这是流程问题。众所周知,华为公司有各种各样的安全红线,在做内部的云化服务化工具链落地实施的时候,最大的工作量集中在如何打破枷锁上,怎么把内网的一段代码或者一段测试用例或者二进制的安全文件
代码托管常见问题 升级CodeArts Repo的SSH功能 从本地推送代码仓到CodeArts Repo时,报错"Error: Deny by project hooks setting 'default': message of commit" 在一台电脑上,如何配置多个SSH
客户离开产品会不会觉得不爽,在很长一段时间之内靠人力就能够获得反馈。比如,几个产品经理一段时间都去客户那办公,坐到客户办公室里,观察客户怎么用产品,有什么问题,白天吐槽,吐槽之后赶紧让团队改。这个阶段不需要数据也是可以的,但是过了这段时间之后,比如产品做大规模的市场拓展,跟很多
的做让人感到痛苦的事。 小结 在开始行动之前,首先应思考需要解决的是什么问题,而不是去问应该采纳何种方式。 不应去问持续集成应该怎么做,TDD应该怎么做。那些都是解决方案域的东西,而应先搞清楚自身现存什么问题。正如去医院看病,不是直接找医生开药,而是应该问清楚自己是什么病,再对症开具体的药。
单击“选择镜像”,在弹框中勾选“demo”,单击“确定”。 更新策略 勾选“总是拉取镜像”。 镜像版本 选择“v1.0.0”。 高级配置 升级策略 升级方式选择“替换升级”。 页面提示创建成功,单击“查看工作负载详情”,返回负载详情页面,“实例列表”页签中显示一条记录。 当该记录的状态为“运行中”时,选
通过修改本地的配置文件信息,实现本地构建后直接将组件上传至CodeArts的私有依赖库中进行管理。 可从依赖库中直接生成配置信息,通过复制或下载配置文件直接替换的方式,修改本地配置信息。 想要了解详细的私有依赖库操作方法,请见快速上手私有依赖库。 CI at CodeArts 持续集成是CodeA
在开始介绍Scrum的组织架构之前,让我们先看一个小故事。 一天,一头猪和一只鸡在路上散步。鸡对猪说:“嗨,我们合伙开一家餐馆怎么样?”猪回头看了一下鸡说:“好主意,那你准备给餐馆起什么名字呢?”鸡想了想说:“叫‘火腿和鸡蛋’怎么样?”“那可不行。”猪说:“我把自己全搭进去了,而你只是参与而已。” 这则故事应用在敏捷
通过写清楚的提交信息,可以让其他人更容易跟上我们的思路并提供反馈。 提交说明要回答如下问题: What——要解决什么问题? When——什么情况下会发生? How——怎么样解决这个问题? Why——为什么这样解决是合理的,比其他解决方法更好? 合并请求的提交要清晰 一个好的合并请求不只是代码的事情,还牵涉到
专项团队做什么?在这个阶段团队要把测试专项能力向服务化能力转型。这时候测试专员就会在团队创建初期进行赋能,包括测试工程搭建,早期的测试用例怎么写,标准化模板的编制,针对非功能性测试的专项能力的赋能,所有团队进行测试流程的评审,包括测试策略、测试计划、测试用例的评审,再看一下整个团
常需要一年多以上,基本是一年一个版本,半年的时间做线上验证,包括到客户的机房验证,那个时候升级都需要选访问量最低的时候进行半夜断网升级。 怎么保证迭代的速度加快,迭代的质量逐步变得更好呢?后来我们探索了一套模式是分层分级流水线,进行大规模开发的持续交付模式,建立一个合理的结构,我们通常会分成四层。