检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
这个话题注定讨论不清，也注定会有不同的意见。本文也仅从方法论和实践的角度，为开发者简单论述敏捷与DevOps。希望每位读者都会从本文中得到自己的理解与启发 ，帮助大家在敏捷与DevOps这两条路上走的更远。 先说本文的观点： ▪ 敏捷与DevOps初衷、目的是为了解决问题，而不是为了树碑立牌，更不是为了占领地盘。
多是业务决策，不要把技术与业务决策混为一谈。部署与发布的解耦过程，也就是前面讲到的技术与业务的解耦过程。 部署：在特定的环境上安装指定版本的软件。部署可能与某个特性的发布有关，也可能无关。 发布：把一个/组特性提供给（部分或全部）客户的过程。 要实现部署与发布解耦，需要代码和环境
参考代码托管约束与限制。 流水线 参考流水线约束与限制。 代码检查 参考代码检查约束与限制。 编译构建 参考编译构建约束与限制。 制品仓库 参考制品仓库约束与限制。 部署 参考部署约束与限制。 测试计划 参考测试计划约束与限制。 性能测试 参考性能测试约束与限制。 漏洞管理服务 参考漏洞管理服务使用约束。
持续部署与发布 持续部署 持续交付与持续部署概念解读 持续交付流水线 基于Pipeline的DevOps核心实践 如何构建高效的持续交付能力 交付在云端-全云DevOps实践
持续规划与设计 什么是敏捷 影响地图 用户故事地图 用户故事驱动的敏捷开发 我在CodeArts做需求 Scrum的22个基础知识点 Scrum实践之团队 Scrum实践之冲刺 敏捷项目管理 敏捷实践之物理看板与电子看板
持续开发与集成 软件版本管理 持续集成
持续测试与反馈 敏捷测试 DevOps敏捷测试之道
户自定义模板，提供25+原子步骤组装成部署任务。 支持与流水线集成打通部署流水线 在流水线能关联部署任务，并可以通过流水线关联构建、代码检查、测试等服务，实现端到端的Devops流程。 接下来以用户使用的云服务器资源分类为区别进行讲解。 ECS部署 弹性云主机提供了自助便捷的服务器获取方式，特别适合自动化部署场景。
华为云CodeArts提供专业的用例管理与缺陷跟踪管理工具。 通过测试计划服务的测试管理功能，可以清晰的查看需求树中每一个需求所关联的测试用例。 测试用例中提供用例的基本信息编辑与查询，用例执行结果、缺陷列表、操作历史等内容的查询。 可直接在用例执行后，在用例界面新建缺陷或关联缺陷，实现缺陷与用例、用例与需求、需求与缺陷的闭环跟踪。
这里的容器镜像项目意为“使用Docker等容器镜像的项目”，具体实现步骤与“传统项目”类似。只需在编译构建过程中开通容器镜像服务SWR并加入步骤“制作镜像并推送到SWR仓库”步骤，构建成功后，镜像即可上传至SWR。 容器镜像项目与传统项目的区别，在代码仓库中即有体现，以使用Docker的项目为例，
如何使用各种开发工具和平台，借助如任务跟踪、分支计划、持续集成、持续发布、自动化测试等工具让开发过程变得更加高效？ 用户故事的需求整理方式与传统需求的整理方式有很大的不同。传统软件开发中，我们依赖用户需求、技术需求、规格说明书等工具，试图使用规范的文档来解决需求收集和传递的问题。
敏捷实践之物理看板与电子看板 选择物理看板还是电子看板 敏捷项目最终的成功还是失败，与使用物理看板还是电子看板没有绝对的因果关系。换个方式说，选择哪种看板不是对与错，而是适合与不适合。所以，要思考的是哪种方式更适合你的团队。 物理看板的优势和劣势 优势 成本低：几乎不需要成本，办
对于需求描述中的不清晰内容与PO进行沟通、澄清。 13 冲刺回顾会议的作用 冲刺回顾会议（Sprint Retrospective）为团队提供了总结和改进的方式，在每个冲刺结束后大家一起总结在这个冲刺中的改进和不足，并一同商讨应对措施，进行持续改进。 14 Scrum中的冲刺和迭代有什么区别？ 迭代
有的产品，它还活着，却已经死了；有的产品，还没发布，就已经死了。太多的产品失败的案例，源于方向性错误，基于错误的假设，功能与业务目标/价值之间缺乏必然的关联与一致性，在做的事与期望的目标南辕北辙。 影响地图试图通过结构化、可视化、协作化的方式来从源头解决上述问题。 影响地图是一门战略规划技术，通过清晰的沟
的是一种务实的做法，当收集到足够一次迭代开发的需求时即向下一个步骤前进，尽量缩短前置时间的浪费，然后将"分析、设计、开发与测试"形成一个开发步骤，减少了步骤与步骤之间的衔接时间。 首次发布：敏捷开发采用迭代的开发方式，每个循环都会有一个潜在可发布版本用来展示开发成果，这种展示给了
新的迭代计划也在不断的演进，但依然是经济并且现实的只规划最近的1-2个迭代。在此过程中，通过不断的交付价值与沟通反馈，建立团队内部彼此之间以及团队与客户之间的沟通、信任与信心。 在CodeArts中，计划是分为两级的，第一级是大的发布计划，以月度、季度、年度为粒度，我们称之为路
图： 第三行所包含的内容就是“大家在电子邮件系统所要做的事情”，包括：注册、配置信息、发布、下单、支付等。 第二行对这些事情进行了分组。 与一般用户故事地图不同的是，这张图当中增加了第一行的角色划分，以使整个流程更加清晰明了。 黄色的便签的第一行包含了最小化的用户故事，如：“蛋糕
续转到云上去了，一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。 在2011年到2014年，华为全面把工具向平台化、服务化方向转型，这个时候一些商业模式才发生了根本性的变化
第六是生产在线测试。如果是金融系统，涉及到钱，应该有相应的管理成本配置，否则怎么保障线上的系统是正确的？线上系统势必要做测试，任何系统的模拟数据都无法与真实数据相比，哪怕在真实系统只花一分钱，模拟交易量都不能替代它。应该用管理成本设置一个账户，在里面实际的实现一些线上的支付，只有这样才能保证
通常而言，软件开发起始于需求收集与分析，所以本文从需求谈起。 传统的瀑布研发模式基于三个假设： 用户准确的知道自己想要什么。 开发人员能够完全理解用户在说什么。 需求在研发过程中不会发生变化。 但事实上这三个前提假设都不存在，需求沟通之后做出来的产品，往往与需求大相径庭。 我们以用户故事来描述需求
长按/截图保存，微信识别二维码
或者关注公众号“华为云”
