-
CodeArts前端DevOps实践 - 软件开发生产线 CodeArts
现如何,监控生成的结果一目了然,会帮助他们知道问题是由于网络还是由于基础框架、业务写法、效率、接口,通过前端主动化、定制化的监控,可以快速识别,且降低交付成本。 第二部分是被动的例行的性能验收。CodeArts团队会从测试验收的维度思考问题,有的团队确实疏忽了,或者初期没有建立起
-
我在CodeArts做需求 - 软件开发生产线 CodeArts
通过新增字段可以标识不同类型的需求,更好的方式则是采用Tag标签。善用标签和过滤器的结合,可以实现非常强大的功能,关于过滤器的使用技巧,我们可以单开一个主题来讨论。 如何识别用户故事的坏味道(BadSmell) 如同低质量的代码会有Bad Smell,用户故事也一样会有坏味道: 几十页上百项需求堆在Product
-
软件开发生产线(CodeArts)使用流程 - 软件开发生产线 CodeArts
1 2 git config --global user.name "您的名字" git config --global user.email "您的邮箱" 输入以下命令行,生成一对SSH密钥。生成的密钥通常保存在“~/.ssh/id_rsa.pub”中。 1 ssh-keygen
-
DevOps VS 敏捷 - 软件开发生产线 CodeArts
是固化的。 方法论如此,学习和实践方法论的人,更应该如此,以一颗开放的心态,接纳一切合理的存在。 本文参考资料: 《DevOps explained》 Jérôme Kehrli 《Accelerate》 父主题: DevOps概览
-
交付在云端-全云DevOps实践 - 软件开发生产线 CodeArts
DevOps是正向价值链,运营反馈是反向价值链,通过不断的度量,实现各方面的提升。在此我们主要关注的是持续交付的交付链。将一个需求变成线上的特性,测试人员在线上测试通过,即完成了正向交付价值。但是实际交付的效果可能并不好,就会造成用户流失,这是非常严重的状况。在正向交付负向反馈的同时,我们要不断
-
持续集成 - 软件开发生产线 CodeArts
执行结果,并有相应的图示进行展示。 代码问题 在“代码问题”页可以看到代码中的具体问题及相应的修改建议。对于每一条代码问题,都可以进行快速在线修改,更改问题状态为未解决、已解决、已忽略,以及指派负责人。 代码度量 在“代码度量”页可以按文件查看代码的圈复杂度、代码重复率。 设置
-
使用CodeArts快速搭建基于ECS部署的代码开发流水线 - 软件开发生产线 CodeArts
进入代码仓库,搜索并打开文件“TestController.java”。 单击,将“hello world”修改为“hello world again”,输入提交信息后单击“确定”。 图7 修改代码 返回流水线页面,可看到流水线正在运行中。 当页面显示时,重新访问页面“http://I
-
DevOps现状报告解读 - 软件开发生产线 CodeArts
传统模式下的运维之痛。 事实证明,DevOps确实能够较好的解决开发和运维之间的混乱问题,提升研发效率,实现高效交付。在近期中国信通院(CAICT)发布的《中国DevOps现状调查报告(2019年)》(以下简称报告)中,超八成企业表示,通过采用DevOps中的核心工程实践“持续交
-
持续部署 - 软件开发生产线 CodeArts
在任务详情页单击“执行”按钮,即可开始部署。任务执行完成后,系统会显示部署结果(成功或失败)。 CCE部署 云容器引擎(Cloud Container Engine)提供高可靠高性能的企业级容器应用管理服务,支持Kubernetes社区原生应用和工具,简化云上自动化容器运行环境搭建
-
使用CodeArts快速搭建基于CCE部署的代码开发流水线 - 软件开发生产线 CodeArts
进入代码仓库,搜索并打开文件“TestController.java”。 单击,将“hello world”修改为“hello world again”,输入提交信息后单击“确定”。 图8 修改代码 返回流水线页面,可看到流水线正在运行中。 当页面显示时,重新访问页面“http://I
-
用户故事驱动的敏捷开发 - 软件开发生产线 CodeArts
如何用好用户故事,需要解决几个关键问题: 如何产生用户故事,让用户将故事讲清楚? 如何将用户故事的内容原汁原味的传递给开发团队? 如何将用户故事中的内容转换为开发功能点,识别与其他功能点的依赖,形成详细的产品规格? 如何在使用用户故事进行增量开发的过程中保持架构的稳定性,同时驱动架构的优化和演进? 如何在开发过
-
华为云CodeArts百人大规模精益DevOps转型 - 软件开发生产线 CodeArts
流程,到了什么环节所有人都看得非常清楚。产品经理每天就可以盯着看板上的需求流到了什么环节,如果到了转测就到转测环境里验收,如果已经上线了就在线上环境再验收一遍。每个服务都会有自己的看板。做了微服务和全功能团队之后,服务之间偶尔会有依赖,会需要另一个服务提供接口,如果完全没有依赖就