检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
开通购买时报错“您的权限不足,请检查账号是否冻结、受限。 ” 问题现象 购买套餐过程中,页面提示“您的权限不足,请检查账号是否冻结、受限。” 原因分析 出现该提示,较常见的原因有以下几点: 账号未进行实名认证。 账号已欠费。 处理方法 通过实名认证:登录控制台,进入“账号中心”,根据实际情况完成实名认证
产品优势 一站式软件开发生产线 软件开发全流程覆盖:支持需求管理、代码托管、流水线、代码检查、编译构建、部署、测试、制品仓库等全生命周期软件开发服务。 开箱即用,云上开发,全流程规范可视,高效异地协作。 研发安全Built-In 在应用设计、开发、测试、运行等全流程提供安全规范及防护能力
CodeArts控制台权限说明 如果您需要为企业中的员工设置不同的访问权限,以达到不同员工之间的权限隔离,您可以使用统一身份认证服务(Identity and Access Management,简称IAM)进行精细的权限管理。该服务提供用户身份认证、权限分配、访问控制等功能,可以帮助您安全的控制资源的访问
持续部署 持续交付与持续部署 每个团队都应该根据自己的需求做出选择。我们不应该关注形式,而应该关注结果:部署应该是无风险、按需进行的一键式操作。 持续交付 持续交付(CD) 是指,所有开发人员都在主干上进行小批量工作,或者在短时间存在的特性分支上工作,并且定期向主干合并,同时始终让主干保持可发布状态
CodeArts套餐概述 套餐说明 CodeArts采用包年/包月计费模式,提供体验版、基础版、专业版、企业版四种套餐,以满足不同规模用户的使用需求。 套餐中包含需求管理、代码托管、流水线、代码检查、编译构建、部署、测试计划、制品仓库、软件建模服务资源,不同版本套餐中,各服务提供的功能特性及资源规格略有不同
CodeArts套餐规格特性差异 概述 CodeArts套餐分为:体验版、基础版、专业版、企业版。 套餐中均包含需求管理、代码托管、流水线、代码检查、编译构建、部署、测试计划、制品仓库、软件建模服务资源;不同版本套餐中,各服务提供的功能特性及资源规格略有不同。 需求管理 表1 需求管理规格特性差异
基于Pipeline的DevOps核心实践 本文主要讲述华为从自有研发实践到向外输出的服务——CodeArts流水线Pipeline,以及基于Pipeline的DevOps实践。 本文分为以下四部分,前三部分侧重于理论,第四部分将演示在保障质量的情况下,如何让代码提交快速上线。 DevOps
DevOps面面观 本文将从以下几个问题入手,阐述DevOps方方面面的理解,希望通过本文的解读,能对DevOps有更全面更深的认识,并能将DevOps的理论与实践在日常工作中落实。 什么是DevOps? DevOps不只是开发与运维的问题 从大处着眼 从小处下手 通过加大部署/发布频度来撬动整个交付过程
Scrum实践之团队 随着近些年敏捷在行业及企业的推广,越来越多的企业意识到了敏捷所带来的好处,并愿意在敏捷上有所投入,从而越来越多的朋友加入了敏捷从业者行列,愿意学习敏捷知识。 本文内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读,并按实际场景进行参考。 定义和特性说明
Scrum实践之冲刺 定义和特性说明 定义 Scrum框架是目前在敏捷圈内比较流行的,下图展示了Scrum框架实践的全景图。 在Scrum框架中,工作在建议时间长度的迭代中循环做,这个迭代叫做冲刺。 各个冲刺提交的工作内容必须是对用户和客户来说具有确定价值的交付物。通常来说,在每一个冲刺中
持续集成 持续集成概述 持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。 代码检查:提高交付质量 加快代码质量的反馈速度至关重要
效能洞察总览 效能洞察(CodeArts Board)为企业管理者、项目经理、团队Leader、开发者提供面向DevSecOps领域端到端的研发效能度量能力,提供从需求、缺陷、代码、构建、测试、部署、发布到运营等研发各阶段作业数据的分析洞察能力,覆盖交付质量、交付效率、交付能力、交付成本
什么是DevOps DevOps概述 DevOps,即Development and Operations,是一组过程、方法与系统的统称,用于促进软件开发、运维和质量保障部门之间的沟通、协作与整合。DevOps的出现是由于软件行业日益清晰的认识到:为了按时交付软件产品和服务,开发和运维工作必须紧密合作
朴素的DevOps价值观 Nicole Forsgren博士在DOES上的演讲,说过一句话:Architecture matters...Technology doesn't。 最近也遇到越来越多类似的问题,例如:业务方向不明确的情况下,如何拆分微服务? 我们通常的观点是“架构是服务于业务的
DevOps VS 敏捷 当我们面对敏捷和DevOps的时候,总会不可避免的思考下面这些问题: 敏捷是什么?DevOps是什么?两者有什么区别? 持续集成不是XP里面的么,怎么DevOps也有持续集成? 我们团队之前在做敏捷转型,现在又开始DevOps转型,这两者有什么区别? 其实这些问题并没必要太过纠结
用户故事驱动的敏捷开发 敏捷开发现在已经不是新鲜事物了,从各种渠道都可以听到不同的团队实施敏捷的胜果,听的时候觉得很美,可是实际行动时就会发现那都是“别人家”的团队,结合自己的情况就会发现诸多问题。即使是仍然打算一试,也经常会不知如何开始。 因此,我们希望能够找到一个可以遵循的敏捷项目管理模型
我在CodeArts做需求 秉承吃狗粮的文化,CodeArts团队在践行精益敏捷DevOps的同时,也在使用CodeArts工具进行实践落地。 需要说明的是: 本文中提到的实践方式,CodeArts团队在践行,所以具有一定的示范性。 不具备普适性,每个团队都应该根据自己团队的业务特性
敏捷项目管理 组建Scrum团队 本文将以一个示例项目为对象,介绍如何进行敏捷项目管理,示例项目背景如下: 凤凰商城示例项目介绍 【凤凰商城】示例项目是耗时数月所开发的汽车零部件配件电子商城。项目采用 Scrum模式 进行迭代开发,每个迭代周期为“两周”,前3个迭代已经完成“凤凰商城
如何构建高效的持续交付能力 持续集成、持续交付、持续部署、以及持续发布,到底是什么含义? 在回答之前,请大家先思考一个问题 :什么是交付过程最痛苦的事情? 集成的过程,测试的过程,以及部署与发布,都很痛苦,否则不会有敏捷与DevOps的各种方法与实践来解决这些问题,但是这些过程又都非常重要