检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
参数值 服务亲和 选择“集群级别”。 负载均衡器 选择“共享型 > 自动创建”。 实例名称:输入“phoenix”。 弹性公网IP:选择“自动创建”。 说明: 如果账号下已有负载均衡器,可选择“共享型 > 使用已有”,并选择已存在的负载均衡器名称。 端口配置 容器端口:80 服务端口:5000
如果实例状态异常,请参考工作负载异常排查处理。 表6 配置访问方式 配置项 配置建议 Service名称 输入“web-demo”。 访问类型 选择“负载均衡”。 服务亲和 选择“集群级别”。 负载均衡器 选择“共享型 > 自动创建”。 实例名称:输入“web-demo-test”。 弹性公网:选择“自动创建”。 端口配置
较复杂。因此使用微服务,第一步是要构建一个一体化的DevOps平台。DevOps包含了持续集成与持续发布、服务依赖关系管理、服务的发现与负载均衡,以及集中化监控管理,这些都是微服务生态系统所必不可少的工具和实践。 近几年火热的容器技术也被誉为是DevOps的天作之合,它的出现使D
的做到。每一丝的赘肉都会影响身体执行的速度,所以需要锻炼来消除。如何消除持续交付过程中的赘肉?和肌肉锻炼燃烧脂肪一样,痛苦的事情需要反复做,做十次一百次上千次,反复打磨,持续优化。 工程过程是需要高效、准确并且高度保持幂等性的。也就是说,执行一次的结果,与执行一百次的结果应该是一
本文的核心可以总结成一句话:Develop on Cadence, Release on Demand。 按普遍的理解,开发是技术域的事,按需发布是业务域的。本文就分别从这两个领域来简单论述持续交付流水线。 技术域 “客户并不一定需要每一个green build,PM/发布经理按业务需求可选择任意一个,在任何时
最终,持续交付归结为一句话,痛苦的事情反复做。 下图所示的持续交付的原则中,红体字描述的,是最与技术无关的一个实践,却也是最重要的核心理念:提前并频繁的做让人感到痛苦的事。 小结 在开始行动之前,首先应思考需要解决的是什么问题,而不是去问应该采纳何种方式。 不应去问持续集成应该怎么做,TDD应该怎么做。那些都是
也有问题,测试环境部署时间比较长,测试人员在α、β生产各个节点上面做部署,然后做验证,使得部署耗费了很多时间。 下面让我们再看看测试,测试最重要的是要做什么。这里有两个关键的焦点: 第一点,测试就是一个质量活动,做测试就是要保证质量。 第二点,业务价值。测试要围绕业务价值去做,而
敏捷在运维侧的延伸”这一说法也不无道理。只是,敏捷与DevOps,都已经不再是原来的那个敏捷和DevOps了;世界变化太快,问题域发生了变化,解决方案域自然也要随之变化。 敏捷的好处是,有一个敏捷宣言,宣告其诞生。敏捷的缺点,也许也是因为有敏捷宣言。敏捷宣言并不应该被拿来约束和限
讨论工程方法和企业能力。但是现在,在交付方式逐步从单体软件向云上迁移的过程中,大家开始意识到继续在自己的研发环境做基于本地化的私有化工具链已经落伍。于是提出新的要求,做新的全云化的DevOps工具链,本文将讲述对此理念进行的实施。 本文主要分为以下五个部分: 首先要检查自己的DevOps状况。
《科技想要什么》一书中,将科技比作生物。生物是在不断进化,伴随着科技生物的进化,科技生物的研发方法也在不断的进化。华为公司在过去三十年,从小型做硬件、做CT通信产品的公司,成为跨ICT公司,研发理念和思想上也在不断变化。经历了初步的CMM持续交付、持续集成到敏捷、DevOps,直到最新的
线以及各种周边配合,涉及的团队非常复杂。基于时代背景来看,核心网络产品要交付出来,在以前经常需要一年多以上,基本是一年一个版本,半年的时间做线上验证,包括到客户的机房验证,那个时候升级都需要选访问量最低的时候进行半夜断网升级。 怎么保证迭代的速度加快,迭代的质量逐步变得更好呢?后
期望承担项目质量控制的职责。然而在传统项目中这点很难做到,因为测试既不能控制代码如何编写,也不能控制开发人员测试他们的代码,但所有的质量把控却都被希望能压缩在开发之后的测试阶段圆满完成。 在敏捷项目中,测试人员不再坐在那里等待工作的降临,而是主动寻找在整个开发周期中都贡献价值的方
的投入(小时/人天等)。但我们一般不使用直接的小时或人天等时间单位来表示这个值,而是使用斐波纳奇数列中的数值来标识不同特性的相对大小,这样做的好处是我们可以屏蔽直接使用时间单位所造成的主观差异,更快更准确的进行评估(因为在没有进行实际开发之前是很难直接估算时间,但是不同特性的相对