检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
效能洞察总览 效能洞察(CodeArts Board)为企业管理者、项目经理、团队Leader、开发者提供面向DevSecOps领域端到端的研发效能度量能力,提供从需求、缺陷、代码、构建、测试、部署、发布到运营等研发各阶段作业数据的分析洞察能力,覆盖交付质量、交付效率、交付能力、交付成本
DevOps VS 敏捷 当我们面对敏捷和DevOps的时候,总会不可避免的思考下面这些问题: 敏捷是什么?DevOps是什么?两者有什么区别? 持续集成不是XP里面的么,怎么DevOps也有持续集成? 我们团队之前在做敏捷转型,现在又开始DevOps转型,这两者有什么区别? 其实这些问题并没必要太过纠结
我在CodeArts做需求 秉承吃狗粮的文化,CodeArts团队在践行精益敏捷DevOps的同时,也在使用CodeArts工具进行实践落地。 需要说明的是: 本文中提到的实践方式,CodeArts团队在践行,所以具有一定的示范性。 不具备普适性,每个团队都应该根据自己团队的业务特性
DevOps现状报告解读 DevOps,是Development和Operations的组合词,是指一组过程、方法与系统的统称,用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。DevOps是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化
应用场景 互联网/Saas服务商 研发挑战 市场高速变化且竞争激烈,产品需要根据市场变化不断更新迭代和升级,但缺乏统一的持续交付工具确保产品随时可推向市场,缺乏工具保证客户快速反馈闭环。 推荐搭配 需求管理、代码托管、代码检查、编译构建、测试计划、部署。 实现结果 每日上线新功能,
如何构建高效的持续交付能力 持续集成、持续交付、持续部署、以及持续发布,到底是什么含义? 在回答之前,请大家先思考一个问题 :什么是交付过程最痛苦的事情? 集成的过程,测试的过程,以及部署与发布,都很痛苦,否则不会有敏捷与DevOps的各种方法与实践来解决这些问题,但是这些过程又都非常重要
解读华为云CodeArts HE2E端到端DevOps实施框架 我们经常讨论什么是敏捷、什么是精益、什么是DevOps。与其去讨论什么是,不如讨论为什么。 精益、敏捷与DevOps为什么会产生?目的是为解决软件研发交付中遇到的各种问题。 软件研发的过程,是价值交付的过程。而价值交付
敏捷项目管理 组建Scrum团队 本文将以一个示例项目为对象,介绍如何进行敏捷项目管理,示例项目背景如下: 凤凰商城示例项目介绍 【凤凰商城】示例项目是耗时数月所开发的汽车零部件配件电子商城。项目采用 Scrum模式 进行迭代开发,每个迭代周期为“两周”,前3个迭代已经完成“凤凰商城
CodeArts套餐规格特性差异 概述 CodeArts套餐分为:体验版、基础版、专业版、企业版。 套餐中均包含需求管理、代码托管、流水线、代码检查、编译构建、部署、测试计划、制品仓库、软件建模服务资源;不同版本套餐中,各服务提供的功能特性及资源规格略有不同。 需求管理 表1 需求管理规格特性差异
什么是DevOps DevOps概述 DevOps,即Development and Operations,是一组过程、方法与系统的统称,用于促进软件开发、运维和质量保障部门之间的沟通、协作与整合。DevOps的出现是由于软件行业日益清晰的认识到:为了按时交付软件产品和服务,开发和运维工作必须紧密合作
用户故事驱动的敏捷开发 敏捷开发现在已经不是新鲜事物了,从各种渠道都可以听到不同的团队实施敏捷的胜果,听的时候觉得很美,可是实际行动时就会发现那都是“别人家”的团队,结合自己的情况就会发现诸多问题。即使是仍然打算一试,也经常会不知如何开始。 因此,我们希望能够找到一个可以遵循的敏捷项目管理模型
持续交付流水线 以终为始,要想将持续交付、持续部署与持续发布讲清楚,就必须了解它们最终的目的,所有这些实践都是围绕着这一目的展开,并且相互关联的。 所以,持续交付也好,DevOps也罢,最终目标是快速的交付价值。 正如Jez Humble对持续交付的定义:“The ability
敏捷测试 在敏捷转型的过程中,传统的测试团队、测试人员遇到的挑战是巨大的,多方面的。本节将讲述敏捷测试的特点,以及在敏捷转型的过程中,测试人员在工作方式,组织架构,技术要求等各方面遇到的转变及挑战。并将结合华为云CodeArts,为大家着重讲解如何通过敏捷测试管理工具更好的在团队中实践敏捷测试的种种变化
影响地图 影响地图是一个简单却极高效的协作性的策略规划方法。 有的产品,它还活着,却已经死了;有的产品,还没发布,就已经死了。太多的产品失败的案例,源于方向性错误,基于错误的假设,功能与业务目标/价值之间缺乏必然的关联与一致性,在做的事与期望的目标南辕北辙。 影响地图试图通过结构化