关于devops:CODING-DevOps-线下沙龙回顾一DevOps-代码质量实战

11 月 22 日,由 CODING 主办的 DevOps 技术沙龙系列「品质」专场在上海圆满结束。在流动现场,四位来自腾讯等知名企业的技术大咖们分享了研发品质与效力的实战经验,与观众们独特探讨如何采取有效伎俩以保障和进步软件品质。 本期沙龙回顾为大家带来的,是来自腾讯云 CODING 布道师杨周的议题——《DevOps 代码品质实战》。 问题:人越来越多,代码越来越乱 随着团队成员增多,每个人在缩进、换行、空格以及大小写方面有不同的习惯,导致代码越来越乱。代码格调问题尚且不致命,更重大的是这些问题: Hard code:在代码中书写各种环境配置、链接、密钥,导致平安危险魔法数字(Magic Number):难以了解和保护代码行数过多:难以保护,违反面向对象的 SOLID 准则不少业界大厂颁布了代码标准,举荐大家间接采纳,因为本人创造标准往往不够全面,很难服众。 代码标准不只是缩进换行问题,通过强制束缚圈复杂度、文件行数和办法行数,可促使大家依照面向对象的形式设计。 如何强制执行代码标准有了代码标准,但怎么落地?是很多团队面临的问题。Lint 程序用来查看代码标准,各个语言(比方 Kotlin、Java、PHP)都有本人的标准和 Lint。 主动查看代码标准有三个机会: IDE:最实时不便的,但须要所有人进行配置、某些 IDE 可能不反对Git commit Hook:提交时,会调用命令行工具强制查看,长处是十分及时,然而存在可被删除的危险服务端:在 Git push 之后,在服务端进行查看,很牢靠,但毛病是不够实时因而,倡议同时应用这三种形式。 在代码查看之后,如何解决?老我的项目有成千上万处不标准,很显然不能一次清理洁净,让所有人停下老我的项目去清理老代码并不事实,而且一次改变太多文件的危险也很高。因而倡议应用增量查看,尤其是 Java 增量查看计划比较复杂,详情可辨认下图二维码浏览 CODING 文档。 服务端查看:倡议应用继续集成(继续一直地把代码集成到骨干,实现品质内建)。流程为:锁定 Git 骨干,所有人开发性能拉取小分支,小分支提交后触发继续集成进行代码标准查看,通过之后再告诉共事进行代码评审,通过这套流程来进步代码品质。CODING 继续集成兼容 Jenkins,图形化界面易上手,如果我的项目曾经在用 Jenkins 可平滑迁徙。 代码整洁了,但后果正确吗?很多我的项目到最初面临的窘境——没有人敢改老代码。比方开发人员会把已有函数如get() 复制一份再批改,变成了 get1()、get2(),这种做法导致我的项目逐步溃烂。本源在于没有人晓得批改老代码会不会导致其余中央调用出错。 在开发和测试拆散的团队架构中,一个负责任的开发者在写了代码之后要自测,而后提测给测试人员。然而前期大家逐步会变得不耐烦,从自测 10 种状况到 5 种状况,再到只测一种,最初到齐全不自测间接提测,所有的压力都缓缓转移到了测试人员身上。负责任的开发逐步变成不负责任的开发,问题还是出在机制上。 国外十几年前就开始这个计划:测试人员转岗学编程开发,仅保留少部分的人工测试。开发人员本人写测试代码,测试覆盖率不达标(比方 80%)则禁止合并。 开发人员如何对本人的代码有信念?不是靠聪明才智,因为人总会百密一疏,即便顶尖的程序员也可能会犯最高级的问题,因而本人写测试代码才是最牢靠的计划,测试代码笼罩了多种边界状况,即便其他人来改写代码也无需放心挂掉。 最晚什么时候开始自动化测试?自动化测试很好,然而也面临窘境:业务太忙,没有工夫写测试代码。 从集体职业倒退的角度,把手动操作 Postman 自测的工夫用来写自动化测试代码,这样一来,本人的程度失去了进步,后续改代码的时候重测工夫也失去了节俭,不再是始终堆业务代码,难以成长。 以前中国的大公司我的项目品质广泛非常蹩脚,因为前 20 年是 2C 的红利期,大家在疾速抢占市场,但当初到了守地盘的时候,这两年大公司开始器重代码品质问题,倡议大家为这个时机早做筹备。 ...

December 7, 2020 · 1 min · jiezi

关于devops:CODING-荣获2020-DevOps-领域年度极具影响力产品奖项

11 月 27、28 日,第十五届 2020 GOPS 寰球运维大会在上海隆重举行,只管大会期间正值疫情非凡期间,观众仍旧激情不减。在本届大会上,来自腾讯、阿里、中国移动、京东的行业内顶尖专家面向千人观众流传先进技术思维和理念,分享业内最佳实际。作为腾讯云旗下 DevOps 一站式研发治理平台提供商,CODING 受邀参加了本届大会。在大会的第一天,主会场举办了 2020 IT 技术领导力年度颁奖盛典。经强烈角逐后,CODING 在泛滥参选厂商中怀才不遇,荣获「2020 DevOps 畛域年度极具影响力产品」奖项。 本次「2020 IT 技术领导力年度评比」旨在通过对 IT 行业从业者、产品、企业、服务商的横向评比及表彰,激励 IT 行业企业继续发展技术创新、激励 IT 人才勇于开拓的无益摸索,冀望 IT 行业企业和从业人员可能不忘初心,砥砺前行,持续引领 IT 行业技术倒退、再创佳绩。其中「2020 年度极具影响力」奖项评比出 6 个为行业提供诸多优良教训,发明杰出的 IT 产品,帮忙更多企业和 IT 从业人员,进一步促成行业的倒退。CODING 获此殊荣,代表着宽广用户对 CODING 产品和服务的必定。将来,CODING 也将持续致力于一站式 DevOps 平台的开发,让客户享受到性能更弱小,笼罩更全面,上手更容易的端到端 DevOps 服务。 颁奖过后,CODING DevOps 布道师杨周承受了 CCTV《态度》栏目组专访,分享获奖感言并简要介绍 CODING 产品和 CODING 的愿景。 CODING DevOps 是腾讯云产品部重点反对的 DevOps 产品,提供从需要到设计、开发、构建、测试、公布和部署的全流程协同及研发工具撑持。目前 CODING 已有超过 200 万的开发者用户,服务超过 50000 家企业,其中包含中国银联,深圳农商行,中体彩,PICC,南方电网等出名客户。杨周示意,CODING 今后会再接再厉,一方面把 CODING 的产品做的越来越成熟、满足客户更多的需要;另一方面,依据客户的反馈并联合 CODING 的策略,做出 CODING 本人的特色。在某些畛域做出亮点和劣势,争取成为国内 DevOps 产品的头部企业。 ...

December 7, 2020 · 1 min · jiezi

关于devops:CODING-DevOps-产品认证学习计划正式启动

为了帮忙宽广软件研发团队管理者、集体开发者等 IT 行业从业者把握 DevOps 及麻利开发的基本知识和概念,CODING 与腾讯云大学现携手推出 CODING DevOps 产品认证学习打算! CODING DevOps 产品认证学习打算将通过在线学习与入手实际相结合的形式,由浅入深帮忙学员精准了解 DevOps 及麻利开发的核心思想,疾速具备 DevOps 研发工具应用能力,同时领导团队更好地把握落地工具,实际麻利开发治理及 DevOps 研发工作流,让集体与团队能相辅相成,全方位晋升研发效力。 对于 CODING DevOps 产品认证面向人群: 企业软件研发团队中的管理者、开发者、项目经理等岗位,高校计算机相关学生群体学习指标: 把握麻利开发及 DevOps 研发治理的基础知识,学会将 CODING DevOps 工具利用到开发管理工作中认证价值: 取得腾讯云 CODING DevOps 认证证书,晋升集体及团队的研发治理能力开发者若参加腾讯云阶梯式岗位技术认证培训并通过认证考试,简历可录入腾讯云人才库,供腾讯云及单干企业择优录用 CODING DevOps 学习门路每个学习课程都联合理念 + 实际的教学方式,按阶段循序渐进,让学员们逐渐把握 DevOps 相干常识,重点课程如: DevOps 的核心理念及价值麻利开发 Scrum 框架下重点工具(如:kanban 等)的应用实际Git 根本工作流实际继续集成、继续交付和部署的理念及实际DevOps 继续反馈与改良的机制建设腾讯云专属在线学习门路课 认证流程1、在线学习: 通过腾讯云专属产品在线课程,疾速把握基础知识 2、入手实际: 联合在线课程与实际操作,取得场景化技能 3、在线考试: 通过考试后,可在腾讯云账号【集体核心】-【产品认证】处查看证书,证书自颁布之日起 2 年内无效 认证证书 返回 CODING DevOps 产品认证开始学习吧! 同时 CODING 为了帮忙各位学员更好地摸索各项产品能力,体验高效的 DevOps 开发流水线,让开发团队升高应用全流程 DevOps 工具的门槛,还推出了 「DevOps Workshop 学习营地」。 ...

December 7, 2020 · 1 min · jiezi

关于devops:你知道吗Artifactory还可以管理SUSELinux系统的依赖

提到SUSE零碎大家应该都用过,尤其是在金融畛域。大部分都是应用SUSELinux零碎。当SUSE零碎短少组件时,装置也是相当的麻烦。 大家都晓得RedHat和Centos零碎应用yum治理软件包装置,Ubuntu应用apt,yum治理的是rpm格局的包,而apt是deb格局,这两种形式装置软件时会自动检索依赖,进行递归软件包的装置,解决咱们装置时短少依赖的问题,大大晋升咱们在零碎上装置软件的效率。 而SUSE也是有本人的包管理工具的,那就是zypper,(zypper的应用办法这里不过多介绍了,有趣味的能够去看SUSE官网的wiki介绍https://cn.opensuse.org/Zypper)与此同时zypper的治理的安装包也是rpm格局,而Artifactory是反对rpm包治理的。所以咱们能够应用rpm仓库来进行zyyper源的配置。 创立RPM仓库治理 首先创立一个rpm仓库地址能够填写http://download.opensuse.org/update/,如下图 增加zyyper源 而后应用zypper命令增加源 zypper ar http://artifactory_url/artifactory/zypper-opensuse-remote/leap/15.2/oss SUSE-15.2-oss zypper ar http://artifactory_url/artifactory/zypper-opensuse-remote/leap/15.2/non-oss SUSE-15.2-non-oss Adding repository ' SUSE-15.2-oss '……………………………………………….[done] Repository ' SUSE-15.2-oss ' successfully added URI         : Enabled     : Yes GPG Check   : Yes Autorefresh : No Priority    : 99 (default priority) 装置软件 zypper in MozillaFirefox

December 4, 2020 · 1 min · jiezi

关于devops:高效交付的秘诀开源-DevOps-运维平台合集

随着云服务、微服务和容器等理念的逐渐倒退,机器和利用越来越多,服务越来越微,利用运行根底环境越来多样化,怎么的架构和技术计划才更适宜越来越宏大繁冗的运维需要呢? 越来越多的团队抉择 Devops 来进步他们开发运维的效率,缩小不必要的开发工夫,通过各种自动化部署来间接地晋升研发品质。 本周我的项目精选所举荐的就是 Gitee 上优质的开源 DevOps 运维平台。 1.kjyw我的项目作者: aqztcom 开源许可协定: MIT 我的项目地址:https://gitee.com/aqztcom/kjyw 简略、高效、快捷的运维脚本工具库。我的项目基于shell开发,收集各类运维常用工具脚本,实现疾速装置nginx、mysql、php、redis、nagios、运维常常应用的脚本等等。 2.Jpom我的项目作者: 码之科技工作室 开源许可协定: MIT 我的项目地址:https://gitee.com/keepbx/Jpom 一款简而轻的低侵入式在线构建、主动部署、日常运维、我的项目监控软件。 3.wecube-platform我的项目作者: WeBank 开源许可协定: Apache-2.0 我的项目地址:https://gitee.com/WeBank/wecube-platform WeCube是一套开源的,一站式IT架构治理和运维管理工具,次要用于简化分布式架构IT治理,并能够通过插件进行性能扩大。 4.bk-ci我的项目作者: 蓝鲸智云 开源许可协定: MIT 我的项目地址:https://gitee.com/Tencent-BlueKing/bk-ci bk-ci是一个收费并开源的CI服务,可助你自动化构建-测试-公布工作流,继续、疾速、高质量地交付你的产品。 5.gokins我的项目作者: UchihaRuis 开源许可协定: Apache-2.0 我的项目地址:https://gitee.com/mgr9525/gokins Gokins 是一个由 Go 语言和 Vue 编写的款轻量级、可能继续集成和继续交付的工具,能够通过其网页界面轻松设置和配置,简直没有难度。绝不收集任何用户、服务器信息,是一个独立平安的服务。 6.ledge我的项目作者: phodal 开源许可协定: MPL-2.0 我的项目地址:https://gitee.com/phodal/ledge Ledge —— DevOps、研发效力常识和工具平台,是作者基于在 ThoughtWorks 进行的一系列 DevOps 实际、麻利实际、软件开发与测试、精益实际提炼进去的常识体系。它蕴含了各种最佳实际、操作手册、准则与模式、操作手册、度量、工具,用于帮忙您的企业在数字化时代更好地后退,还有 DevOps 转型。 更多优质 DevOps 运维平台我的项目,点击前面的链接即可查看:https://gitee.com/explore/devops ...

December 3, 2020 · 1 min · jiezi

关于devops:ONES-收购知名协作工具-Tower

ONES 发表收买出名合作工具 Tower ,进一步拓展其业余研发治理业务幅员。收买后,ONES 将提供笼罩小团队到中大型企业的研发治理解决方案。 Tower 专一合作效率晋升,取得近千万用户青睐Tower 合作工具于 2012 年正式上线,通过 8 年的倒退,Tower 以优质的用户体验和产品口碑博得了用户必定,在行业和社区有极大影响力。在 Tower,团队能够轻松地创立我的项目并指派工作,通过多种可视化视图全面跟踪和治理我的项目进度,保障我的项目有序推动。 目前,Tower 曾经为近百万团队提供合作工具,在互联网、教育、批发等畛域均造成了成熟解决方案,如 Bilibili、YY 欢聚时代等多家头部企业均应用 Tower 实现了轻量高效的团队合作。 ONES 深耕企业级研发治理,中大型企业信赖之选正如 Tower 多年保持的「让每个人走的更快,让团队走的更远」的团队合作理念,ONES 也始终以「助力企业更好更快公布产品」为使命,深耕中大型企业业余研发治理畛域。ONES 先后公布了我的项目进度治理、知识库治理、测试用例治理等8款企业级产品,贯通研发全流程,晋升企业合作效率。 作为面向中大型企业的专业级研发管理工具,ONES 通过了 CMMI、ISO、可信云等多个业余资质认证,为小米、浪潮软件、招商基金等泛滥中大型企业提供安全可靠的研发治理解决方案及业余服务,取得了市场的充沛认可。 ONES + Tower,陪伴企业初创到胜利据 Gartner 数据统计,2019 年寰球面向软件研发畛域的项目管理软件市场规模年复合增长率达到了 9 %。在海内的研发治理畛域,Jira 等产品也曾经充沛验证了研发治理对企业的重要价值。Jira 所属公司 Atlassian(NASDAQ: TEAM) 在 2017 年以 4.25 亿美元收买轻量级项目管理工具 Trello,是其全面笼罩小团队到中大型企业的重要里程碑。 Trello 的退出为 Atlassian 带来了更多的用户群,同时吸引了企业客户增购产品套件,促成整体利润的踊跃增长。依据 Atlassian 公布的财报显示,Trello 在 2018 年为 Atlassian 带来 12,789 位新增客户,2019年又带来了 2,500 位新增客户,整体支出上涨 33%。 正如「Jira + Trello」,「ONES + Tower」的强强联合,也将为客户提供更灵便更丰盛的解决方案。不同阶段、不同规模的企业齐全能够依据本身工作形式来自由选择研发治理产品。 ...

December 3, 2020 · 1 min · jiezi

关于devops:2020中国DevOps社区峰会北京站知识与技术共舞数字化与敏捷齐飞

作者:DevOps社区Meetup起源:微信公众号 层林浸染,夕阳的斜晖已缓缓把北京的枫叶染红,寒风扫落叶的季节到了。很多人会说这个冬天很冷,咱们须要更多和煦。是的,所以咱们来了——2020中国DevOps社区峰会(北京站)。 纵寒风凛然,冬日里不变的仍然是咱们对DevOps执着的激情,理念与技术傍身你就是那无畏经济寒冬的无敌英雄。无论你是麻利内功雄厚,还是有DevOps工具链里的宝刀屠龙,或是曾经取得数字化转型的独门绝学,都不容错过这场DevOps盛会 !常识与技术共舞,数字化与麻利齐飞,12月19日,中国DevOps 社区峰会北京站大会议程继续更新,咱们期待看到您的身影。 【峰会】:2020中国DevOps社区峰会 · 北京站 【地点】:北京潘家园创享空间 【工夫】:12月19日 主会场01 《华为云DevCloud如何构建高效可信的继续交付能力》 姚冬 华为云DevCloud 首席技术布道师 中国DevOps社区外围组织者 【讲师介绍】华为云DevCloud首席技术布道师,IDCF社区联结发起人,《麻利无敌之DevOps时代》,《DevOps业务视角》,《麻利开发常识体系》《DevOps最佳实际》等书作(译)者。 【演讲概述】云原生时代,对研发与交付提出了更高的要求。继续集成,继续测试,继续交付,与继续部署,诸多实际背地的理念,在理论企业规模化利用中,在可信与品质的要求下,应该如何联合与取舍?本次分享将为你道来华为云DevCloud如何构建高效可信的继续交付能力。 02 《DevOps金融实际》 魏鹏 资深架构师&效力产品线负责人 中国DevOps社区组织者 【讲师介绍】普元数字化金融研究院 、资深架构师&效力产品线负责人、中国DevOps社区组织者,长期致力于金融科技治理、研发效力、品质治理等畛域的实际,领有多年金融行业IT布局、研发、运维的建设教训,先后参加了中国银行、建设银行、民生银行、渤海银行、邮储银行、九江银行、华兴银行、华润银行、天津银行、鄂尔多斯银行的基础架构、公有云、DevOps、IT布局、科技治理等体系的建设项目。 【演讲概述】金融企业翻新须要面临麻利转型,但作为金融翻新外围动能的科技部门却面临着诸多难题,如何利用ToC精益经营和5S方法论来解决这些痛点?如何落地DevOps的全流程?另外金融行业的麻利组织转型在各家银行有何实际?业务部门和科技部门责权利如何无效流动? 数字化转型专场01 《传统企业数字化转型门路》 付晓岩 建信金融科技公司团队副总经理 资深企业级业务架构师 【讲师介绍】建信金融科技公司团队副总经理,资深企业级业务架构师,《企业级业务架构设计:方法论与实际》和《银行数字化转型》两书作者,建行新一代外围业务零碎转型工程业务架构师团队核心成员,长期负责企业级业务架构设计与管控工作。国家工程实验室金融大数据安全与利用钻研核心高级专家,腾讯云最具价值专家。 【演讲概述】通过本次分享,介绍传统企业数字化转型门路,强调架构转型的重要性,介绍业务架构设计办法和理念,比照剖析自上而下的企业架构办法和自下而上的中台办法,分享转型案例和实际心得,与观众一起摸索数字化转型办法。 02 《数字化软件生产线赋能“普惠科技》 喻吉林 普元数字化金融研究院院长 【讲师介绍】普元数字化金融研究院院长,期致力于SOA架构、微服务架构、业务中台架构的设计与实际,领有多年金融行业IT布局、架构设计与研发教训。先后参加了国家电网、工商银行、远光软件、国家开发银行、中国证券结算上海分公司、兴业银行、广东省农村信用联社等公司的业务流程平台、Java技术平台、利用云平台、对立利用平台、综合利用开发平台、业务中台等平台建设项目。 【演讲概述】咱们为企业实现IT科技方面的普惠,使得IT建设更亲民,人人都能用IT,人人都能参加IT的建设。在这个过程中DevOps充当数字化生产线,如何通过DevOps建设普惠业务,赋能IT团队?同时与之匹配的生产工具:低代码开发平台该如何建设? 03 《文言业务中台》 王健 ThoughtWorks首席咨询师 【讲师介绍】“文言中台”系列文章作者,极客工夫《说透中台》专栏作者。始终放弃着对技术的酷爱,热衷于技术分享。目前专一在企业平台化转型,企业架构治理,中台战略规划,微服务架构与施行,大型遗留零碎服务化革新等实际在不同行业中的推广与落地。 【演讲概述】通过实际发现,对于业务中台的布局和设计十分艰难,甚至是对于业务中台的定义和定位通过几年的工夫并没有变得清晰,反而更加的含糊和混沌。本次分享,联合本身多年的中台钻研和实践经验,从业务中台的乱象到业务中台实质的探讨,从整顿整合行业最佳实际到分享本身亲自的趟坑教训,一起分享和探讨业务中台的方方面面。 04 《数字平台驱动企业数智化转型》 孙杰 中油瑞飞 数字化能力核心首席架构师 数字化转型专家 【讲师介绍】中油瑞飞 数字化能力核心首席架构师,数字化转型专家,业内资深云计算专家,《云原生基础架构》译者,《企业公有云建设指南》作者。 【演讲概述】数字平台是企业数字化转型的外围,数字平台包含基础设施平台、数字技术底台、中台和数字化经营治理及生态服务,对内撑持麻利生产、动静保护、精益治理、实时监控和智能决策;对外改善用户体验、撑持近程保护、构建产业生态等。平台赋能业务实现价值增长,减速企业的数智化转型! 05 《浅析数字化转型与产业互联网》 史海峰 贝壳金服 小微企业生态CTO 【讲师介绍】贝壳金服 小微企业生态CTO,曾在神州数码、亚信联创长期从事电信行业业务撑持系统集成工作,参加中国移动、中国联通多个我的项目,具备丰盛的大型业务零碎研发施行教训。曾在当当负责总体架构布局、技术规范制订和技术预研推广,长于把握简单业务需要,提出创新性解决方案,参加多个重点项目的方案设计,在我的项目中对系统架构进行继续革新优化。负责技术委员会组织管理工作,挖掘最佳实际、推动技术革新、开源产品,组织内外部技术交换。曾负责饿了么技术创新部产品研发团队,实现多个创新性业务我的项目及技术产品。当初贝壳金服负责小微企业生态金融服务产品布局、技术团队治理、零碎建设。曾多次加入业界技术大会,包含ArchSummit、QCon、SACC、TOP100、SDCC、GITC、MPD、GIAC、CSDI等,任讲师及出品人,不定期更新自媒体微信公众号“IT民工闲话”。 【演讲概述】从信息化到数字化,从产品化到智能化,从互联网+到产业互联网,这些概念的实质是什么?为什么说企业数字化转型与新基建国家策略一脉相承?为什么说互联网的下半场是产业互联网?数字化转型和产业互联网有哪些难点?须要怎么的方法论? 精益麻利专场01 《需要合作的三个锤子》 王宇 ...

December 3, 2020 · 1 min · jiezi

关于devops:2020年值得收藏的50多种Kubernetes工具

在过来几年,Kubernetes 在容器编排市场独占鳌头。自 2016 年以来,Docker Swarm 就退出了次要竞争者的行列,并且像 AWS 一样承诺对 K8s 进行反对和集成,换句话说,它抵赖了失败。 目前,由 Kubernetes 作为首选的容器解决方案已迅速遍及,因而,这里列出了所有 K8s 加强工具的综合清单,以进一步晋升您的开发工作。 Kubernetes 集群部署Kubespray Kubespray 为 Kubernetes 的部署和配置提供了一组 Ansible 角色。Kubespray 反对 AWS、GCE、Azure、OpenStack 或裸机 IaaS 平台。Kubespray 是具备凋谢开发模型的开源我的项目。因为无需应用其余工具进行配置和编排,因而对理解 Ansible 的人来说,该工具是一个不错的抉择。Kubespray 基于 kubeadm 开发。 地址:https://github.com/kubernetes...价格:收费Minikube Minikube 容许你在本地装置和试用 Kubernetes。该工具是摸索 Kubernetes 的一个很好的终点,它能够让你在笔记本电脑上的虚拟机(VM)中轻松启动单节点 Kubernetes 集群。Minikube 在 Windows、Linux 和 OSX 上可用。只需 5 分钟,你就能摸索 Kubernetes 的次要性能。只需一个命令即可间接启动 Minikube 控制台。 地址:https://github.com/kubernetes...价格:收费Kubeadm 自 1.4 版本以来,Kubeadm 成为 Kubernetes 的发行工具。该工具是在已有基础架构上搭建 Kubernetes 集群的最佳实际。然而,Kubeadm 无奈为您提供基础架构。它的次要劣势是可能在任何中央部署最小的可用 Kubernetes 集群。不过,Kubeadm 不蕴含其余附加组件和网络组件,因而你须要手动装置这些组件(或应用其余工具装置)。 ...

November 30, 2020 · 5 min · jiezi

关于devops:揭秘1111监控排障利器-京东高稳定日志服务深度解析

云妹导读: 往年11.11期间,京东11.11寰球酷爱季累计下单金额超2715亿元,冲破历史最高下单金额的同时,京东智联云拜访带宽较往年618同比晋升20%,超高弹性应答京东11.11海量并发需要,拜访峰值QPS较往年618同比晋升258%;京东智联云CDN总峰值带宽是往年618峰值的116%。 简直所有业务都须要通过京东智联云所提供的负载平衡、DNS、CDN 这些零碎,那么从这些零碎所产生的日志中便能挖掘出十分有价值的信息,也能做到从全局和上帝视角对整个零碎的状态和性能进行实时监控。日志服务未然是零碎稳固运行必不可少的一部分,成为DevOps中的标配选项。本次大促中,日志服务零碎的稳固运行,完满实现了大促的保障工作,为大促新纪录提供了松软的保障。本篇文章将介绍大促对日志服务所带来的挑战,以及京东智联云日志服务零碎架构设计。 一、大促对日志服务带来的挑战1,性能方面作为最罕用的排障、剖析工具,日志服务性能的欠缺性有着很重要的影响。在大促的场景下,用户的次要场景需要有: 现场日志查看日志监控实时剖析日志生产2,老本方面数据作为企业最贵重的资产,大促的数据更是外围中的外围。 团体及咱们服务的相干企业一方面冀望数据资产存储越久越好,另一方面又要讲求老本与效益的均衡,这便造成了一种矛盾的景象。 日志服务每天产生以PB计量的数据,造成了一个不可漠视的老本项,如何无效升高其整体老本,是一个最间接的难题。 3,稳定性方面大促作为京东团体全年唯二的最高级别大型流动,对服务的稳定性有着近乎刻薄的要求。服务上一次不稳固的稳定,都会间接导致支出上的损失。日志服务作为团体服务的技术基石,本身服务的稳定性至关重要。 二、京东智联云日志服务解析京东智联云日志服务,作为京东外部一站式DevOps解决方案运维域的重要组件之一,为全团体提供对立日志解决方案。通过为研发、运维、经营提供检索、排障、剖析等性能,满足各业务零碎、经营零碎、中间件、底层服务的需要,助力其施展价值。 1,产品功能完善作为最罕用的排障、剖析工具,日志服务提供了欠缺的产品性能。在确保笼罩各类性能需要的根底上,提供了_智能解析_、_施行剖析_等增强型性能。为撑持「疾速发现问题」-「疾速定位问题」-「疾速解决问题」的外围指标提供了保障。 日志服务的业务性能架构图如下: 2,老本京东智联云日志服务整体架构上实现了存储与计算拆散。可进行针对性的调优。 咱们先来看一下日志服务利用架构示意图: (1)存储存储的应用次要对应利用架构视图的indexer局部。这里次要关注存储相干的两个因素: 存储介质 、 存储内容 。 ①存储介质 业余的团队干业余的事件,抉择业余的存储产品,日志服务层不再干预存储层的优化。 选取准则为: 足够成熟稳固;老本便宜。咱们抉择了对象存储产品。其特色为: 资源弹性伸缩老本低廉高可用性保障安全性兼容规范S3整个产品应用下来十分稳固,实现了存储介质上的「低成本」。 ②存储内容 日志存储计划示意图如下,上面咱们来讨论一下在升高存储内容方面做的工作。 日志数据流传输到服务端后,被indexer重组为bucket及index文件,最终被写入共享存储。 index文件用于减速定位检索的文件,bucket局部用于存储日志原始数据。index及bucket均采纳了压缩的形式进行存储,实现了存储内容上的「低成本」。 (2)计算计算资源的应用次要对应利用架构视图中的query indexer局部。 这一部分性能有: 依照索引计算须要加载的bucket加载bucket根据bucket中的meta定位待处理的block针对block内容进行解压+计算后果聚合通过上述性能能够看到, 日志检索、剖析工作兼具IO密集型及计算密集型特色 ,这部分是须要咱们针对性进行资源优化利用的。 在数据的扫描上,咱们通过多级索引,实现bucket文件的精准定位。 采纳提早加载的形式加载bucket进一步升高IO开销。 计算环节采纳了优先级工作队列+worker池的形式,通过晋升工作的并发度,能够借助更多的计算资源晋升计算速度。通过对计算工作进行评分,给予不同的优先级,正当调度计算资源,实现分级保障。 3,稳定性上云的用户最关怀的问题就是各个根底服务的稳定性。用户是否能够齐全信赖日志服务呢,日志服务是如何保障服务的高可用性的?接下来让咱们一起探讨下日志服务的根本实现及在稳定性上所做的一些工作。 先简略介绍日志服务的组成模式及大促备战流程,这是咱们进行后续探讨前须要理解的背景信息。 上面借助日志服务职责分层示意图,来理解日志服务的组成模式: 采集层: 日志agent,适配云主机,k8s等各类环境,提供日志收集性能;存储层: 底层复用Database及对象存储的能力,实现数据的高可用存储;计算层: 对日志数据进行过滤、转换、统计,反对业务层各个功能模块;业务层: 日志产品层。提供检索、剖析、监控、生产转储等性能。大促备战流程: 其中,咱们需重点辨认如下信息: 辨认重保租户辨认重保零碎用户设定的预申请配额理解以上信息后,咱们开始在多个方面探讨稳定性相干工作。 (1)高可用一套高可用服务的推出,要经验的次要环节如下: 存储层 复用Database及对象存储的能力,间接实现跨AZ高可用、跨region的容灾能力。每个产品都做了大量稳定性相干的工作,这里不再赘述。 计算引擎 ◆  轻量级实时计算服务:自研无状态服务,依照规范的跨AZ、Region部署的准则,能够很轻易地实现高可用及容灾。 ◆  基于大数据引擎的计算服务: ◇  依照业务进行划分,实现资源隔离; ◇  HA+checkpoint,保障作业的复原; ...

November 30, 2020 · 1 min · jiezi

关于devops:揭秘1111监控排障利器-京东高稳定日志服务深度解析

云妹导读: 往年11.11期间,京东11.11寰球酷爱季累计下单金额超2715亿元,冲破历史最高下单金额的同时,京东智联云拜访带宽较往年618同比晋升20%,超高弹性应答京东11.11海量并发需要,拜访峰值QPS较往年618同比晋升258%;京东智联云CDN总峰值带宽是往年618峰值的116%。 简直所有业务都须要通过京东智联云所提供的负载平衡、DNS、CDN 这些零碎,那么从这些零碎所产生的日志中便能挖掘出十分有价值的信息,也能做到从全局和上帝视角对整个零碎的状态和性能进行实时监控。日志服务未然是零碎稳固运行必不可少的一部分,成为DevOps中的标配选项。本次大促中,日志服务零碎的稳固运行,完满实现了大促的保障工作,为大促新纪录提供了松软的保障。本篇文章将介绍大促对日志服务所带来的挑战,以及京东智联云日志服务零碎架构设计。 一、大促对日志服务带来的挑战1,性能方面作为最罕用的排障、剖析工具,日志服务性能的欠缺性有着很重要的影响。在大促的场景下,用户的次要场景需要有: 现场日志查看日志监控实时剖析日志生产2,老本方面数据作为企业最贵重的资产,大促的数据更是外围中的外围。 团体及咱们服务的相干企业一方面冀望数据资产存储越久越好,另一方面又要讲求老本与效益的均衡,这便造成了一种矛盾的景象。 日志服务每天产生以PB计量的数据,造成了一个不可漠视的老本项,如何无效升高其整体老本,是一个最间接的难题。 3,稳定性方面大促作为京东团体全年唯二的最高级别大型流动,对服务的稳定性有着近乎刻薄的要求。服务上一次不稳固的稳定,都会间接导致支出上的损失。日志服务作为团体服务的技术基石,本身服务的稳定性至关重要。 二、京东智联云日志服务解析京东智联云日志服务,作为京东外部一站式DevOps解决方案运维域的重要组件之一,为全团体提供对立日志解决方案。通过为研发、运维、经营提供检索、排障、剖析等性能,满足各业务零碎、经营零碎、中间件、底层服务的需要,助力其施展价值。 1,产品功能完善作为最罕用的排障、剖析工具,日志服务提供了欠缺的产品性能。在确保笼罩各类性能需要的根底上,提供了_智能解析_、_施行剖析_等增强型性能。为撑持「疾速发现问题」-「疾速定位问题」-「疾速解决问题」的外围指标提供了保障。 日志服务的业务性能架构图如下: 2,老本京东智联云日志服务整体架构上实现了存储与计算拆散。可进行针对性的调优。 咱们先来看一下日志服务利用架构示意图: (1)存储存储的应用次要对应利用架构视图的indexer局部。这里次要关注存储相干的两个因素: 存储介质 、 存储内容 。 ①存储介质 业余的团队干业余的事件,抉择业余的存储产品,日志服务层不再干预存储层的优化。 选取准则为: 足够成熟稳固;老本便宜。咱们抉择了对象存储产品。其特色为: 资源弹性伸缩老本低廉高可用性保障安全性兼容规范S3整个产品应用下来十分稳固,实现了存储介质上的「低成本」。 ②存储内容 日志存储计划示意图如下,上面咱们来讨论一下在升高存储内容方面做的工作。 日志数据流传输到服务端后,被indexer重组为bucket及index文件,最终被写入共享存储。 index文件用于减速定位检索的文件,bucket局部用于存储日志原始数据。index及bucket均采纳了压缩的形式进行存储,实现了存储内容上的「低成本」。 (2)计算计算资源的应用次要对应利用架构视图中的query indexer局部。 这一部分性能有: 依照索引计算须要加载的bucket加载bucket根据bucket中的meta定位待处理的block针对block内容进行解压+计算后果聚合通过上述性能能够看到, 日志检索、剖析工作兼具IO密集型及计算密集型特色 ,这部分是须要咱们针对性进行资源优化利用的。 在数据的扫描上,咱们通过多级索引,实现bucket文件的精准定位。 采纳提早加载的形式加载bucket进一步升高IO开销。 计算环节采纳了优先级工作队列+worker池的形式,通过晋升工作的并发度,能够借助更多的计算资源晋升计算速度。通过对计算工作进行评分,给予不同的优先级,正当调度计算资源,实现分级保障。 3,稳定性上云的用户最关怀的问题就是各个根底服务的稳定性。用户是否能够齐全信赖日志服务呢,日志服务是如何保障服务的高可用性的?接下来让咱们一起探讨下日志服务的根本实现及在稳定性上所做的一些工作。 先简略介绍日志服务的组成模式及大促备战流程,这是咱们进行后续探讨前须要理解的背景信息。 上面借助日志服务职责分层示意图,来理解日志服务的组成模式: 采集层: 日志agent,适配云主机,k8s等各类环境,提供日志收集性能;存储层: 底层复用Database及对象存储的能力,实现数据的高可用存储;计算层: 对日志数据进行过滤、转换、统计,反对业务层各个功能模块;业务层: 日志产品层。提供检索、剖析、监控、生产转储等性能。大促备战流程: 其中,咱们需重点辨认如下信息: 辨认重保租户辨认重保零碎用户设定的预申请配额理解以上信息后,咱们开始在多个方面探讨稳定性相干工作。 (1)高可用一套高可用服务的推出,要经验的次要环节如下: 存储层 复用Database及对象存储的能力,间接实现跨AZ高可用、跨region的容灾能力。每个产品都做了大量稳定性相干的工作,这里不再赘述。 计算引擎 ◆  轻量级实时计算服务:自研无状态服务,依照规范的跨AZ、Region部署的准则,能够很轻易地实现高可用及容灾。 ◆  基于大数据引擎的计算服务: ◇  依照业务进行划分,实现资源隔离; ◇  HA+checkpoint,保障作业的复原; ...

November 30, 2020 · 1 min · jiezi

关于devops:敏捷与-DevOps-混合动力助力明略开拓企业智能新世界

明略科技是中国当先的数据中台和企业智能决策平台提供商,致力于通过大数据分析开掘和认知智能技术,推动常识和治理复杂度高的大中型企业进行数字化转型。 目前,明略科技已为公共安全、工业、数字城市、金融、营销、广告及服务业等垂直行业的 2000 多个组织,提供数据智能解决方案。 企业 AI 步入行业开辟期,研发效力亟待晋升随着“新基建”的宽泛布局,企业数字化、智能化的转型已势不可挡。AI 作为新基建当中不可获取的动能之一,推动产业朝更智慧的方向后退。但因为 AI 行业从概念遍及期过渡到落地期不久,各行业在 AI 能力建设过程中,不可避免会进入无人之地。因而,明略科技在实现每一个行业标杆客户的智能解决方案落地,都在开辟着 AI 技术平台的新畛域、新思路。 随着越来越多垂直行业标杆客户的开辟,明略的业务越来越多元化,面临的挑战也在逐步降级,研发效力亟待晋升: 我的项目团队数量激增,沟通协同老本居高不下。研发效率难以度量,研发治理难度显著加大。企业客户的定制化需要增多,研发交付速度急需晋升。团队办公模式多样化,部门间协同模式也需多样化。麻利与 DevOps,混合能源让明略跑得更快更稳高效的企业研发建设在顺畅、稳固、牢靠的研发基础设施之上。基于 CODING 提供的麻利与 DevOps 工作流, 明略科技搭建了更加自动化、体系化、高质量的研发流程,缩小了开发人员的有效沟通,让研发交付不仅疾速而且无效。 我的项目协同晋升交付价值明略面对的行业十分多元,特地是工业、金融、互联网等场景简单的行业,其业务需要多变且往往有着十分丰盛的背景信息,团队之间需及时同步变更信息,应用一般沟通工具难以查阅无效的探讨信息。同时,为了应答业务需要的急增,明略有大量的小型研发团队在并行开发,如何正当估算需要所需的人力投入,晋升交付价值,也是项目管理的难点所在。 应用 CODING 之后,明略的研发团队将我的项目事务录入到了我的项目协同中。基于我的项目的复杂性以及多变性思考,明略抉择了故事点这种更麻利的形式来进行需要工作的估算,解决了拍脑袋决定人力投入的问题。针对信息同步的问题,明略通过我的项目协同丰盛的关联和援用性能,每个成员都能够残缺地获取需要的背景信息、详情进度和上下文信息。 有了明确的业务需要以及牢靠的人力老本度量,迭代的布局也变得更加正当,业务人员与开发人员的合作更加严密与通顺,业务的交付价值也在无效晋升。 研发数据驱动治理降级研发数据是研发提效的根底,没有精确、全面的研发数据,研发治理问题就难以被实在反映,更不要谈采取有效的治理措施。 针对明略研发团队数量繁多的特点,CODING 的仪表盘以及效力度量,帮忙明略研发团队汇总数据、剖析数据。仪表盘演绎了研发团队所有的工作数据并予之量化剖析。这些海量的数据皆会以图表或列表的形式跃然纸上,研发团队可随时查看各项目标进度、状态和指标。 明略的技术保障部门 leader 和咱们分享道:作为技术保障团队,咱们始终在致力摸索如何进步研发效率以及交付速度。仪表盘当中的“迭代概览”与“近期事项”咱们常常应用,迭代概览中的事项进度和故事点燃尽图能够帮团队更好地把控进度:通过理论燃尽的曲线与打算进行比照,能够疾速辨认出迭代的交付危险,从而及时给予成员所需的环境与反对,帮忙成员更高效地实现工作。 在我的项目完结后的复盘阶段,效力度量能够进一步剖析成员在周期内的工作负荷、实现的工作量与工作动静,让明略的研发 leader 清晰地理解团队成员的负载与效率。在下一个新我的项目开始时,可依此作为成员的能力掂量参考来制订新的我的项目打算,从而进步下一个我的项目交付胜利的概率。 CI/CD 全流程管控利用上线在应用 CODING 之前明略次要是采纳本地自建的形式来搭建研发流水线,这须要研发团队抽出精力去装置工具与插件,平时还需不定时解决工具的软件破绽、服务器故障、网络故障等问题,还需自行买通自建的 DevOps 工具与部署资源的连贯。 基于 CODING 的代码托管、继续集成、制品库、继续部署,明略搭建了云端的自动化继续交付流水线,将利用公布无缝接入了正在应用的腾讯云计算资源中,例如CVM(Cloud Virtual Machine 云服务器)、TKE(Tencent Kubernetes Engine 腾讯云容器服务)、SCF(Serverless Cloud Function 云函数) 等: 强整合的 DevOps 工作流让明略研发团队领有了统一的账号体系、权限治理、UI 体验;同时免去了 DevOps 基础设施的自建与保护,研发团队终于能够将精力集中到业务的交付上。 1.对于交付,明略关注的不仅仅是速度,更是品质。CODING 将品质构建在了自动化流程当中:在研发人员提交合并申请时,会触发自动化的代码扫描以及继续集成,将坏滋味代码断绝在门禁之外。 ...

November 27, 2020 · 1 min · jiezi

关于devops:谁说产品经理和程序员之间不能和平共处

摘要:那有什么简便的方法能让团队成员疾速共创起来呢?置信大家都会统一认为,具备一个框架并且有清晰指引的形式是最简略的。明天笔者就给大家介绍一种四两拨千斤的方法-用户故事地图。用DevOps拥抱变动的世界,2020年11月,中国DevOps社区峰会在成都举办,多位业内大咖齐上阵,继续推动DevOps静止在国内的倒退。华为云DevCloud资深产品经理受邀分享主题“如何让团队在高度共识中实现需要与设计沟通”,介绍针对我的项目需要设计中经常出现的我的项目团队需要了解不统一、需要共识不到位,从而导致需要返工、我的项目延期、团队成员积极性不低等问题的应答计划。 在日常项目管理的需要设计中,置信大家都会遇到许多的为什么: 1.为什么需要不合乎用户的想法啊? 2.为什么需要研发总是延期呢? 3.为什么我的项目团队总是对需要无奈达成共识呢? … 面对以上如此多的为什么,那本源到底是在哪里呢?笔者曾经验过软件工程师、项目经理、产品经理等多个角色,因而也与以上多个角色的对立面进行过强烈PK,比方做软件工程师时,与产品经理的互黑;做项目经理时,又常常剧烈驱逐团队减速交付进度;做产品经理时,会通过各种画饼单向洗脑研发交付团队。起初仅从该角色为出发点,以本人的观点来了解并试图压服其余角色与本人达成统一。但此时问题就凸显进去了: 1.需要各自了解的不统一。 2.尽管了解了需要,然而心理不服啊,会认为这需要没啥价值,随随便便做完就OK了。 3.最大的问题是,用户爆炸了,这是做的啥啊? 4…….. 很多诸如此类的问题,究其根因就是单向沟通造成的,大家没有达成共识,没有充沛了解用户的需要。要解决此类问题,就须要大家独特参加需要的设计,使得大家对问题达成共识,彼此有充沛的了解,调动大家积极性一起从多个视角、全方位了解问题并达到翻新。这好比就是蜘蛛侠一个人战斗,始终也会变为灰色的蜘蛛。但如果到了复仇者联盟就会能量大暴发。 那有什么简便的方法能让团队成员疾速共创起来呢?置信大家都会统一认为,具备一个框架并且有清晰指引的形式是最简略的。明天笔者就给大家介绍一种四两拨千斤的方法-用户故事地图。 什么是用户故事地图? 用户故事地图定义 用户故事地图就是通过故事化+图形化的形式将用户需要活泼的展示在团队背后,让团队能够全面梳理、探讨,确认story蕴含的内容。它从用户视角理解产品流程,能够帮忙咱们找到用户的痛点、发现产品存在问题的阶段,从而对症下药地进行优化,因而它非常适合产品需要的共创性设计。用户故事地图要求所有相干角色都须要参加,包含:产品经理、研发经理、软件工程师、设计师、用户,有时可能还须要高层领导的参加。 总之,请牢记这是一个全员参加设计,从多角度发现问题,洞察需要的过程。 从望闻问切的角度把脉用户,一个规范的用户故事地图个别蕴含以下三大组成部分: 1) 用户:用户画像(persona)、用户指标(user goals/needs); 2) 用户和产品:用户行为(doing)、触点(touch point)、想法(thinking)、情绪曲线(feeling/experience); 3) 产品机会:痛点(pain point)、机会点(opportunities)。 如何绘制用户体验地图?依据之前介绍,整个用户故事地图其实就是一个我的项目团队与用户独特拼图的过程,集思广益把上述所有用户故事地图须要填写的信息全副填写进去,没有简单的合作流程,没有太多的步骤。制作一信息个用户故事地图分为四个步骤: 上面咱们以“华为开源镜像站产品的设计需要”来阐明如何制作用户故事地图,为了阐明制作过程,对相干的信息做了裁剪和形象。(华为开源镜像站是华为云提供的一个开源组件:https://mirrors.huaweicloud.com/) 1. 用户定义用户定义次要的目标就是能勾画出用户画像,找到用户的基本特征、行为特点、用户指标,要十分分明本人的产品是为谁设计。用户定义的方法能够如下所示,首先挂出一个典型人物的头像,定义姓名。而后从人口属性、行为特点、用户指标等几个维度别离进行重点形容。 2. 骨干故事依据用户画像,明确用户要实现的工作阶段及用户指标。在案例中,用户的指标就是用户在整个下载镜像并注册为华为云会员的过程中的要求或需要。列出用户指标,能够让咱们真正思考用户在每个环节,想要的是什么。比方镜像站用户的应用过程和指标如下: 3. 拆解故事1)梳理用户行为和接触点: 依据用户次要故事和指标进行用户故事的拆解,这里次要设计触点、用户行为、欠缺对用户情绪与心理的剖析。首先梳理用户与镜像站产品的接触点,而后根据接触点梳理出用户的要害行为,再通过行为来理解用户的心理和情绪。 2)用户想法和情绪曲线: 依据对应的阶段的用户行为,写下过后用户的思考和想法,并以条目标模式整理出来。而后提炼用户每个节点的情绪,提炼情绪时,为了避免集体主观判断导致的误差,倡议两个人一组用雷同的数据进行提炼。 4. 沟通确认-演绎痛点和机会点通过用户每个阶段的行为和情绪曲线,整顿出每个阶段的痛点和问题,以及思考痛点背地的起因,此处是否能够采取什么措施,来满足用户的指标,晋升用户的体验,这就是机会点。 5. 残缺的用户故事地图通过以上的整顿后,就得出了完整版的用户故事地图。后续能够对地图进行整顿和丑化产出。并依据整顿出的机会点,依据重要水平和难易水平排出优先级来安顿执行。优化用户体验地图中的痛点,帮忙用户实现目标,或者确立新的产品性能的方向。 总结本文次要通过华为开源镜像站的示例讲述了用户故事地图的制作流程。 用户故事地图其实简略说就是一种十分乏味的拼图游戏,大家一起来洞察用户,发现产品机会。理论工作中除了填写本文列举的这些条目外,能够减少相干的拼图条目,以便可能更加全面的的发现用户需要。 项目前期是不可能正确的捕获并写出所有的需要所有故事的,用户故事地图这个办法也不可能在繁多阶段捕捉出所有的用户故事。用户故事不是二维的产物,应该是三维的,需加上工夫这个维度,随着工夫的推移以及产品不同阶段退出产品新的用户故事。逐渐减少和优化各种故事地图,与时俱进。 因为是大家独特洞察的后果,所以可能很好的达成共识、同理心,并且能从多角度发现问题。 点击理解华为云DevCloud,一站式云端DevOps平台 点击关注,第一工夫理解华为云陈腐技术~

November 26, 2020 · 1 min · jiezi

关于devops:项目管理全新升级博云DevOps产品-V34正式发布

近日,BoCloud博云推出 BeyondDevOps 产品 v3.4 正式版本,该版本提供端到端 DevOps 的最佳实际落地平台,构建从需要到开发、测试、上线的可视化、自动化的研发过程治理和继续反馈度量体系,帮忙企业打造标准化、规范化的研发流水线,实现业务稳固高效的继续经营。 新增亮点1. 项目管理全新降级 工作项反对多达10种灵便可配的自定义字段属性类型,通过自定义属性能够为工作项增加扩大字段,满足个性化界面的须要。 2. 工作流全新降级 将工作流从零碎模板扩大到我的项目中,减少我的项目级工作流,不便项目经理在我的项目中可能更灵便的配置工作项状态的流转。 3. 工作台 反对集体工作台性能,工作台中整合了集体待办事项列表,能够更加专一于工作,进步工作效率。 对于BeyondDevOps平台BeyondDevOps 平台是博云提供从 “ 需要 -> 开发 -> 测试 -> 公布 -> 运维 -> 经营 ” 端到端的开发经营一体化平台解决方案。平台笼罩项目管理、研发治理、运行治理和经营治理的协同服务和研发工具撑持,将线下 IT 生产过程转变为线上高度自动化、可视化的 IT 生产线,晋升产品研发效率,疾速响应业务需要,保障工作品质,并通过度量剖析、危险预判,继续晋升 IT 经营能力。 # 率先通过信通院 DevOps 评估,外围工具能力达到国内领先水平 10月20日,在2020 云原生产业大会上,中国信通院针对 DevOps 服务能力等行业痛点,在大会上正式颁布了研发经营(DevOps)解决方案分级能力要求等多项云原生畛域规范评估后果。博云成为首批通过信通院 DevOps 评估的云计算厂商之一。 研发经营(DevOps)解决方案能力分级要求标准了DevOps解决方案应具备的服务能力,笼罩项目管理域、利用开发域、测试域、运维/经营域等利用开发经营全生命周期能力子域。规范对 DevOps 解决方案及相干工具能力进行分级,分为根底级、加强级、先进级。 作为率先通过中国信通院首批 DevOps 评估的厂商之一,博云 BeyondDevOps 平台取得 DevOps 利用开发域的最高级别——先进级认证。这意味着 BeyondDevOps 的集成开发环境、代码托管、代码评审、编译构建、流水线、部署公布多项 DevOps 外围工具能力达到国内领先水平。 目前,博云 BeyondDevOps 平台在金融等行业已领有大量案例,可能为客户提供稳固牢靠的 IT 交付生产线,帮忙企业打造适宜本人的研发经营一体化平台,通过实现业务、开发、测试、运维团队的一体化,帮忙企业客户业务又快又好地上线公布。 ...

November 17, 2020 · 1 min · jiezi

关于devops:面对大促DevOps怎么做这里有一份京东1111-DevOps备战指南

面对大促DevOps怎么做?这里有一份京东11.11 DevOps备战指南 往年11.11,从0点到23点59分,京东11.11寰球酷爱季累计下单金额冲破 2715亿元 ,发明了新的记录。随着GMV和买家数不断创新高,要应答几何级增长的大促须要跨多个团队协同,云资源应用也越来越多,从几百到几千、上万,每个都核查一遍根本不事实,京东智联云DevOps作为京东智联云的核心技术产品,能实现研发、测试、运维高效协同,晋升服务交付效率和稳定性,并能通过 服务与资源管理 、 继续交付 和 智能监控 三大利用场景,疾速发现问题-定位问题-解决问题。 ▲京东智联云DevOps在2019年跻身IDC MarketScape中国DevOps云市场"Major Players"地位▲  一、发现问题——故障无处遁形监控是研发、运维人员的眼睛,对服务进行多维度平面的观测,能力确保故障呈现的时候第一时刻发现。京东智联云监控为用户提供如下倡议: 监控笼罩排查京东智联云监控提供从_浏览器->边缘节点(CDN)-> 负载平衡 –> 服务器_全链路的监控笼罩, 通过定义监控规范,为用户增加监控,帮忙用户笼罩监控提供办法、工具上的反对。 监控规范分为四层,咱们从下往上看: 重点零碎在日常工作中往往曾经在平安方面进行了重点关注,在大促备战期间次要关注: _首先是根底监控,_这一层次要解决机器、网络层面的问题,包含咱们常见的CPU、内存,机器死机等问题;_而后是存活性监控,_解决程序部署到机器上后,是否存活的问题,比方过程退出,端口发送一个ping过来,没有返回pong;_再上一层,则是性能监控,_重点关注Google提出的四大黄金指标pv、平响、错误码和容量等,解决分布式程序的定界问题(比方通过拜访MySQL的工夫飙升晓得是上游MySQL的问题);_最上层是业务监控,_模仿用户进行拜访,解决服务在用户侧的体现是什么。有了规范,设计的监控零碎就能依照规范来落地,能够给出一些数据化的经营指标,推动监控的欠缺。 基于对业务配置的指标采集、告警规定的剖析,帮忙用户分层级地发现监控配置当中的疏漏,揭示用户在各个层级配置监控,晋升监控覆盖度。  日常巡检所谓 上工治未病 。除去配置笼罩残缺的报警,及时排查服务的潜在危险,防止大促流量洪峰期间呈现服务质量的问题,日常巡检必不可少,京东智联云智能监控提供內建根底资源巡检大盘,帮忙用户疾速发现资源有余问题。 同时,京东智联云自研时序数据存储反对OpenTSDB/Prometheus协定,便于集成Grafana组件,不便用户自行定制大屏。除去时序数据指标,京东智联云还提供基于日志的实时指标提取计划,能够对接报警、展现。 定位问题“ 如果我有一小时援救地球,我会用59分钟界定问题,而后用1分钟解决它 。 ” ——爱因斯坦 当故障产生,定位问题的边界,疾速寻找根因是缩短整个故障解决MTTR的重中之重。京东智联云智能监控从“宏观”定界到“宏观”定位角度,通过联结事件、日志、利用异样多维度数据,帮忙用户缩短定位问题工夫。 事件追踪故障往往由“流量降落”、“页面打不开了”等黑盒类检测发现,但问题的具体所在并不能通过此类告警发现。而故障产生往往与变更无关,帮忙业务人员疾速理解到故障时段,到底呈现过哪些模块的调整,来推断问题的边界就有很大的帮忙。 智能监控集成关联利用的各类变更操作,打消业务人员的信息屏障,为业务人员提供“上帝视角”,能够从宏观层面理解到以后各个子系统都在产生些什么,可能更好帮忙用户找到具体的故障起因以及故障故障模块。 日志追踪在确认问题边界之后,接下来就是对具体故障起因的剖析了,京东智联云日志服务提供对服务日志订阅、检索、剖析等多方面性能。承载 PB 级日志业务,提供低成本、高性能的残缺解决方案。通过现场日志查看、以及日志剖析工作等性能,从“白盒”的角度观测业务以后正在呈现的异样。 排障利器JEX宏观层面,京东智联云监控团队推出自主研发的无侵入式的故障诊断平台JEX, 实时捕捉异样,能够在线开启火焰图,捕捉CPU/内存热点,行级别定位代码问题,大幅缩短研发人员排查故障工夫。通过集成JEX, 研发人员能够在第一工夫获取业务Exception的具体情景,JEX能够保留异样事件产生的环境信息,不便研发复现以及定位代码问题所在。 二、解决问题“ 凡事预则立不预则废。 ” 故障产生第一时刻应该执行止损操作,防止对线上业务造成继续的影响。京东智联云DevOps平台通过一直的压测、破坏性演练,保障了在历次大促期间安稳运行。通过对故障解决实际的一直总结凝练,京东智联云DevOps推出 预案平台 ,作为研发、运维同学的“手脚”,为业务方提供疾速止损的能力。咱们将预案分类为 流量解决 、 扩缩容 、 降级 、 数据恢复 、 主备切换 等几大维度,领导用户自流量入口到后端存储建设欠缺的预案体系。同时提供可主动执行以及可手工执行的预案,针对不同团队不同运维场景的故障止损操作。 预案平台提供webhook、对接DevOps平台控制系统两种形式别离应答不同场景的故障自愈。 Webhook京东智联云智能监控反对对告警配置增加webhook的模式来买通 故障的发现 到 解决 环节。用户能够定制本人的webhook API, 实现数据分析、故障解决、自行的音讯告诉等不同场景的扩大。 ...

November 16, 2020 · 1 min · jiezi

关于devops:有奖体验-CODING-产品iPad-ProHHKB-键盘等超级礼包等你来

DevOps 研发效力降级、高效率研发工具已成为软件研发行业的热门话题,也是每个企业研发团队须要一直摸索的命题。CODING 一站式软件研发管理工具平台旨在让开发团队低门槛应用 DevOps 工具,帮忙每个团队找到最佳的 DevOps 实际门路。为此,CODING 推出了「DevOps Workshop 学习营地」,在这里,你能够深度体验 CODING 产品,学习实际 DevOps 的全过程,体验高效的开发流水线,实现相应的工作还可解锁精美礼品及定期抽大奖! 在 DevOps Workshop 你能够取得摸索 CODING 产品,体验高效的开发流水线工具对 DevOps 开发实际有更粗浅意识参加 iPad Pro、机械键盘、Bose 耳机等礼品抽奖环节CODING 洋葱猴大礼包等精美礼品或腾讯云产品大礼包在 Workshop 中体验残缺 DevOps 工具链CODING DevOps Workshop 中,工作包会领导您应用 CODING 的代码治理、麻利开发、制品库、继续集成、测试治理、文档治理、继续部署等产品,笼罩 DevOps 研发工作流。 大量精美礼品,等您支付需在 CODING 平台中依照操作步骤实现工作通过后即可支付礼品 实现工作,定期参加大礼抽奖 参加即可得腾讯云各产品高价值大礼包 还有 CODING 周边大礼包、短鹅联萌公仔随机送 如何参加 DevOps Workshop注:CODING 用户受权即可参加非 CODING 用户需实现注册后参加 1. 流动登录: 在 PC 端浏览器中关上: https://workshop.coding.io 2. 工作挑战: 依照操作步骤实现工作,即可取得对应的学分3. 解锁礼品: 抽奖、支付礼品 合作伙伴 点击马上加入流动舒适提醒:在 PC 端关上流动链接体验更好哦~

November 13, 2020 · 1 min · jiezi

关于devops:11-月-22-日CODING-DevOps-技术沙龙系列上海站质量专场来啦~

大家是否对之前 9 月份举办的「DevOps 转型与实际」 技术沙龙还有印象?深圳的观众们好评如潮,其余地区的小伙伴都在呐喊 CODING 到全国各地更多城市举办线下流动。那么这一次,CODING 携手来自腾讯等知名企业的大咖嘉宾在上海举办 「品质专场」DevOps 技术沙龙,分享研发品质与效力的实战经验,探讨如何采取有效伎俩以保障和进步软件品质。 流动工夫:2020 年 11 月 22 日(周日)13:30 - 17:00 流动地点:上海市黄浦区延安东路 550 号陆地大厦 29 楼氪空间 流动详情及报名形式见下图海报 报名本流动后,请扫描下方二维码增加小助手微信,由小助手拉大家进入沙龙流动群,加群暗号 【1122】。 奖品除了大咖们的分享,CODING 还为大家筹备了惊喜抽奖环节! 现场的侥幸观众能够取得以下奖品—— 1)CODING DevOps 洋葱猴抱枕 x 20 2)猫爪杯 x 8 3)浏览系列丛书《深度学习——实践与实战(根底篇)》x 8 4)小电风扇 x 5 5)鼠标垫 x 5 还在等什么?赶快扫描海报内二维码报名吧~ 点击也可间接跳转至报名页,让咱们相约上海! 往届流动精彩霎时 主办方 腾讯云旗下一站式 DevOps 开发平台 CODING.net,成立于 2014 年,致力于 DevOps 工具链产品的标准化。CODING 长期关注开发者社区建设,主办全国 20 余场专题技术流动。 合作伙伴

November 12, 2020 · 1 min · jiezi

关于devops:当代开发者的六大真实现状你被哪一个场景戳中了

摘要:开发者到底是怎么一个群体?或者能从调研机构Slashdata近期公布的《2020年Q3版暨第19届开发者群体状态报告》中发现一二。近几年,华为针对开发者群体的要害决策很多、投入力度很大,不仅构建了欠缺的开发者社区(中转链接),还推出了各种HDC、HC Developer Day等各种大型流动,以及DevRun、HDZ等在全国各地继续发展的地区性、社区性的流动,也十分有针对性的推出了面向业界专家的华为云专家、高校联盟等各种打算。 那么,开发者到底是怎么的一个群体呢?或者最近公布的一份权威报告能够给咱们带来些许启发。近期,业界出名的开发者调研机构Slashdata公布了最新版的开发者经济调查报告《2020年Q3版暨第19届开发者群体状态报告》,华为云也是作为Slashdata此次调研的合作伙伴,独特参加和造就了这份回收问卷总数高达17000份的业界报告。 那么这篇报告对于2020年Q3当前的开发者要害趋势都说了些什么呢?次要是如下六大场景: 新冠疫情期间开发者们的额定需要;对于不同语言社区的现状刷新;开发者驳回或回绝应用云技术的起因;实际DevOps都是什么人?开发者最看重开源我的项目啥?新兴技术。一、新冠疫情期间开发者们的额定需要· 四成开发者都反馈说受新冠疫情影响他们须要更为灵便的工作工夫和工作量安顿; · 对于开发者来说,合作工具和平台是最重要的技术需要; · 自雇佣型开发者以及小企业开发者更少因新冠疫情而产生额定需要; · 所服务企业规模越大,开发者越须要自我管理和合作的工具,以及精力衰弱方面的反对; 二、对于不同语言社区的现状刷新· JavaScript是最风行的编程语言,覆盖范围很广,寰球共有1240万开发者在应用; · Python目前共计有900万用户,仅去年就新增220万新开发者,在2020年初超过了Java; · Kotlin是成长最快的语言社区,自2017年底以来规模曾经翻倍; 三、开发者驳回或回绝应用云技术的起因;· 在思考驳回某项云技术时,价格和反对/文档是主宰开发者决策流程的关键因素;而在回绝时,价格是最重要的回绝起因; · 供应商有很多机会能够在市场上辨别定位它们的编排工具,开发者更少关怀其价格,而更关注可能有助于开发的个性; · 只有云解决方案可能满足最低要求,开发者们就不再特地关怀个性集或性能方面的问题; · 开发者会回绝无奈带给他们有满足感的开发体验的技术,可能接触到社区以及取得失当的反对是很重要的; 四、实际DevOps都是什么人?· 绝大多数的业余开发者(超过80%)或多或少都以某种模式参加了实际DevOps; · 继续集成和继续部署(CI/CD)是最常见的两大DevOps实际,但只有1/4的开发者在这两方面都做到了其工作流的自动化; · 程序员都十分违心应用CI/CD,但却较少应用等经营实际,比方在生产环境监控利用; · 领有大量有教训专业人士的软件部门更违心拥抱DevOps模式,少有例外; 五、开发者最看重开源我的项目啥?· 相比参加开源我的项目做出奉献,开发者更观赏与开源社区的单干和互动; · 简直在所有方面,西欧开发者都比其余地区开发者更器重开源; · 南亚开发者高度重视对开源我的项目的奉献,这使得该地区极有可能主导下一波开源开发的浪潮; 如下图能够看出,东亚开发者简直在所有方面都落后于其余地区……不器重与社区的合作和交换、也不器重提供继续的技术支持…… 六、新兴技术· AR/VR等新兴技术尚未齐全拥抱OSS准则; · 参与度和驳回度变动很小,这意味着DevOps已到成熟期; · 雾计算/边缘计算在从业人员中越来越有吸引力,但总体参与度依然不高; · 机器视觉正在逐步成熟,随着学习该专题的开发者大量减少,其驳回率也将增长; · 一些先进技术在参与度方面呈现了疲劳效应,但在仍继续投入的开发者中的驳回率有所回升; 如上就是本次报告的一些要害内容。 欢送继续关注华为云DevCloud,搜寻公众号:HWDevCloud,获取更多干货资讯! 点击关注,第一工夫理解华为云陈腐技术~

November 10, 2020 · 1 min · jiezi

关于devops:DevOps-视角的前后端分离与实战

本文作者:CODING - 廖红坤前言随着微前端、微服务等技术理念和架构的蓬勃发展,咱们曾经没必要去探讨为什么要前后端拆散这种话题,前后端拆散已成为互联网我的项目开发的规范模式。前后端在各自的畛域倒退越来越纵深。 DevOps 视角的前后端拆散明天咱们换个视角,从 DevOps 的角度来聊聊前后端拆散。 我的项目协同DevOps 体系中蕴含了麻利开发方法论,而前后端拆散前的开发模式无奈做到麻利。开发过程中前后端强依赖,需屡次重复集成能力公布可用版本,违反了麻利开发“适应性”的特点(适应性即欢送变动)。此外,前后端串行工作的形式拉长了版本公布周期,违反了麻利开发“疾速公布小版本”的理念。 前后端拆散前的合作模式:产品经理依据需要出原型UI 出设计图前端做 html 页面后端将 html 页面套成 jsp 页面(前后端强依赖,后端必须要等前端的 html 做好能力套 jsp。如果过程中 html 产生变更,后端也要被迫调整,开发效率低)集成呈现问题前端返工后端返工二次集成集成胜利交付 拆散后的合作模式:产品经理依据需要出原型UI 出设计图前后端约定接口、数据和参数前后端并行开发(无强依赖,可前后端并行开发,如果需要变更,只有接口和参数不变,就不必两边都批改代码,开发效率高)后端 API 自动化测试前后端集成前端页面调整集成胜利交付 代码治理前后端拆散后,前后端代码离开治理,后端不须要合并前端代码,缩小代码合并抵触问题。此外,前后端拆散后,后端能够依据业务类型自在选用编程语言开发不同的组件,实现松耦合,与微服务架构不约而同。 测试治理前后端拆散后,对应的测试也拆散了。因为后端只输入 api 接口,于是能够很不便的进行自动化测试,提前裸露问题,并且测试老本很低。而前端能够不依赖后端,本人本地 mock 数据,待前后端接口对接后,测试能够开始功能测试。 交付部署1913 年,福特汽车开发了世界上第一条流水线,大幅提高了汽车的生产效率,每 24 秒流水线就能制作一辆汽车,实现了汽车的规模化生产,福特也因而成了美国最大的汽车制造商。 交付部署蕴含继续集成和继续部署,其外围就是流水线。从代码拆散开始,前后端就造成了两条并行的流水线,各自独立编译,构建,打包,公布。公布过程中不须要对方在场,呈现了问题各自回退。 从我的项目协同、代码治理、测试到交付部署,须要一套残缺的 DevOps 工具链撑持,比拟典型的如 Jira + GitLab + Jenkins + Nexus + Kubernetes,但这些工具之间账户体系、操作习惯互不相通,试想团队每退出一个新成员管理者都要在每个工具平台为其增加账户,新成员也要花工夫去逐个相熟。这对管理者和新人都是不必要的累赘。这样的背景下,咱们能够采纳 CODING 提供的一站式 DevOps SaaS 服务,疾速实现前后端拆散的 DevOps 最佳实际。 疾速实际 DevOps本文以崇奉麻利开发理念的互联网团队 突突突小分队 为例,基于 CODING DevOps,以项目管理为终点,继续部署为起点演示疾速实现前后端拆散我的项目的 DevOps 最佳实际。相干人员: ...

November 4, 2020 · 2 min · jiezi

关于devops:DevOps教程DevOps-自动化

【注】本文译自:https://www.javatpoint.com/de... 自动化是 DevOps 实际的要害需要,使所有自动化是 DevOps 的根本准则。自动化过程从开发人员机器上的代码生成开始,直到将代码推送到代码中,而后再监督生产中的应用程序和零碎。 自动化基础架构设置和配置以及软件部署是DevOps实际的次要亮点。DevOps 施行 ID 依赖于自动化能力在几个小时内交付,并在各个平台之间频繁交付。 DevOps 中的自动化可进步速度、一致性、更高的准确性、可靠性,并减少交付数量。DevOps 中的自动化封装了从构建,部署和监督开始的所有内容。 DevOps 自动化工具 在大型 DevOps 团队中保护宽泛的大规模 IT 基础架构,能够分为六类,例如: 基础设施自动化配置管理部署自动化性能治理日志治理监控 上面简要介绍一下这些类别中的一些工具,例如: 基础设施自动化 亚马逊 Web 服务 (AWS):作为一种云服务,您无需物理存在于数据中心中,它们易于按需扩大,并且没有后期硬件老本。能够将其配置为依据流量主动提供更多服务器。 配置管理Chef Chef是便捷的DevOps工具,可实现速度,规模和一致性。它能够用来加重简单的工作并执行配置管理。借助该工具,DevOps 团队能够防止在一万台服务器之间进行更改。相同,他们只须要在一处进行更改,就会主动同步到其余服务器中。 部署自动化Jenkins 有助于继续集成和测试。通过在构建后尽快发现问题,从而更无效地集成我的项目变更。 性能治理App Dynamic 提供实时的性能监控。该工具收集的数据可帮忙开发人员在呈现问题时进行调试。 日志治理Splunk 此 DevOps 工具解决了一个中央存储,汇总和剖析所有日志之类的问题。 监控__Nagios__: 当基础设施和相干服务呈现故障时,它会告诉相干人员。Nagios 是用于此目标的工具,可帮忙 DevOps 团队发现并纠正问题。

October 30, 2020 · 1 min · jiezi

关于devops:前端面试每日-31-第560天

明天的知识点 (2020.10.27) —— 第560天 (我也要出题)[html] HTML5的var标签有什么利用场景?[css] 你有应用过touch-action属性吗?说说它的用处[js] 深拷贝里的循环援用如何解决?[软技能] 请说说你对DevOps的了解《论语》,曾子曰:“吾日三省吾身”(我每天屡次检查本人)。前端面试每日3+1题,以面试题来驱动学习,每天提高一点!让致力成为一种习惯,让奋斗成为一种享受!置信 保持 的力量!!!欢送在 Issues 和敌人们一起探讨学习! 我的项目地址:前端面试每日3+1【举荐】欢送跟 jsliang 一起折腾前端,零碎整顿前端常识,目前正在折腾 LeetCode,打算买通算法与数据结构的任督二脉。GitHub 地址 微信公众号欢送大家前来探讨,如果感觉对你的学习有肯定的帮忙,欢送点个Star, 同时欢送微信扫码关注 前端剑解 公众号,并退出 “前端学习每日3+1” 微信群互相交换(点击公众号的菜单:交换)。 学习不打烊,充电加油只为遇到更好的本人,365天无节假日,每天早上5点纯手工公布面试题(死磕本人,愉悦大家)。心愿大家在这虚夸的前端圈里,放弃沉着,保持每天花20分钟来学习与思考。在这变幻无穷,类库层出不穷的前端,倡议大家不要等到找工作时,才狂刷题,提倡每日学习!(不忘初心,html、css、javascript才是基石!)欢送大家到Issues交换,激励PR,感激Star,大家有啥好的倡议能够加我微信一起交换探讨!心愿大家每日去学习与思考,这才达到来这里的目标!!!(不要为了谁而来,要为本人而来!)交换探讨欢送大家前来探讨,如果感觉对你的学习有肯定的帮忙,欢送点个[Star]

October 27, 2020 · 1 min · jiezi

关于devops:腾讯云大学-x-CODING-知识分享月直播预告

经验十年的倒退,DevOps 曾经变成被宽泛认知的研发效力方法论。DevOps 工具链作为 DevOps 落地的核心技术实际之一,在自动化和品质方面使得开发团队能够更快更好地交付产品,进步其竞争力。 本次 CODING 资深技术专家周纪海将在 《DevOps 工具链的十年演进》 课程中,向大家分享在 DevOps 10 年的倒退过程中,DevOps 工具链经验的不同阶段的演进,并带来一些在 DevOps 畛域的实践经验和独到见解。 开课时间10 月 28 日(周三)19:00 课程纲要《DevOps 工具链的十年演进》 DevOps 和工具链简介老一代 DevOps 工具目前支流和革命性的 DevOps 工具新一代 DevOps 平台和工具讲师介绍**周纪海 CODING 资深技术专家** 英国伦敦帝国理工学院博士毕业。曾在多家大型银行(巴克莱银行,汇丰银行等)从事 DevOps 工作。2018 年从伦敦汇丰银行总部派往广州中国汇丰软件,负责投行部千人的 DevOps 转型。2020 年作为首席技术布道师和资深技术专家退出 CODING。 扫描海报二维码,或通过报名中转链接,立刻报名直播课

October 26, 2020 · 1 min · jiezi

关于devops:从理论到工具带你全面了解自动化测试框架

软件行业正迈向自主、疾速、高效的将来。为了跟上这个高速后退的生态系统的步调,必须放慢应用程序的交付工夫,但不能以就义品质为代价。疾速实现品质是必要的,因而质量保证失去了很多关注。为了满足卓越的品质和更快的上市工夫的需要,自动化测试将被优先思考。对于微型、小型和中型企业(SMEs)来说,自动化本身的测试过程是十分必要的,而最要害的方面是抉择正确的自动化测试框架。 什么是自动化测试框架?自动化测试框架是为自动化测试脚本提供执行环境的脚手架。框架为用户提供了各种劣势,帮忙他们无效地开发、执行和报告自动化测试脚本。它更像是一个专门为自动化组织的测试而创立的零碎。简而言之,咱们能够说框架是各种指导方针、编码标准、概念、过程、实际、我的项目档次、模块化、报告机制、测试数据注入等因素的建设性混合,以此撑持自动化测试。因而,用户在自动化应用程序以利用各种生产性后果时能够遵循这些领导准则。 这些劣势能够是不同的模式,如易于编写脚本、可伸缩性、模块化、可了解性、过程定义、可重用性、老本、保护等。因而,为了可能取得这些益处,倡议开发人员应用一个或多个自动化测试框架。此外,当有一群开发人员在同一个应用程序的不同模块上工作时,以及当咱们心愿防止每个开发人员实现本人的自动化办法的状况下,须要一个对立的规范测试自动化框架。 自动化测试框架的类型市场上的自动化测试框架可能因反对不同的关键因素(如可重用性、易维护性等)而有所不同。如以下几种类型: ●基于模块的测试框架●测试库架构框架●数据驱动测试框架●关键字驱动测试框架●混合测试框架●行为驱动开发框架 自动化测试框架的劣势除了自动化测试所需的起码的手动干涉外,应用测试自动化框架还有许多长处:●更快的上市工夫:通过容许测试用例的继续执行,应用一个好的测试自动化框架有助于缩小应用程序的上市工夫。一旦自动化,测试库的执行将比手动测试更快,运行工夫也更长久。●晚期缺点检测:对于测试团队来说,软件缺陷的文档记录变得相当容易。它进步了总体开发速度,同时确保了跨区域的正确性能。问题发现的越早,解决老本就越低,采纳自动化测试框架的效益也就越高。 ●进步测试效率:测试占据了整个开发生命周期的重要局部。即便是总体效率的最轻微的改良也会对我的项目的整个工夫框架产生微小的影响。只管最后的设置工夫较长,但自动化测试最终所占用的工夫要少得多。它们实际上能够在无人值守的状况下运行,在过程的最初时刻对后果进行监督。 ●更高的投资回报率:尽管最后的投资可能较高,但自动化测试能够长期为组织节俭收入。这是因为运行测试所需的工夫缩小,从而导致工作品质更高。这反过来升高了公布后的故障概率,从而升高了我的项目老本。 ●更高的测试覆盖率:在自动化测试中,能够对应用程序执行更多的测试,这将带来更高的测试覆盖率。减少测试覆盖率能够测试更多的个性和应用程序的品质。 ●自动化测试的可重用性:在测试自动化中,测试用例的重复性能够帮忙软件开发人员评估程序的反馈,以及绝对简略的设置配置。自动化测试用例能够通过不同的办法来应用,因为它们是可重用的。 十大自动化测试框架1.机器人框架如果是心愿在测试自动化工作中应用python测试自动化框架,Robot框架是最佳抉择。Robot框架基于Python,但也能够应用Jython(Java)或IronPython(.NET)。Robot框架应用关键字驱动的办法来简化测试的创立。Robot框架还能够测试MongoDB、FTP、Android、Appium等。它有许多测试库,包含Selenium WebDriver库和其余有用的工具。它有很多API来帮忙它尽可能地扩大。Robot框架应用的关键字办法对于那些曾经相熟其余基于供应商的关键字驱动的测试工具的测试人员十分有用,这使得他们更容易过渡到开源。 2.网络驱动(WebDriverIO)WebdriverIO是一个基于Node.js的自动化测试框架。它有一个集成的测试运行器,能够为web应用程序和本地挪动利用程序运行自动化测试。同时,它能够在WebDriver协定和Chrome Devtools协定上运行,使它对基于Selenium WebDriver的跨浏览器测试或基于Chromium的自动化都无效。因为WebDriverIO是开源的,你能够失去一堆插件来满足你的自动化需要。“Wdio装置向导”使安装简单和容易。 3.CitrusCitrus是一个开源框架,您能够应用它自动化任何消息传递协定或数据格式的集成测试。对于任何类型的消息传递,如REST、HTTP、SOAP或JMS,Citrus框架将适宜测试消息传递集成。如果您须要与用户界面交互,而后验证后端流程,那么能够将Citrus与Selenium集成。例如,如果您必须单击“发送电子邮件”按钮并在后端验证电子邮件是否已收到,柑橘能够接管此电子邮件或UI触发的JMS通信,并验证后端后果,所有这些都在一个测试中实现。 4.CypressCypress是一个以开发人员为核心的测试自动化框架,它使测试驱动开发(TDD)成为开发人员的事实。它的设计准则是可能打包和捆绑所有货色,使整个端到端测试体验欢快和简略。Cypress的架构与Selenium不同;Selenium WebDriver近程运行在浏览器内部,而Cypress运行在浏览器外部。这种办法有助于了解浏览器外部和内部产生的所有,从而提供更统一的后果。它不须要您解决对象序列化或在线协定,同时为您提供对每个对象的本机拜访。当您将应用程序拉入浏览器时,Cypress能够同步告诉您浏览器内产生的每一件事件,这样您就能够本机拜访每个DOM元素。它还使得在应用程序中搁置调试器变得很容易,这反过来又使开发人员工具的应用变得更容易。 5.Seleniumweb应用程序最风行的开源测试自动化框架之一。Selenium还能够作为许多其余测试工具的根底,因为它具备跨平台和跨浏览器的性能。Selenium反对多种编程语言,如Java、C#、PHP、Python、Ruby等。它易于保护,因为它领有最大的在线反对网络之一。Selenium能够通过宽泛的库和api进行高度扩大,以满足每个人的需要和需要。Selenium是测试人员的首选,因为它能够编写更高级的测试脚本来满足各种复杂程度。它为测试编写提供了一个回放工具,无需学习特定的脚本语言。 6. Cucumber 它是一个跨平台的行为驱动开发(BDD)工具,用于编写web应用程序的验收测试。Cucumber能够疾速且容易地设置执行,并容许在测试中重用代码。它反对Python、PHP、Perl、.NET、Scala、Groovy等语言,以易于浏览和了解的格局实现函数验证的自动化。一个好的个性是标准和测试文档都被上传到一个最新的文档中。Cucumber使不相熟测试的业务涉众更容易浏览代码,因为他们能够轻松地浏览代码,因为测试报告是用商业可读的英语编写的。该代码能够与Selenium、Watir、Capybara等其余框架一起应用。 7.Gauge 它是一个开源工具无关的测试自动化框架,实用于Mac、Linux和Windows。从事TDD和BDD工作的人会喜爱Gauge专一于创立动静/可执行文档。标准——量规自动化测试是在现有的ide(如visualstudio和Eclipse)中应用C、Java和Ruby的提价语言编写的。Gauge的性能也能够通过对插件的反对进行扩大。它是作为一个BYOT(自带工具)框架开发的。因而,您能够应用Selenium,也能够应用任何其余工具来驱动测试UI或API测试。如果你想要一个可读的非BDD办法来实现自动化,你应该试试Gauge。 8.Serenity 如果您正在寻找一个与cumber和JBehave等行为驱动开发(BDD)工具集成的基于Java的框架,那么Serenity可能是适宜您的工具。它的目标是使编写自动化验收和回归测试更容易。它还容许您将测试场景放弃在较高级别,同时在报告中包容较低级别的实现细节。Serenity充当Selenium WebDriver和BDD工具的包装器。它形象了许多您有时须要编写的样板代码,这使得编写BDD和Selenium测试变得更容易。Serenity还提供了大量的内置性能,例如解决并行运行的测试、WebDriver治理、截屏、治理步骤之间的状态、促成Jira集成,所有这些都不须要编写一行代码。 9.CarinaCarina应用风行的开源解决方案构建,如Appium、TestNG和Selenium,这缩小了对特定技术栈的依赖。您能够测试挪动应用程序(本机、web、混合)、web应用程序、REST服务和数据库。Carina框架反对MySQL、sqlserver、Oracle、PostgreSQL等不同类型的数据库,提供了MyBatis ORM框架实现DAO层的惊人体验。它反对所有风行的浏览器和挪动设施,并且在IOS/Android之间重用测试自动化代码高达80%。API测试基于Freemarker模板引擎,它在生成REST申请方面提供了极大的灵活性。Carina是跨平台的,能够在Unix或Windows操作系统上轻松地执行测试。 10.ZTF Zentao Testing Framework,简称ZTF,是一款开源自动化测试治理框架。与市面上已有的自动化测试框架相比,ZTF更聚焦于自动化测试的治理性能。ZTF提供了自动化测试脚本的定义、治理、驱动、执行后果的回传、Bug的创立以及和其余自动化测框架的集成。ZTF应用go语言开发,能够反对各种平台。ZTF反对常见的编程语言,您能够抉择您喜爱用的语言来开发自动化测试脚本。通过禅道自研的ZTF自动化测试工具,可很好地驱动8种单元测试框架、3种自动化测试框架来执行测试,并把最终后果回传给禅道,进行对立的报告展现。禅道ZTF买通了项目管理和继续集成工具之间的沟壑,贯通继续集成、继续测试、继续部署等DevOps生命周期的不同阶段。 总结以上列出的工具大多是已成熟且风行的,它们应用AI/ML提供了测试自动化性能,以解决组织当初面临的疾速交付及品质的挑战。此列表还包含提供API和服务测试的工具,这些工具对于胜利的DevOps转换至关重要。人工智能、无代码、大数据和物联网测试等新兴技术正在进步测试自动化的效率,同时也为现有的工具和新的参与者发明了机会,使其可能为测试社区带来价值。 自动化工具的抉择不仅应该满足以后需要,还应该关注潜在的趋势和改良。无效的测试自动化工具应该反对根本的优化、数据生成、更智能的解决方案和剖析。到目前为止,组织中的测试自动化程度很低,在14%到18%之间。然而组织正在致力将自动化覆盖率进步到80%。API和服务测试也是将来倒退的趋势。

October 19, 2020 · 1 min · jiezi

关于devops:JFrog汽车行业DevOps峰会欢迎加入了解全球新趋势

JFrog汽车行业DevOps峰会北京工夫:10月19日 9:00 您依附数百万行代码来放弃汽车的性能和平安。谬误的软件会毁坏安全性,性能和品质,这既是毁灭性的也是低廉的。品牌名誉对您公司的胜利至关重要。疾速,牢靠和平安的软件交付管道是您能够取得的最大竞争劣势。随着软件交付最佳实际的一直倒退,胜利的路线可能会因扩散注意力而受到妨碍。 在您开发新技术和软件的过程中,挑战在于开发团队可能在数据可用性和一致性方面进行合作的能力。这对于品质和敏捷性至关重要……进入汽车畛域的DevOps时代。 退出咱们加入为期一天的独家汽车DevOps峰会,理解瞬息万变的DevOps格局如何影响您的业务策略。汽车行业专家与经验丰富的DevOps从业人员将分享他们的教训,以帮忙领导您迈向下一个飞跃。 报名地址:https://www.bagevent.com/even...

October 16, 2020 · 1 min · jiezi

关于devops:springcloud本地开发的微服务如何调用远程k8s的微服务

前言一般来说k8s应用的容器网络与开发者的所在的办公网络并不能间接连通,如何在开发环境拜访k8s的服务,就成为咱们日常开发绕不开的坎。下边就介绍几种能够不便咱们在本地环境调用k8s服务计划 计划一:Telepresence1、Telepresence简介Telepresence是一款为Kubernetes微服务框架提供疾速本地化开发性能的开源软件。它的工作原理是在本地和 Kubernetes 集群中搭建一个通明的双向代理,它将集群中的数据卷、环境变量、网络都代理到了本地。其官网如下 https://www.telepresence.io/ 2、Telepresence能帮咱们实现什么本地服务能够齐全拜访近程群集中的其余服务;本地服务能够齐全拜访Kubernetes的环境变量,Secrets和ConfigMap;K8S中运行的近程服务也能够齐全拜访本地服务。3、实际步骤a、装置kubectl命令行工具,并配置本地能够拜访Kubernetes集群 b、装置Telepresence工具 c、通过Telepresence工具启动本地服务 ps: 因为Telepresence目前次要反对Mac和linux环境,对window尽管也反对,但用window的装置形式,相比其余两种繁琐一些。而我的本地环境是window环境,因而我没采纳这种形式。如果对如何利用Telepresence拜访k8s感兴趣的敌人能够查看如下链接 Telepresence:让微服务本地开发不再难 自从用上 Telepresence 后,本地调试 Kubernetes 中的微服务不再是梦! 计划二:Kt Connect1、Kt Connect简介KT Connect ( Kubernetes Developer Tool ) 是轻量级的面向 Kubernetes 用户的开发测试环境治理辅助工具。其外围是通过建设本地到集群以及集群到本地的双向通道,从而晋升在继续交付生命周期中开发环节的效率问题以及开发测试环境的复用问题。其官网如下 https://alibaba.github.io/kt-connect/#/ 2、Kt Connect能帮咱们实现什么a、间接拜访Kubernetes集群 开发者通过KT能够间接连贯Kubernetes集群外部网络,在不批改代码的状况下实现本地开发与联调测试 b、转发集群流量到本地 开发者能够将集群中的流量转发到本地,从而使得集群中的其它服务能够联调本地 c、Service Mesh反对 对于应用Istio的开发者,KT反对创立一个指向本地的Version版本 d、基于SSH的轻量级VPN网络 KT应用shhuttle作为网络连接实现,实现轻量级的SSH VPN网络 e、作为kubectl插件,集成到Kubectl 开发者也能够间接将ktctl集成到kubectl中 3、实际步骤a、装置kubectl命令行工具,并配置本地能够拜访Kubernetes集群 以在window环境装置kubectl命令行工具为例(ps:本文的k8s是间接应用云厂商的k8s服务) 3.1、 下载kubectl 请到kubernetes版本发布页面下载与集群版本对应的或者更新的kubectl。其下载链接如下 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/README.md 3.2、 装置kubectl后,配置一下环境变量 ,并用管理员cmd命令验证一下装置是否胜利 C:\WINDOWS\system32>kubectl version --clientClient Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.9", GitCommit:"4fb7ed12476d57b8437ada90b4f93b17ffaeed99", GitTreeState:"clean", BuildDate:"2020-07-15T16:18:16Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"windows/amd64"}3.2、 配置config文件 在C:UsersAdministrator目录下新建.kube文件夹,并在该文件夹下新建config文件,并把kubeconfig内容拷贝到config文件中。 ...

October 10, 2020 · 1 min · jiezi

关于devops:3000帧定格动画告诉你什么是-DevOps

CODING 历时 3 个月用 3000 帧制作的 DevOps 科普视频新鲜出炉啦~只须要 3 分钟,Dev 和 Ops 果农将带你走进 DevOps 的世界! 点击 3000 帧定格动画通知你什么是 DevOps 即可观看视频 以下为视频概述什么是 DevOps?本视频比照了两个农场--传统农场和 DevOps 农场,在农场里,开发 Dev(developer)是种植者,运维 Ops(operations)是养护者,他们的指标是播种品质最好的果子。 传统农场中,Dev 负责种树,他们不停的松土、挖坑、栽树,好比开发者持续性地编写代码,做出扭转,为业务提供原动力。等 Dev 实现种植后,Ops 就接管了果树的培养工作,继续的浇水、驱虫,监测果树衰弱。好比运维须要负责软件的继续保护,保障业务运行稳固。 在传统的研发模式里,因为不足沟通和合作,开发和运维容易陷入相互指责。并且不足自动化工具的建设,一旦呈现了问题,故障修复迟缓。 而在 DevOps 模式下,所有都有了扭转。Ops提供自动化设施,Dev 则应用这些设施照料果树。在 Ops 对 Dev 进行简略培训后,Dev 把树苗种好,即可自行操控无人灌溉系统为果树浇水,指挥无人机喷洒农药。这就意味着在同样的工夫里,只须要更少的人力即可照料更多的果树,Ops 也只用负责对自动化设施和服务设施进行保护和降级。 比拟一下两个农场,传统模式下果子产量低、品质差;而 DevOps 模式下,果子的培养速度和品质都有了显著进步。 总结一下,过来不同团队的矛盾是--开发求变动,运维求稳固,而 DevOps 的理念是心愿突破研发和运维之间的隔膜,通过自动化流程来升高运维老本和提高效率,在监测工具的帮忙下及时发现和解决问题以保障产品质量。 目前,市面上曾经有许多能够撑持 DevOps 流程的工具,如 Git,Spinnaker,Docker,Kubernetes,Jenkins 等;也有集成性的全链路 DevOps 工具平台,比方国外的 Azure DevOps 以及国内的 CODING DevOps。如果想要突破团队沟通的壁垒,进步企业研发效力,那么实际 DevOps 不失为一种卓有成效的办法。 ...

October 10, 2020 · 1 min · jiezi

关于devops:周纪海从-DevOps-到-DevSecOps-的落地实践

2020 年 9 月 25、26 日,GOPS 寰球运维大会(深圳站)举办圆满成功。在本届大会上,来自腾讯、阿里、京东、安全的行业内顶尖专家面向互联网及传统行业、宽广运维技术人员,流传先进技术思维和理念,分享业内最佳实际。作为腾讯云旗下 DevOps 一站式研发治理平台提供商,CODING 受邀参加了本届大会。在两天工夫里,CODING 与 1000 多位现场来宾进行了深刻交换;CODING CEO 张海龙承受了媒体专访,简要介绍 CODING 产品和分享 CODING 的愿景;CODING 资深技术专家周纪海也在腾讯专场中分享了 DevSecOps 工具与实际议题。 以下为周纪海在腾讯专场分享的演讲内容—— CODING:从 DevOps 到 DevSecOps 的落地实际DevOps 简介,工具和平台个别谈起 DevOps 自动化,都是先从工具来实现。工具横跨了开发周期,项目管理、CI/CD 等环节。在每一个环节外面都有比拟经典的工具,很多工具大家也都用过。 而近几年,业界衰亡了一站式平台,从端到端打造一整套工具,囊括项目管理、代码托管、自动化部署、自动化测试等,在其中某一环节能够退出品质卡点和品质门禁去保证质量。无论是华为、腾讯还是阿里近年来都陆续呈现了一些产品,腾讯云旗下的 一站式 DevOps 平台,更集中在开发侧,涵盖了从项目管理始终到最初代码交付上线等环节。腾讯的这套自动化工具平台,通过对外输入帮忙客户解决痛点,能够在整个环节,例如构建、标准制订等环节解决客户的问题。腾讯有相干的私有云和公有云方面的产品,帮忙客户在整个研发流程上进行实现。 DevSecOps 简介,挑战和工具DevSecOps 的概念很早之前就有,以前被称为 DevOpsSec,16 年有一本书名叫“DataOPsSec”,为什么会从 DataOPsSec 变成 DevSecOps 呢?有两种说法,一种说法是 DataOPsSec 的缩写是 DOS,这就有了重名,为了防止单词的反复就改了名字;另外一种说法是 DataOPsSec 还是传统模式的程序,开发、测试、运维,最初在上线之前做信息安全。然而信息安全应该横跨整个流程,嵌入到每一个环节当中,因而变成了 DevSecOps。 那么为什么须要 DevSecOps?DevOps 曾经做好了,速度很快,品质很好,信息安全的作用是什么?下图就阐明了为什么须要 DevSecOps。传统模式下,从需要开始到整个开发测试须要 3 周的工夫,上线之前,信息安全部门染指进行平安评估,这可能须要 1 周工夫。而通过 DevOps,咱们把后面进行压缩,比如说通过自动化、微服务、麻利等伎俩把合作做得更好,效率进步,变成了 1 周。然而因为传统的 DevOps 没有思考信息安全,在上线之前还是要进行平安的评估扫描,这个工夫并没有缩短。DevSecOps 通过在 DevOps 流程的每个阶段或检查点构建安全性来打消 DevOps 和信息安全之间的阻碍,从而更快、更平安地生成高质量的代码。 ...

October 9, 2020 · 1 min · jiezi

关于devops:DevOps-转型与实践沙龙回顾第二讲

背景介绍本期分享内容为 《平台化 DevOps—云计算与云原生模式下 DevOps 的建设实际》。目前,DevOps 越来越成为大家以后建设的热点,随同着基础设施的转型和利用框架的转型,更多的业务偏差云端和 C 端的场景,促成了 DevOps 的倒退。在本次沙龙上,腾讯云 CODING DevOps 资深架构师余朋飞为大家介绍了在云计算和云原生两种模式下,如何推动 DevOps 的建设和实际。 企业 IT 架构演变历程在 2007 年之前,企业还未产生 DevOps 的概念,大多还是基于物理机的模式。2012-2014 年是第一波上云的热潮,企业纷纷将传统的物理硬件转换到虚拟机的构造上。之后,容器的倒退推动了利用的转型,微服务越来越被大家所提及,对应 DevOps 这个概念也越来越被大家所推崇。所以第二波上云是业务从底层迁徙到云上。第三波是云原生,整个 IT 基础设施,无论是从硬件端、中间件以及所依赖的数据库等资源全副可能在云上提供服务。 基于这个模式,更应该被关注的是整个软件开发自身业务需要的梳理,到整个业务的经营,这个阶段从开发态,从经营态和服务调度的模式都有新的改善。 DevOps 始终致力于怎么更好地保护利用的生命周期。在 DevOps 1.0 时代,这个时代是将根底资源做标准化,更多的是针对利用架构采取单体或服务总线的架构,对应的模式还是以虚拟化为主。 然而在整个业务倒退过程中,更应该面向的是 DevOps 2.0 服务治理,整个利用架构和基础设施的架构随之也会变动。接下来就具体看一看在这两种不同的管理模式下,整个 DevOps 的建设到底是什么样的形式去推动和落地它的。 云计算模式下的 DevOps业务上云给大家带来了什么?咱们须要解决哪些问题?以下总结了几方面目前业界比较关心的点。首先因为基础设施的爆炸式增长,导致环境配置管理和保护愈发艰难,继续部署层面须要公布的节点越来越简单;在业务推向虚拟化基础设施的时代下,业务架构变得更加简单,对应部署成功率,相应的零碎稳定性也会降落;另外因为底层云资源带来的便当,在流量冲击的状况下须要做好资源和利用的弹性;最初,随着业务对 IT 的诉求越来越频繁,须要更疾速反馈整个业务的诉求。 因而, DevOps 的建设火烧眉毛,从需要到最终上线经营的全生命周期里须要进行全方位改良——比方须要更好更规范的需要管理工具,须要通过自动化伎俩疾速治理对应的环境,可能通过自动化测试把品质建设起来,最初可能更好地解决在经营阶段的事变。在这个阶段,大家更聚焦的外围是自动化,怎么通过 DevOps 的伎俩来强化自动化流程。在自动化成果根底上随同的是标准化和版本化,在自动化的同时也要做好相应的品质内建以及 DevOps 过程度量,因为只有将过程度量好之后能力评估 DevOps 建设的成果,品质内建也是保障 DevOps 建设过程中软件的品质可能失去很好的管制。 从这几个指标来看,外围指标包含生产效率、软件研发效率,生产管制中的产品质量,对应的老本节俭。在软件研发过程中,通过牢靠、可反复的流水线能够帮忙咱们更疾速、更高效地生产 IT 软件或对应的服务。 CODING DevOps 流水线实际下图为以后 CODING 面向客户所推的 DevOps 流水线实际。 ...

October 9, 2020 · 1 min · jiezi

关于devops:金融机构如何提升IT生产效能

金融机构如何晋升IT生产效力? 在VUCA时代,各个行业都面临着易变、不确定、简单、含糊的宏观环境所带来的挑战。 作为古代经济的外围支柱之一,金融业承当着助推产业经济倒退与改善民生的双重使命。对于金融机构来说,唯有敏锐的洞察客户需要,疾速打造产品与服务,实现高效迭代与精益经营,才是这个变动的时代中制胜的要害。 无论是“金融科技”还是“科技金融”,数智科技曾经成为金融密不可分的一部分。背后是应接不暇的新需要、新体验、新玩法、新模式,身后是一直“跨界”的异业竞争者…… 对于金融机构来说,IT生产力的强弱间接决定其在强烈的竞争中能走多远。 击碎金融行业IT生产力“瓶颈”道阻且长 DevOps以其“疾速迭代、继续交付、继续运维”的指导思想,为金融行业开释IT生产力、突破倒退瓶颈提供了新方向,各类金融机构纷纷开始DevOps的尝试。然而,金融业DevOps实际依然处于摸索阶段,存在很多瓶颈持续突破: 瀑布式开发仍不能应答疾速变动的市场需求我的项目制外包开发依然会带来交付、运维危险大量竖井式零碎以致DevOps落地所需的部署和数据碎片化麻利开发仍不足跨部门协同与全流程实际,效力难以度量……击碎金融行业IT生产力“瓶颈”仍需响鼓重锤。 "Major Player"的DevOps“黄金三角” 在2019年10月公布的《IDC MarketScape:中国DevOps云市场,2019年厂商评估》报告中,京东智联云基于业务实际与多场景利用方面的劣势,跻身“Major Players”(外围厂商)地位。 京东智联云历经多年撑持整个京东团体2万人DevOps开发运维实际,总结出了集“最佳实际-工具平台-效力度量”三位一体的 DevOps“黄金三角”体系: 基于京东和一线互联网DevOps最佳实际,一直积淀和打磨出京东智联云一站式DevOps集成平台通过原创的效力度量办法提取并观测平台数据,实现效力的可量化与可视化,进一步驱动业务实际过程中的效力改良和晋升通过“最佳实际-工具平台-效力度量”的一直相互促进,实现IT生产效力增益的双闭环 “三位一体”的京东DevOps质效继续晋升模型 工具平台 京东智联云一站式DevOps集成平台可实现含麻利迭代、继续集成、继续交付在内的软件交付全生命周期笼罩。 大规模需要治理与麻利合作:面向中大型企业,买通需要整体规划和跨部门流转机制,实现需求沟通和流转线上化;提供细粒度的需要双向追踪性能,升高需要沟通老本,实现多层级麻利合作,高效迭代产品,帮忙晋升团队研发效率,升高端到端交付周期;反对项目管理与产品迭代双模治理形式,灵便应答多种简单治理场景。 企业级代码托管零碎:撑持京东团体十万级代码库和近两万工程师的研发工作。分布式高可用架构,三重代码加密备份,反对强制代码评审策略,反对30+种代码扫描引擎,一键触发代码增量/全量扫描,一键接入支流继续交付流水线。通过全方位治理与爱护企业代码资产,让开发流程更高效更标准。 继续集成与交付零碎:用流水线贯通代码提交、编译构建、自动化测试、主动部署等维度,将开发测试与上线部署闭环,造成DevOps的主动交付工具链,不便企业疾速落地实际DevOps计划,无效晋升研发、运维效率。 智能监控与排障零碎:提供涵盖智能化发现问题、精准定位异样、疾速解决问题、运维经验总结的一站式解决方案,帮忙研发运维人员疾速解决故障,保障服务稳定性。自研智能线上排障解决方案,主动捕捉并上报线上利用中产生的异样事件,保留异样产生时的残缺调用栈,现场变量、源码以及日志,帮忙开发者及时获取程序异样的线程状态,极大地缩短Debug的工夫老本。 效力度量 没有度量,就无奈改良。 京东智联云DevOps研发效力度量平台,原创“基于端到端价值流的研发效力度量模型”,通过对于多维度过程指标、后果指标的追踪,实现交付效率、交付品质、交付能力的度量,并面向高层管理者、项目经理、工程师等不同视角,提供度量仪表盘、洞察剖析、定制报表等性能,以数据领导改良,让研发效力可量化、可剖析、可晋升。 最佳实际 近五年来,京东智联云DevOps全面服务于京东团体,贯通全研发流程,禁受住屡次618、11·11电商大促顶峰流量的严峻考验。以京东APP为例,自2018年全面实际DevOps以来: 版本迭代周期从2个月缩短至2周版本需要总量晋升100%季度需要吞吐量晋升100%理论开发周期升高36%平台缺点逃逸率降幅200%仅用2个月的工夫,实现京东APP极速版的开发、上线京东智联云DevOps“黄金三角”驱动京东团体IT产能失去进一步开释。 质效合一 助力金融行业开释IT生产效力 京东智联云基于本身DevOps超大规模实际积攒,助力金融客户一一击碎效力瓶颈: 通过多种流程模板和代码托管等性能升高交付、运维危险微服务架构,反对可插拔插件,缩小落地对产品自身的批改以一站式的解决方案、独创的效力度量办法助力金融客户疾速相应需要,优化能效往年6月,京东智联云为某股份制商业银行打造银行研发利用治理平台,平台面向该行大部分利用零碎及子系统开发、上线、利用全流程,提供包含编译、部署,研发、零碎测试、运维、迭代在内的一站式服务。平台上线后,突破开发与运维团队间的壁垒,实现失去高效协同,无效晋升了该行整体业务零碎的经营和运维能力。 将来,京东智联云DevOps解决方案将继续为金融业提供更欠缺的继续迭代、继续集成、继续交付的基础设施和解决方案,助力金融客户更无效的开掘和开释IT生产力潜能,推动实现质效合一的高品质倒退。 -END- 点击【浏览原文】,理解京东智联云更多信息~

October 9, 2020 · 1 min · jiezi

关于devops:DevOps-转型与实践沙龙回顾第一讲

9 月 19 日,CODING 和中国 DevOps 社区联结举办的深圳第九届 Meetup 在腾讯大厦 2 楼多功能圆满结束。本次沙龙以 「DevOps 转型与实际」 为主题,4 位来自互联网、金融、批发行业的出名世界 500 强企业技术大咖,在现场分享了他们对于 DevOps 转型实际的见解和教训。80 多位观众与讲师们也进行了深刻的技术探讨,独特探讨在 DevOps 潮流下,企业可能面临的新机遇和挑战。 CODING 始终致力于让所有开发者都能有机会聆听最具前沿的 DevOps 技术分享,之后还会在全国各地举办一系列 DevOps 技术沙龙。在不同城市的小伙伴也无需放心,咱们届时会提供线上直播平台,让异地的同学也能与导师无障碍交换,敬请期待!话不多说,本期为大家分享的是 《DevOps 在 SEE 小电铺的落地与实际》—— 背景介绍SEE 小电铺是微信生态内最大的小程序电商服务平台,目前累计与 10000+ 自媒体单干开店,是微博、斗鱼等平台的官网电商 SaaS 服务商,以及抖音头部渠道电商平台。 SEE 小电铺技术负责人马志雄讲述了在竞争强烈的电商行业背景下,SEE 小电铺是如何引入业界优良的 DevOps 实际,打造了高效稳固的利用交付体系,帮忙公司迈向云原生时代的。他次要围绕落地的法令,分享了 SEE 小电铺内 DevOps 实际的指标、落地的准则和具体实际。 引入 DevOps 实际在疫情期间, SEE 小电铺的工作人员采取了近程办公模式,这对所有人的合作和效率提出了更高的要求。研发流程中呈现的各种问题促使 SEE 小电铺反思技术架构、研发流程、度量工具以及团队文化如何可能高质量地顺畅交付用户价值。 继续改革的第一步是辨认问题。通过调研和探讨,SEE 小电铺首先引入了 DevOps 能力成熟度模型,对以后团队外面存在的问题以及须要补齐的能力进行梳理。 SEE 小电铺在组织撑持方面设立了 DevOps 工作小组,由工程效力团队专项推动,把DevOps 具体事项纳入 OKR 里进行指标治理,并拆解到相干的一线共事外面去。借此机会,团队文化被从新塑造,工作小组一直和一线共事讲将来的技术方向是什么,为什么要去做这件事件,和所有人同步推动 DevOps 指标、办法和策略。在具体落地门路上,灰度思维帮忙优先主导推动那些对 DevOps 认同度比拟高的共事,从比拟容易革新并且可能迅速看到功效的我的项目着手。 ...

October 9, 2020 · 2 min · jiezi

关于devops:各角色如何从DevOps中受益

企业每天都面临着疾速变动和高要求。当初的主力消费者比他们的上一辈对企业有着变幻无穷的要求和更高的冀望。日益强烈的竞争意味着企业必须迅速而明智地采取行动,以保住本人的市场份额。企业一直与竞争对手竞争,致力为客户提供最好的产品。许多艰难的根本原因是不足沟通,对于许多公司来说,DevOps是解除窘境的办法。 依据RightScale 2016年对1060名IT专业人士进行的云端状态考察,81%的大企业和70%的中小企业报告采纳了DevOps。这种麻利思维办法波及到客户、产品治理、开发人员、QA和其余角色之间的合作,以便向更好的产品、服务和零碎后退。 DevOps带给不同角色的劣势是什么?开发人员没有采纳DevOps的开发人员可能会对构建和部署流程的日常工作感到丧气。因为不得不一遍又一遍地实现雷同的工作,他们会没有工夫进行翻新。 而当有了DevOps和自动化,那些枯燥反复的工作就能够被打消!没有了这些耗时性我的项目,开发人员能够领有更多的工夫做本人喜爱的事件:研发。花更多的工夫翻新、更少的工夫修理和保护是一种胜利。 不想参加软件的运维?随着DevOps买通筒仓,减少单干,这种状况也在不远的未来向你招手了。 运维人员对于运维来说,在未采纳DevOps前,典型问题之一是从开发人员那里获取随机的、通常是错误百出的代码。因为沟通很少,达成决定须要更长的工夫,也会让工作更加艰难。运维所关怀的是保护环境的稳定性,但这很难做到。 有了DevOps,运维人员在计划外工作和返工上破费的工夫缩小了22%。这次要是因为减少了与开发人员的交换。更好的代码、共享的代码库和更稳固的操作环境使工作更加轻松。 自动化和继续集成容许在不威逼稳定性的状况下交付新性能。 产品经理当你的产品和服务须要更长的工夫能力制作进去并付诸行动时,你就很难战胜你的竞争对手。当你的软件有谬误时,这尤其艰难。DevOps激励合作环境。当在生产过程中有更多的交换,产出是更好的产品。当每个人都保持一致时,最终交付的产品肯定会更好。DevOps带来的46倍的软件部署频率和440倍的变更前置工夫会让运维的工作更加轻松。 系统管理员要高效地治理一个从不沟通的团队简直是不可能的。不足沟通使工作变得艰难,因为软件有谬误,反馈不及时,可见性低。 合作是DevOps的要害因素之一。沟通会带来更好的产品和更好的零碎。此外,它们的治理也不那么简单。自动化缩小了人为谬误,且可使故障更改率升高3倍。 DevOps还减少了整个软件开发过程的可见性。当可能检测谬误、定位其本源并发现起因时,就能够迅速修复问题。DevOps使得故障修复速度快96倍。 测试工程师如果你不晓得问题是哪里产生的,是谁造成的,就很难解决问题。当找不出问题,无奈解决问题,并且晓得每一分钟都意味着越来越多的人感到不不便(可能还会为此懊恼)时,压力就来了。 DevOps容许更快地解决问题。进步可见性和沟通对于解决问题至关重要。工程师能够应用实时数据来解决问题并理解应用程序更改的影响。当呈现问题时,解决方案施行得越早越好。如果一个Bug变得太深,就更难修复了。 QAQA的工作是确保产品和零碎都运行良好,但这并不意味着他们喜爱谬误缠身的软件和过程。如果没有沟通、合作和自动化(DevOps的所有支柱),谬误就会泛滥成行。有了DevOps,团队成员能够一起工作来生产更好的产品,自动化能够缩小容易防止的人为谬误。后果就是呈现更少的谬误。并且,因为继续的集成、继续的交付以及频繁的小更改,谬误也更小更容易修复。DevOps用户报告说,修复平安问题的工夫缩小了50%,故障复原速度放慢了96倍。 客户服务任何在服务行业工作过的人,无论是在餐馆、批发还是客户服务,都晓得与不满的顾客打交道的苦楚。当零碎呈现故障和谬误时,用户会很不快乐。当然故障不是你发明的,但你必须解决它们。 DevOps会导致更少的谬误,这意味着用户的应用体验更加舒服。尽管依然会接到用户的投诉电话,但这只会越来越少。此外,用户也不会因为重复经验雷同的故障而火暴。一个更具协作性的环境意味着你的工作更容易。 终端用户扭转的意义是为了更好的用户体验。采纳DevOps不仅为本人简化了流程,这也意味着将有更多的工夫为客户做出更多的改良。 DevOps通过改良流程和应用程序使最终用户的体验更加统一。总的来说,让互动更欢快。 所有角色都受害!综上所述,每个人都受害于DevOps的一些基石,如继续集成、继续交付、公布自动化、测试自动化和合作。继续集成简直打消了产生大故障或谬误的可能性。自动化流程打消了繁琐的手工工作。合作创立了一个协调的团队,并改良了最终产品。 DevOps发明了更高兴、更高效的团队。人们不用一次又一次地实现同样无聊的工作,解决同样的问题。挫折感和不欢快的缩小会让团队成员更有效率和效率。这样能够打消工作中一些不称心的中央,为组织减少价值。 团队效率达到高峰,有更多创造性和变革性的工作、个体责任和增强沟通。当筒仓被突破后,团队会对独特的指标和实现目标的打算有一个更清晰的意识。此外,减少透明度会带来更理智的决策。受权、自信和合作的团队口头得更快更无效,从而导致更快的公布和更智能的工作。 如果出了问题或者有计划外的工作,沟通能够帮忙团队治理意外的阻碍。DevOps建设流程并明确优先级,以领导您和您的团队成员在继续执行原始打算的同时实现计划外的工作。 当员工做他们喜爱做的事件时,他们会更投入,更高兴。DevOps不解决工具问题,它解决人的问题。高兴的员工带来高兴的顾客。 公司也受益匪浅通过更好的流程和沟通环境,公司将受益匪浅。不仅在感情上每个人都是敌人的形式,在经济上也是如此。更称心的员工能够做他们喜爱做的事件,而客户失去了更好的体验,公司就会从中受害。 因为DevOps节俭了工夫和资源,并进步了公司的速度和竞争力,因而ROI(投资回报率)有了切实的进步。因为继续集成、继续交付、公布自动化、测试自动化和合作,组织可能更快地交付个性并更快地进入市场。团队是被动的,而不是被动的,因为它能满足新的市场需求并应答平安威逼。 继续的反馈使公司可能更频繁地听取客户的意见。因而,组织能够交付更及时、更具相关性的软件。这样就能够更快地响应客户一直变动的需要并改善用户体验。在现今社会下,每家公司实质上都是科技公司。如果没有疾速的软件,将永远无奈将本身产品推向市场。而没有DevOps,就无奈领有疾速的软件。 DevOps使IT与业务指标保持一致。它发明了一个专一于发明价值和继续改良组织的团队。发明最好的客户体验是头等大事,每个人都在一起发明和保护最好的产品和服务。 DevOps将速度与方向联合起来,为企业带来利益。 作者:陈琦,资深麻利测试参谋,作为国内出名项目管理软件——禅道的团队成员,次要负责开源自动化测试治理框架——ZTF的开发工作。领有十多年的麻利过程实践经验,现致力于测试自动化和DevOps相干畛域的实际和钻研。

October 9, 2020 · 1 min · jiezi

关于devops:Artifactory制品库的密码管理及策略配置

明码平安治理通常咱们在企业外部对平台帐号进行治理时,平安团队都会对咱们的帐号体系有肯定要求。 通常状况下有以下几点: 明码设定的要求,比方明码的长度,复杂度。明码治理的要求,如明码过期工夫,谬误尝试次数等等。明码平安的的要求,比方明码是否加密。JFrog Access 服务本篇文章就为您介绍一下Artifactory的帐号管理体系如何设定以上规定,对于应用Artifactory制品库的公司来说,这是一项必须要理解的内容。 那么说到Artifactory的帐号管理体系,就要给大家介绍一下JFrog Access,它JFrog产品中的一项服务,作用是在后盾治理所有JFrog服务的身份验证和受权的相干事务。Artifactory中任何配置的所有用户,组,权限和明码,都有这项服务来治理和存储。JFrog Access作为JFrog Artifactory装置的组成部分,Access服务将作为独自的WAR文件装置在 $ARTIFACTORY_HOME/webapps 文件夹下。 Access相干配置那么依据对Access的服务所承当的工作来说,咱们的明码规定配置,也天然是由这项服务来治理。 对咱们以后曾经运行的服务来说Access的配置文件,对于Artifactory 6.x的版本来说,文件存储在$ARTIFACTORY_HOME/access/etc目录下,如果是Artifactory 7.x的版本,文件存储在$JFROG_HOME/artifactory/var/etc/access目录下,文件名为:access.config.latest.yml 该文件中与明码安全性相干的配置项如下: security: password-policy:    # users' password policy (用户的明码策略) uppercase: 0      # minimum number of uppercase letters that the password must contain (明码必须蕴含的最小小写字母数) lowercase: 0      # minimum number of lowercase letters that the password must contain (明码必须蕴含的最小大写字母数) digit: 0          # minimum number of digits that the password must contain (明码必须蕴含的最小数字数) length: 4         # minimum length of the password (明码最小长度) ...

September 28, 2020 · 2 min · jiezi

关于devops:本周四CODING-DevOps-深度解析系列最后一课等你来

课程介绍《DevOps & ITIL —— 共存还是代替?》 CODING DevOps 深度解析系列收官之作:《DevOps & ITIL —— 共存还是代替?》,行将于 9 月 24 日本周四,由 CODING 特邀讲师、EXIN 官网认证 DOP/DOF 讲师、高级 ITIL 讲师 刘宁 老师开讲。 ITIL 主张通过平安、稳固的流程化的治理来为客户交付价值;而 DevOps 主张通过高速度和高质量的交付软件和性能个性为客户交付价值。在以后企业组织架构和组织文化正在进行大规模的改革背景下,会造成放弃 IT 服务治理全面驳回 DevOps 的场面吗?本课程将从企业运维视角登程,深刻解说 DevOps 与 ITIL 间的抵触与交融。 课程纲要ITIL 的前世今生DevOps 和 ITIL 有哪些交加和关联ITIL 和 DevOps 能够共存吗?开课时间9 月 24 日(周四) 19:00 - 20:00 讲师介绍刘宁 EXIN 官网认证 DOP/DOF 讲师 高级 ITIL 讲师 CODING 特邀讲师 专一于企业 IT 经营和 IT 治理方向的继续钻研和实际,为联想集团、北方航空、安全团体、中国人寿、中石化等多家知名企业提供过 IT 治理、TTT(企业培训师)、DevOps、IT 服务治理方面的征询、布局和施行服务。 ...

September 23, 2020 · 1 min · jiezi

关于devops:CODING-DevOps-深度解析系列第二课报名倒计时

课程介绍《DevOps 误区与组织筹备》 DevOps 帮忙企业与集体快速反应市场需求,传递客户价值,但不同角色就有不同解释,理论应用也往往呈现认知落差和妨碍。 CODING DevOps 深度解析系列第二课——《DevOps 误区与组织筹备》 将由 CODING 特邀讲师、CPHT(靖本行策有限公司)创办人软件工程布道师 卢建成 老师主讲,心愿就 DevOps 的各面向来探讨常见的概念误区,并且从数字化转型的需要角度,探讨组织与 DevOps 关系,提供对数字化转型和 DevOps 感兴趣的伙伴们一个将扭转引入组织的钥匙和终点。 课程纲要工具角度流程角度人与组织角度左移与服务文化DevOps 的角色举荐书目开课时间9 月 23 日(周三) 19:00 - 20:00 讲师介绍卢建成 CPHT(靖本行策有限公司)创办人软件工程布道师 CODING 特邀讲师 钻研软件工程并且接轨实务教训超过十五年,历练新产品开发、需要定义、软件设计到交付,人工智能等种种议题,并有相干译作。 扫描 海报二维码 或 点击即可预约系列课程

September 22, 2020 · 1 min · jiezi

关于devops:什么是IaaSPaaSSaaS

IAAS、PAAS、SAAS名词解释: IaaS:基础设施服务,Infrastructure-as-a-service PaaS:平台服务,Platform-as-a-service SaaS:软件服务,Software-as-a-service把软件开发合成为一下这些局部,对于IAAS、PAAS、SAAS进行比照 Applications 利用 Runtimes 运行工夫 Security & Integeration 平安与集成 Databases 数据库 Servers 服务器 Virtualization 虚拟化 Server HW 服务器硬件 Storage 保管部 Networking 网络区别解释you manage:用户决定managed by wendor:云服务商决定能够看出:·SaaS 模式下用户没有任何自主权,只能应用给定的应用程序;·PaaS 模式下能够本人装置应用程序,然而不能定制操作系统;·IaaS 模式下则是云服务商提供(虚构的)硬件,从操作系统开始都能够本人抉择和定制。 IAASyou manageApplications 利用Runtimes 运行工夫Security & Integeration 平安与集成Databases 数据库managed by vendorServers 服务器Virtualization 虚拟化Server HW 服务器硬件Storage 保管部Networking 网络PAASyou manageApplications 利用managed by vendorRuntimes 运行工夫Security & Integeration 平安与集成Databases 数据库Servers 服务器Virtualization 虚拟化Server HW 服务器硬件Storage 保管部Networking 网络SAASyou manage无managed by vendorApplications 利用Runtimes 运行工夫Security & Integeration 平安与集成Databases 数据库Servers 服务器Virtualization 虚拟化Server HW 服务器硬件Storage 保管部Networking 网络案例解释1.ISSA:IaaS 是云服务的最底层,次要提供一些根底资源。它与 PaaS 的区别是,用户须要本人管制底层,实现基础设施的应用逻辑。上面这些都属于 IaaS。 ...

September 21, 2020 · 1 min · jiezi

关于devops:K8S实战二十一-部署策略蓝绿部署滚动部署灰度部署金丝雀部署

前言应用程序的更新公布,如何升高对用户的影响面,人们钻研出了几种公布策略。 更新历史20200720 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/20/how-to-deployment.html蓝绿部署流程 筹备 A/B 两个集群,运行雷同的程序。 在我的项目降级时,首先把 A 集群从负载平衡中移除,进行新版本的部署。 B 集群仍提供服务。 A 集群降级实现后退出负载平衡,B 集群从负载平衡中移除。 长处 平滑公布,不会因公布导致服务中断,策略简略,回滚速度快,用户无感知 毛病 耗费资源,硬件老本高,须要两倍以上服务器资源。 滚动部署流程 先启动一台新服务器运行新版本,退出生产环境。 而后进行一台老版本服务器,将其更新为新版本,而后退出生产环境。 依此类推,直到集群中全副服务器降级为新版本。 长处 解决了蓝绿公布老本高的问题。如果业务须要 10 台服务器,那么降级中一共有 11 台服务器即可。 毛病 部署周期长,公布策略简单。 如果此时用户拜访呈现问题,无奈疾速确定是新版本导致还是旧版本 BUG。即无奈进行准确流量管制。 金丝雀部署、也叫灰度部署流程 在具备准确流量管制的状况下,将局部服务器降级为新版本,而后将指定起源 IP 的小局部流量导向到这部分服务器。 确定这部分用户没问题后,将全副服务器降级为新版本。 K8S 中能够应用两套 Deployment,其中一套 Deployment 运行新版本 Pod,通过 ingress 映射进去后,通过 DNS 将指定起源地区的解析,或者公司外部用户的解析,导向到该 ingress。 长处 因为咱们管制了指定起源的 IP 拜访新版本,所以呈现问题后,咱们可能晓得受影响用户拜访的是新版本还是旧版本,从而防止了滚动公布的毛病。 毛病 仍然无奈防止新版本呈现问题后对用户的影响,但咱们曾经将其管制在可控范畴之内。 结束语金丝雀部署,即灰度公布,是绝对比拟完满的应用程序公布解决方案。 分割我微信公众号:zuolinux_com

September 19, 2020 · 1 min · jiezi

关于devops:K8S实战十九-K8S-包管理-Helm

前言相似于 Linux 的 YUM、APT,Helm 是 K8S 的包管理工具。 Helm, 一个二进制工具,用来装置、降级、卸载 K8S 中的应用程序。 Helm Chart,一个 tgz 包,相似安卓的 APK。 K8S 利用打包成 Chart,通过 Helm 装置到 K8S 集群中。 更新历史20200717 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/17/k8s-package-manager-helm.htmlHelm 包管理工具装置 Helm,解压到 /usr/loca/bin/ 下 wget https://get.helm.sh/helm-v3.3.1-linux-amd64.tar.gz增加国内仓库 helm repo add apphub https://apphub.aliyuncs.comhelm repo updatehelm repo list查找 nginx helm search repo nginx装置 nginx-ingress 到 K8S 中 helm install nginx apphub/nginx如果有报错,有些旧仓库往会最新版 K8S,这里是 v1.18.2依照,会报错,能够换个仓库或者下载下来批改后本地装置 报错Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"helm pull apphub/nginx-ingress --untargrep -irl "extensions/v1beta1" nginx-ingress | grep deploymentgrep -irl "extensions/v1beta1" nginx-ingress | grep deploy | xargs sed -i 's#extensions/v1beta1#apps/v1#g'helm install nginx1 ./nginx-ingress/再装置一个 nginx-ingress ...

September 19, 2020 · 2 min · jiezi

关于devops:K8S实战十八-容器资源分配和资源限制

前言为了避免容器调度到资源有余的节点上,能够为容器指定资源起码要求量。 为了避免容器无节制的应用 CPU、内存 等资源,能够为容器指定资源最大容许使用量。 更新历史20200714 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/14/container-resources-request-limit.html资源申请和资源束缚能够为容器指定资源申请量和资源束缚量。 资源个别指 CPU、内存。 资源申请量,指容器要求节点调配的最小容量,如果该节点可用容量小于容器要求的申请量,容器将被调度到其余适合节点。 资源束缚量,指容器要求节点限度其应用的最大容量,如果容器内存使用量超过内容束缚量,容器将被杀掉,如果指定了重启策略,容器杀掉后将被重启。 波及的参数 束缚量spec.containers[].resources.limits.cpuspec.containers[].resources.limits.memoryspec.containers[].resources.limits.hugepages-<size>申请量spec.containers[].resources.requests.cpuspec.containers[].resources.requests.memoryspec.containers[].resources.requests.hugepages-<size>示例 apiVersion: v1kind: Podmetadata: name: frontendspec: containers: - name: app image: images.my-company.example/app:v4 env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"资源单位K8S 中的一个 cpu 等于云平台上的 1 个 vCPU/核或裸机 Intel 处理器上的 1 个超线程。 ...

September 19, 2020 · 2 min · jiezi

关于devops:K8S实战十一-Service-的-ServiceIngress

前言ingress 能够了解为 Service 的 Service,即在现有 Service 的后面再搭建一层 Service,作为内部流量的对立入口,进行申请路由的转发。 说白了就是在前端搭建一个 nginx或者haproxy,将不同 host 或 url 转发到对应的后端 Service,再由 Service 转给 Pod。只不过 ingress 对 nginx/haproxy 进行了一些解耦和形象。 更新历史20200628 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/06/28/about-ingress-controller.htmlIngress 的意义ingress 补救了默认 Service 裸露外网拜访时候的一些缺点,如不能进行对立入口处的7层 URL 规定,如一个默认 Service 只能对应一种后端服务。 通常说的 ingress 蕴含 ingress-controller 和 ingress 对象两局部。 ingress-controller 对应 nginx/haproxy 程序,以 Pod 模式运行。 ingress 对象 对应 nginx/haproxy 配置文件。 ingress-controller 应用 ingress 对象中形容的信息批改本身 Pod 中 nginx/haproxy 的规定。 部署 ingress筹备测试资源 部署2个服务,拜访服务1,返回 Version 1拜访服务2,返回 Version 2两个服务的程序配置 ...

September 18, 2020 · 4 min · jiezi

关于devops:K8S实战九-控制器-DaemonSet-将守护进程容器化

前言Deployment 治理的 Pod 容许在一个节点上运行多个正本。 当须要在节点上运行收集日志或者执行监控工作的容器时,显然不适宜启动多个 Pod 正本。 这种场景下,咱们能够启用 DaemonSet 控制器来治理 Pod。 更新历史20200620 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/06/20/about-controller-daemonset.htmlDaemon Pod 的特点Pod 运行在集群中的全副或者局部节点上每个节点上只能有一个这样的 Pod当集群中退出了新节点,Pod 会主动在新节点上创立当节点被从集群中移除后,节点上 Pod 会主动被回收掉Daemon Pod 实用的场景网络插件的 Agent存储插件的 Agent监控工作的 Agent收集日志的 AgentDaemonSet创立一个 DS cat daemonset.yaml apiVersion: apps/v1kind: DaemonSetmetadata: name: fluentd-elasticsearch namespace: kube-system labels: k8s-app: fluentd-loggingspec: selector: matchLabels: name: fluentd-elasticsearch template: metadata: labels: name: fluentd-elasticsearch spec: tolerations: # this toleration is to have the daemonset runnable on master nodes # remove it if your masters can't run pods - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers# kubectl apply -f daemonset.yamldaemonset.apps/fluentd-elasticsearch created查看 ...

September 18, 2020 · 2 min · jiezi

关于devops:K8S实战六-配置-NFS-动态卷提供持久化存储

前言本节中 K8S 应用 NFS 近程存储,为托管的 pod 提供了动静存储服务,pod 创建者无需关怀数据以何种形式存在哪里,只须要提出须要多大空间的申请即可。 总体流程是: 创立 NFS 服务器。创立 Service Account。用来管控 NFS provisioner 在k8s集群中运行的权限。创立 StorageClass。负责创立 PVC 并调用 NFS provisioner 进行预约的工作,并关联 PV 和 PVC。创立 NFS provisioner。有两个性能,一个是在NFS共享目录下创立挂载点(volume),二是建设 PV 并将 PV 与 NFS 挂载点建设关联。更新历史20200610 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/06/10/nfs-client-provisioner.html配置NFS服务器server ip: 192.168.10.17 [root@work03 ~]# yum install nfs-utils rpcbind -y[root@work03 ~]# systemctl start nfs[root@work03 ~]# systemctl start rpcbind[root@work03 ~]# systemctl enable nfs[root@work03 ~]# systemctl enable rpcbind[root@work03 ~]# mkdir -p /data/nfs/[root@work03 ~]# chmod 777 /data/nfs/[root@work03 ~]# cat /etc/exports/data/nfs/ 192.168.10.0/24(rw,sync,no_root_squash,no_all_squash)[root@work03 ~]# exportfs -arvexporting 192.168.10.0/24:/data/nfs[root@work03 ~]# showmount -e localhostExport list for localhost:/data/nfs 192.168.10.0/24参数:sync:将数据同步写入内存缓冲区与磁盘中,效率低,但能够保证数据的一致性async:将数据先保留在内存缓冲区中,必要时才写入磁盘所有work节点装置 nfs-utils rpcbind ...

September 18, 2020 · 3 min · jiezi

关于devops:将DevOps视为哲学实施DevOps的绝佳方式

通过此前的文章介绍,置信大家都对DevOps有了简略的理解。(回顾DevOps是什么、生命周期点这里:《DevOps生命周期,你想晓得的全都在这里了!》)DevOps的概念和工具在近些年出现热火朝天的趋势,且依据预测将持续增长。但DevOps并非久而久之就能实现,而是须要在循序渐进的应用中愈发纯熟、欠缺。您可能曾经留神到,人们信心在他们的环境中实现DevOps,并冀望从中取得更大的益处。诚然,DevOps能够让软件开发之旅走上快车道,但在本文中将展现DevOps的另一面,行将DevOps视为一种哲学。事实就是,仅仅依赖工具并不能帮忙实现目标,还须要有心态上的扭转。是的,DevOps并不齐全是为了更快的软件开发和交付。事实上,它促成了合作环境,在这种环境中,软件能够更高效、更少Bug、更疾速,而且更重要的是,以用户为核心。 DevOps的定义指出DevOps弥合了开发和运维之间的鸿沟。DevOps的最终目标是缩短软件开发生命周期,然而不应该漠视软件的品质。许多要害的技术组织,如亚马逊、Netflix、NASA、IBM、微软、谷歌、Facebook等,都在他们的开发环境中应用DevOps作为方法论。 然而你真的了解DevOps这个词及其整套理念吗?不能仅仅通过缩小软件交付的工夫就说你在做DevOps或麻利。如果你的组织正在做DevOps,那么团队中的每个人都必须参加到整个DevOps规程中,该规程重视于弱小的合作和晚期的反馈。 从无到有的DevOps旅程依据Gartner的考察,到2023年,90%的DevOps打算是因为领导办法的限度而不是技术起因而失败。DevOps从无到有的旅程将须要每个人的致力和关注,因为DevOps着眼于整个团队而非集体。这就是观点在采纳胜利的DevOps流程中能够施展重要作用的中央。当你思考理念问题时,以下几点是必须具备的:●可能感性思考特定问题●可能独立清晰地思考●以更广大的视角剖析和解决问题当你承受“DevOps作为一种哲学”以及无效的DevOps工具时,软件开发办法将被转移到深远且疾速的软件交付上,并与每个阶段的用户反馈保持一致。 有许多传统的软件开发模型,比方瀑布模型、螺旋模型、迭代模型、极限编程模型等等。另一方面,DevOps是一种基于麻利准则的新文化,它在较短的工夫内器重软件的办法、过程和品质。 为什么DevOps的转变对组织来说会如此艰难?DevOps之旅对大多数组织来说都是苦楚的,因为:●人们抗拒转变●团队不协调及精力有限●对自动化不切实际的期待●专一于上述因素,就能够逐渐在组织中为DevOps营造一个建设性的气氛。 自动化被误会了咱们常常听到DevOps应用CI(继续集成)和CD(继续交付)来自动化软件开发管道。但这只是局部假相。毫无疑问,DevOps指的是软件开发、测试和部署的自动化,但这并不意味着不须要人工智能和合作。尽管有些流程能够毫不费力地实现自动化,但有些流程须要高级性能。记住“导致devops失败的往往是人,而不是流程”,Gartner钻研总监George Spafford如是说。为了在竞争中取得劣势,应该关注软件开发的品质。自动化是必不可少的,并且通过打消冗余工作节俭了您大量的工夫和精力。然而,更重要的是质量标准,通过人和机器独特保护。在这里,人们能够帮忙将提议的开发图与开发的零碎相匹配,这样他们就能够更加关注客户的满意度。 扭转不是久而久之产生的,要循序渐进你不能指望在一两天内就能胜利实现DevOps。它可能须要几天、几周甚至几个月的工夫能力成熟。在这里,“将DevOps视为一种哲学”能够帮忙建设一种心态——以迟缓而动摇的心态帮忙企业实现基本扭转。 软件不再只停留在网页端和挪动端范畴内。它正在超过机器学习、人工智能、大数据分析、物联网的崛起。 在数字时代,须要继续的分割和以品质为导向的心态。在这样的场景中,DevOps之类的概念能够让您取得同步的益处,从而通过以客户为核心的软件解决方案交付价值。 不要仅为了更快的交付而施行DevOps,须要做的是:●确认DevOps的真正劣势●依附“DevOps哲学”来带来文化改革●为组织定义自动化和合作●在进行下一步工作之前,留神整体基础设施●确定指标和衡量标准●不要胆怯失败●开发整个工具链并培训员工 人员和流程必须依照独特的思维形式工作,以便向最终用户交付价值。这个准则实用于任何类型的软件开发。 作者:陈琦,资深麻利测试参谋,作为国内出名项目管理软件——禅道的团队成员,次要负责开源自动化测试治理框架——ZTF的开发工作。领有十多年的麻利过程实践经验,现致力于测试自动化和DevOps相干畛域的实际和钻研。

September 14, 2020 · 1 min · jiezi

关于devops:中国-DevOps-社区-CODING-深圳第九届-Meetup-来啦

号外号外! 中国 DevOps 社区 & CODING 深圳第九届 Meetup 来啦! 本次以 「DevOps 转型与实际」 为主题的技术沙龙流动,由腾讯云旗下一站式 DevOps 开发平台 CODING 和中国 DevOps 社区主办,邀请了四位来自世界 500 强或国内外知名企业的技术大咖,独特探讨在 DevOps 的大潮流中,各公司如何攻克常见的企业痼疾本源,实现转型与落地实际 DevOps,进步研发效力。 流动工夫: 9 月 19 日(周六)13:30 - 17:00 流动详情及报名形式详见下图海报 Attention转发本次流动链接至朋友圈(未屏蔽分组),并增加下方微信小助手二维码,发送暗号 【0919】 和 朋友圈截图,即可获取收费门票! 奖品除了大咖演讲分享,流动现场还有惊喜抽奖环节!侥幸观众能够取得的奖品包含—— DevOps 浏览系列: 1)《DevOps 实际指南》x 5 本 2)《麻利无敌之 DevOps 时代》x 2 本 3)《京东麻利实际指南》x 5 本 4)《麻利转型》x 3 本 5)《绩效跃升地图》x 3 本 6)《DevOps 成长地图》x 3 份 CODING 及合作伙伴纪念品: 7)CODING 猴子抱枕纪念品及流动贴纸 8)猫爪杯、挂脖风扇 ...

September 10, 2020 · 1 min · jiezi

关于devops:GoCenter为Go-moudles加速

一、背景Go语言是Google开发的一种动态强类型、编译型、并发型,并具备垃圾回收性能的编程语言。为了不便搜寻和辨认,有时会将其称为Golang。自2009年11月Google正式发表推出,成为凋谢源代码我的项目以来,Go语言已成为当今开发人员和DevOps畛域最风行的语言之一, 它被用于设计和编写Kubernetes和Helm。 然而,相比语言自身曾经失去了宽泛的遍及和应用,Go语言的包治理计划却大大滞后了。2018年Google终于在Go1.11官网推出了Go modules,为Go语言提供了反对版本化的依赖治理计划。 Go modules当初已成为Go语言规范的依赖管理工具和包仓库标准。而GoCenter为Go modules的实现和推广提供了依赖包的公共仓库,使得Go语言的开发人员可能更为稳固和不便地开发可反复构建的Go应用程序。 除了提供Go仓库外,在获取和下载Go module包方面,GoCenter提供了比传统的如GitHub等版本管理系统更为疾速的反对。 二、验证GoCenter速度的测试为了验证GoCenter提供了更快获取Go modules的形式,咱们设计了如下测试计划: 1、咱们选取了两个Go我的项目,用以比拟不同我的项目规模下速度的不同。一个是公有我的项目,webhook-bridge(https://github.com/retgits/webhook-bridge);一个是公共我的项目,动态站点生成器Hugo(https://github.com/gohugoio/hugo)。 2、咱们在两个网络环境下别离执行测试,用以比拟不同网络条件下速度的不同。一个是JFrog的公司网络,一个是家庭网络。 3、构建Go 我的项目通常蕴含两步,第一是下载依赖,第二是编译可执行程序。本次测试集中在第一局部,Go依赖包的下载速度。为了使测试尽可能偏心和不间断, 咱们编写了一个脚本, 在运行“go get”之前删除了所有模块,而后对于同一个我的项目别离应用 GitHub和GoCenter来获取依赖。这些命令将运行10次, 后果记录在文件中。测试应用的脚本参见https://github.com/xingao0803/GoCenter-Performance/blob/master/testscript.sh。 同时,为了保障测试的公正性,咱们测试的时候并没有告诉GoCenter团队。他们既不能对测试所用的我的项目或模块产生影响,也无奈篡改咱们的测试数据。 三、测试后果测试后果的具体列表参见https://github.com/xingao0803/GoCenter-Performance/blob/master/GoCenter-performance.xlsx。在这里,咱们统计一下,列出每个我的项目的最快和最慢运行之间的差别。 1、公有我的项目的测试后果 在JFrog公司网络测试公有我的项目: 越小越好 GoCenter/GitHub 用户模式下CPU秒数 内核模式下 CPU秒数 CPU占比 总运行秒数 比拟最慢运行 0.18 0.29 0.83 0.30 比拟最快运行 0.18 0.29 0.69 0.26 在家庭网络测试公有我的项目: 越小越好 GoCenter/GitHub 用户模式下CPU秒数 内核模式下 CPU秒数 CPU占比 总运行秒数 比拟最慢运行 0.16 0.30 0.83 0.42 比拟最快运行 0.17 0.29 0.53 0.23 最初一列“总运行工夫”,是测试下载Go我的项目依赖包并放入正确地位的工夫。从上述统计能够看出,通过GoCenter获取Go modules依赖比从GitHub获取速度更快,耗费资源更少。 这个公有我的项目只有6个间接依赖和12个间接依赖的Go module。如果应用更大规模的我的项目,如Hugo,包含43个间接依赖和11个间接依赖,成果又会如何呢? 2、Hugo我的项目的测试后果 在JFrog公司网络测试公有我的项目: 越小越好 ...

August 27, 2020 · 1 min · jiezi

关于devops:如臂使指勇往直前-使用Helm-Charts的最佳实践

一、背景Kubernetes是由谷歌开源的容器集群管理系统,是目前最为风行、成为事实标准的旨在主动部署、扩大和运行利用容器的开源平台。咱们晓得,容器(Container)的转义是“集装箱”,而Kubernetes的名字则来源于希腊语中的“舵手”。正如名字所预示的,咱们心愿Kubernetes这个舵手可能帮忙咱们把装满集装箱(利用容器)的货轮(容器集群)顺利、安稳地驶向目的地。 好舵手的胜利驾驶,离不开得心应手的工具——船舵,而利用的Helm charts(Helm的转义就是操作船舵的方向盘),无疑为Kubernetes这个舵手提供了如臂使指的好工具。Helm charts是能够从Helm仓库获取的一个文件汇合,用以形容利用对应的一组互相关联的K8s资源。以最无效的形式制作利用的Helm charts,可能助力Kubernetes在将利用容器部署到生产环境时逾越浅滩、畏缩不前。当然,正如咱们开发那些用以部署产品的公开公布的K8s charts时所发现的那样,某些不当的Helm charts也会导致咱们的容器货轮到处流浪、彷徨不进。 在开发过程中,每次提交拉取申请(PR,Pull Request)时Helm社区提供的反馈,都指引咱们采纳某些Helm charts的最佳实际,从而使得运维和更新利用容器都取得了现实的成果。当编写为社区或客户应用的公开公布的K8s charts时,以下这些事项是须要认真思考的: · 须要定义哪些依赖关系? · 利用是否须要保护长久化的状态? · 如何通过私密和权限来解决安全性? · 如何管制运行中的容器? · 如何确保利用试运行的,而且可能接管申请? · 如何对外公开利用提供的服务? · 如何测试编写的K8s charts? 本文列出了咱们开发过程中利用的一些最佳实际,使得开发出的Helm charts可能具备更好的结构化和针对性。心愿这些实际可能帮忙K8s驾驶您的容器货轮顺利地达到此岸。 二、起步在启航之前,心愿你能首先相熟开发Helm charts的基本概念和过程。请参考Helm的官网文档,https://helm.sh/docs/developing_charts/。 在本文中,咱们将遵循这些最佳实际来创立一个Helm chart,用以部署一个基于Express.js框架的,两层的,针对Mongo数据库进行增、删、改、查(CRUD)的利用。该利用的示例代码位于https://github.com/jainishshah17/express-mongo-crud。 三、创立Helm chart并填写chart信息3.1 创立模板首先,利用helm客户端的create命令创立咱们的helm chart模板: $ helm create express-crud 该命令将会为名为“express-crud”的Helm chart创立相应的目录构造。 3.2 填写chart信息批改刚刚生成的模板目录中的Chart.yaml文件,增加形容chart信息的元数据,包含失当的: · apiVersion(必选):chart应用的Helm API的版本,目前固定为“v1”; · 名称name(必选):Helm chart的名称; · 版本version(必选):Helm chart的版本,是合乎语义化版本2.0的版本字符串; · 形容description(可选):对Helm chart利用范畴的形容; · 利用版本号appVerions(可选):Helm chart蕴含的利用版本,可用作对应的docker镜像的标签tag(能够不遵循语义化版本的命名规定); · 源码地位source(可选):我的项目源代码的地位; · 维护者maintainer(可选):记录Helm chart维护者的根本信息; · 图标icon(可选):为Helm chart选个个性化的图标吧。 ...

August 27, 2020 · 6 min · jiezi

关于devops:Helm-在Kubernetes中部署应用的利器

一、背景Kubernetes(k8s)是一个基于容器技术的分布式架构当先计划。它在Docker技术的根底上,为容器化的利用提供部署运行、资源调度、服务发现和动静伸缩等一系列残缺性能,进步了大规模容器集群治理的便捷性。 在容器云环境及容器化服务在业界开始大规模部署利用的前提下,Kubernetes在业界的理论利用状况又是怎么的呢?在往年召开的JFrog SwampUp用户大会上,Codefresh公司为大家展现了一些有意思的数据。如下图: 据Codefresh公司统计,在目前JFrog的企业用户当中,有80%曾经应用了Kubernetes,这阐明Kubernetes曾经失去了业界的认可并开始了宽泛的利用。然而,只有5%的JFrog用户在生产环境中应用Kubernetes。也就是说,企业更多的只是在本人的研发、测试环境中去应用 Kubernetes。这是什么起因呢?JFrog通过本身在Kubernetes利用上的大量实践证明,“Kubernetes is hard”,间接应用Kubernetes去部署和治理容器化的云服务,尤其是基于微服务的云服务,是十分具备挑战性的工作。 那如何能力更便捷地利用Kubernetes呢?JFrog抉择了Helm,Kubernetes的官网包管理工具。咱们再来看Codefresh提供的另一组数据,如下图: 和上一组数据一样,只有5%的JFrog企业用户在生产环境应用了Kubernetes。但同时,也有5%的JFrog用户应用了Helm。可见,当把Kubernetes利用到生产环境的时候,泛滥企业也和JFrog一样,抉择了Helm这一“利器”。 为什么Helm会受到这样的青眼?本文将通过JFrog施行Helm和Kubernetes的实际来介绍和剖析Helm的劣势所在。 二、Helm是什么在介绍Helm之前,咱们先来看看间接利用Kubernetes部署云服务会遇到哪些艰难。 Kubernetes应用yaml文件来形容和治理服务中各个组件的配置和部署需要,每个组件对应一个yaml文件。当下的云服务通常都是由多个组件形成的,如何配置和解决好这些组件,也就是多个yaml文件之间的关联关系,成为了Kubernetes利用的额定工作。而当云服务降级,却仅仅波及其中一个或某几个模块时,降级模块的新yaml文件和已有yaml文件之间的关联关系就会变得更加盘根错节,从而更减少了应用Kubernetes来配置和治理降级的难度。 其次,Kubernetes把组件的配置信息也间接记录到yaml文件当中。从形容组件的角度来讲,这种形式的确比拟清晰。然而,当云服务的部署面对多个环境,如不同的开发、测试、产品环境(这也是以后比拟常见的利用场景)时,要如何解决这些环境配置之间的差异?要为每个环境都开发和保护一套不同的yaml文件?这显然大大增加了利用Kubernetes的难度和工作量。 而且,Kubernetes的yaml文件自身是没有版本的概念的。那么当某次部署失败,须要回滚到上一个稳固版本时,该抉择哪一套yaml文件来解决?显然,这须要很多额定的工作来解决。 那Helm是如何来解决这些问题的呢? Helm(https://helm.sh)是Kubernetes的官网包管理工具。Helm是通过被称作Helm Chart的包来形容和治理云服务的。Helm Chart对应的是一组结构化的目录和yaml文件,而这些目录和文件大抵可分为三个局部: 1、模板 在templates目录下寄存着一组用来形容云服务当中各个组件的yaml文件,这和目前Kubernetes的用法相似。Helm把这些yaml文件组织在同一目录,可能很不便地理解以后云服务的组成,构造清晰且便于管理。 2、配置与依赖 templates目录下的yaml文件是不蕴含具体的配置信息的,只保留了对配置项(key)的援用。真正与指标环境对应的配置信息(value)是存储在values.yaml文件里的。当然,values.yaml只是存储了一些缺省的、动态的配置信息,在部署的过程中也能够动静地减少或批改这些配置信息。这种配置与利用拆散的设计使得同一套templates能够不便地部署到不同的指标环境中,只须要更新values.yaml文件或部署时动静批改配置信息就能够了。 另外,针对某些已被宽泛应用的云服务或组件,目前曾经存在比拟成熟、通过验证的Helm Chart了。当应用到这些服务或组件时,能够间接在requirements.yaml文件里形容这种依赖关系。在部署的时候,Helm会主动获取这些依赖的Helm Chart应用,并存储在charts目录。这种依赖性的设计,防止了很多重复性的工作,也使得Helm Chart的并行开发和共享成为可能。 3、版本化 每一个Helm Chart包都能够在Chart.yaml文件里定义本人的版本。另外,每一次 Helm的部署都会主动生成一个版本(release)。应用Helm的命令,能够不便地实现这些已部署版本的查问、降级、回滚和其余治理工作。 三、Helm的利用实际通过上面对Helm的介绍和剖析能够看出,Helm可能很好地解决Kubernetes利用部署的难题。JFrog在本人的Kubernetes实际当中也充沛应用了Helm。 目前,在JFrog各个产品本身的CI/CD流水线上都应用Helm进行Kubernetes上的部署,曾经能够实现每周100+不同产品线的任意版本组合部署,每次部署超过50种微服务。JFrog也将为客户提供这些Helm Chart,以帮忙客户在Kubernetes环境疾速部署JFrog的各种产品。 在实际Helm的过程中,JFrog也积攒了一些教训和最佳实际。 1、配置与利用拆散 针对所有的环境应用同样的Helm Chart,然而依据不同的环境配置本人特定的values.yaml文件。同时,依据指标环境的变动对这些values.yaml文件进行版本化的治理。 2、善用依赖 目前曾经有很多产品和通用组件都实现了比较完善、通过验证的Helm Chart,能够在https://hub.kubeapps.com里找到。咱们在开发本人的Helm Chart时,能够通过定义依赖来充沛地利用这些已有的成绩,在缩小工作量的同时,也能进步产品的品质。 3、在理论部署前查看Helm Chart Helm提供了很多实用的命令来帮忙咱们在理论部署之前查看Helm Chart里的谬误,升高应用的危险。比方: · helm lint <chart path> helm lint能够用来查看下载的Helm Chart是否存在问题 · helm install –debug –dry-run <chart> ...

August 27, 2020 · 1 min · jiezi

关于devops:你的应用安全吗-用Xray和Synk保驾护航

一、背景在当下软件应用的开发过程当中,自研的外部代码所占的比例逐渐地缩小,开源的框架和共用库曾经失去了宽泛的援用。如下图所示,在一个Kubernetes部署的利用当中,咱们本人开发代码所占的比例可能连0.1%都不到。 开源软件可能帮忙开发者共享彼此的成绩,使得咱们可能疾速复用其他人开发并已失去验证的软件库,从而可能集中精力专一于创新性的工作。然而,开源软件的大量援用也给咱们的利用带来了安全隐患。平安检测已成为以后DevOps流程的重要组成部分。 二、你的利用平安吗据不齐全统计,当初有78%的企业都在应用开源软件。然而,大家在享受开源软件带来的研发便当的同时,是否也意识到开源软件带来的安全隐患呢? 从上图的统计数据能够看出,只有13%的企业会把平安放在援用开源软件时的首要关注点。大部分的使用者抉择置信开源软件的发明和维护者会保障其安全性。然而,下图的统计数据表明,安全性并不是开源软件维护者的保护重点。 这样的现状导致咱们罕用的开源软件库蕴含了各种各样的安全漏洞,例如,据统计,目前14%的NPM包、30%的Docker Hub镜像都蕴含安全漏洞。而且在这些破绽被发现之后,也得不到及时的修复。据统计,Maven包里有59%的已知安全漏洞还没有失去修复,而破绽的均匀修复工夫是290天,最重大级别破绽的均匀修复工夫也仅是265天。黑客们已逐步把开源软件作为了次要的攻打指标。 该怎么样保障咱们上线利用的平安呢? 三、JFrog Xray,监测安全漏洞的利器JFrog公司提供的Artifactory+Xray是一个很好的产品组合。Artifactory是全语言的制品仓库,可能在同一个仓库中存储和治理咱们利用研发中应用的所有内部依赖包。而Xray通过对Artifactory的监督,可能在构建,甚至开发阶段就发现安全漏洞问题,使得平安监测前置,防止了在利用上线前紧急排查问题的困境。 如上图所示,当Artifactory仓库中新退出了制品包,设置了对其监督的Xray就会启动安全检查,并报告查到的安全漏洞和License受权状况。而针对安全漏洞,Xray会提供具体的破绽信息,以及在利用中的精确定位来辅助咱们对其进行剖析和查看。 同时,针对查出来的安全漏洞,Xray还提供了针对其扩散范畴的剖析。也就是说,能够帮忙咱们剖析,出了被查看的这个制品包外,还有哪些其余的利用也蕴含了这个安全漏洞。 除了安全漏洞及其扩散范畴的剖析,Xray还提供自定义问题的能力。咱们能够把用其余工具发现的平安问题,或者如性能过低、版本过老等非平安问题定义在对应的制品包上,同样也能够利用Xray的能力查看这些问题在咱们的利用中的扩散范畴。 四、Snyk, 不仅仅是监测破绽 JFrog Xray是基于开源的NVD开源破绽数据库来监测安全漏洞的,而Snyk(https://snyk.io)提供了额定的商业破绽数据库。Xray能够通过和Snyk的集成,实现利用Snyk的商业破绽数据库进行安全漏洞查看。 当然,基于本身的商业破绽数据库,Snyk也提供了安全漏洞的扫描和监测能力。Snyk提供了与各种各样平台的集成,帮忙咱们监测部署在这些平台上的利用平安。 然而,Snyk的能力不仅如此,他还能帮忙咱们修复安全漏洞。例如,当和咱们的Github Enterprise集成后,咱们能够抉择咱们须要监测的我的项目。 选定后,Snyk就会主动扫描咱们的代码并报告在我的项目当中发现的安全漏洞。 Snyk最大的特色是,针对这些安全漏洞,可能主动给出PR(Pull Request)模式的修复倡议。PR既能够针对所有发现的破绽,也能够只针对某一个具体的破绽。 间接Merge这些PR就能够帮忙咱们替换应用已修复安全漏洞的依赖包,实现安全隐患的主动打消。 五、总结 开源软件的大量援用,在不便了利用开发的同时,也带来了平安的隐患。利用JFrog Xray和Snyk等工具,可能帮忙咱们尽早地发现开源依赖引入的安全漏洞,剖析破绽的扩散范畴,也能够给出修复倡议,实现安全隐患的主动打消。 参考文献· Xray and Snyk - Don’t just scan … Fix! https://www.youtube.com/watch... · JFrogXray试用地址 http://www.jfrogchina.com/artifactory/free-trial/ 欢送观看JFrog杰蛙每周二在线课堂,点击报名: https://www.bagevent.com/even...

August 24, 2020 · 1 min · jiezi

关于devops:GoCenter助力Golang全速前进

一、背景Go语言是Google开发的一种动态强类型、编译型、并发型,并具备垃圾回收性能的编程语言。为了不便搜寻和辨认,有时会将其称为Golang。自2009年11月Google正式发表推出,成为凋谢源代码我的项目以来,Go语言已成为当今开发人员和DevOps畛域最风行的语言之一, 它被用于设计和编写Kubernetes和Helm。然而,相比语言自身曾经失去了宽泛的遍及和应用,Go语言的包治理计划却大大滞后了。 Go语言生态系统中短少的是标准化——没有用于依赖关系治理的规范工具, 也没有规范的包格局或兼容的包仓库标准。这意味着开发人员无奈应用Go语言创立可重现的构建, 这是一个相当大的问题。这些年来, 社区推出了诸如dep、godep、glide和govender等工具,试图用来解决Go语言的依赖治理, 但并未胜利。2018年Google在Go1.11官网推出了Go modules,为Go语言提供了反对版本化的依赖治理计划。 Go modules当初已成为Go语言规范的依赖管理工具和包仓库标准。而GoCenter为Go modules的实现和推广提供了依赖包的公共仓库,使得Go语言的开发人员可能更为稳固和不便地开发可反复构建的Go应用程序。 二、Go语言的依赖治理在介绍GoCenter之前,咱们先简要地回顾一下Go语言依赖治理的倒退历程。 Go语言在推出之初,并没有明确的依赖治理计划。只是在构建过程中通过go get命令,将用import申明的依赖从对应的源,通常是git上的我的项目,下载到$GOPATH/src目录下,和Go利用本身的代码放在一起。这种依附GOPATH来治理依赖的机制带来的问题 是不言而喻的,比方: · 因源依赖包本身的变动,导致不同工夫构建Go利用时go get失去的依赖本质上是不同的,即不能实现可反复的构建; · 或者因源依赖包本身的变动,从新构建Go利用时会引入不兼容的新实现,导致Go利用无奈通过编译。 因而在1.5版本以前,为了躲避这个问题,通常须要将应用的依赖包手工拷贝进去。 为了实现Go利用的可反复构建,Go1.5引入了Vendor机制。Vendor机制的外围就是在GOPATH上面减少了vendor文件夹。Go利用所需的依赖都能够从依赖源fork出所需的分支,寄存到vendor文件夹。当构建Go利用时,Go编译器会优先在vendor文件夹下搜寻依赖的第三方包,vendor文件夹下没有才会再到$GOPATH/src上来找。这样只有开发者事后将特定版本的依赖包寄存在vendor文件夹,并提交到Go 我的项目的code repo,那么所有人实践上都会失去同样的编译后果,从而实现可反复构建。 在Go1.5公布后的若干年,Go社区把注意力都集中在如何利用Vendor机制解决Go利用的依赖治理问题,并诞生了泛滥的依赖管理工具,如dep、golide、govendor等。然而,和Java的Maven、Python的Pypi、C/C++的Conan等业界成熟的依赖治理计划相比,Vender机制依然存在许多问题,比方: · Vendor文件夹中的依赖包没有版本信息。这样依赖包脱离了版本治理,对于一致性治理、降级,以及问题追溯等场景,都会难以解决; · Vendor机制没有给出如何可能不便地失去Go我的项目依赖了哪些包,并将其拷贝到vendor文件夹下的计划,少数状况下还须要到不同的Git源我的项目里手工拷贝; · 当依赖的包比拟多的时候,vendor文件夹也会变得十分宏大。 2018年年初,Go外围Team的技术leader,也是Go Team最晚期成员之一的Russ Cox在集体博客上间断发表了七篇文章,系统阐述了Go team解决“包依赖治理”的技术计划:vgo。vgo的次要思路包含:语义导入版本控制(Semantic Import Versioning)、最小版本抉择(Minimal Version Selection)、以及引入Go module等。同年5月份,Russ Cox的提案“cmd/go: add package version support to Go toolchain”被社区承受,vgo的代码合并到Go骨干,并将这套机制正式命名为“go modules”。因为vgo我的项目自身就是一个试验原型,merge到骨干后,vgo这个术语以及vgo我的项目的使命也就此结束了。后续Go modules机制将间接在Go骨干上持续演变。 Go modules机制的次要变动包含: · 去除了饱受诟病的GOPATH的限度。Go编译器将不再到GOPATH上面的vendor或src文件夹下搜寻Go利用构建依赖的第三方包; · Go modules机制为在同一利用repo上面的包赋予了一个新的抽象概念: 模块(module),即可重用的Go代码包,并启用一个新的文件go.mod记录模块的元信息和依赖关系。而在go.mod里明确形容了依赖包的版本信息,同一个依赖包也能够记录多个不同的版本。除了准确版本外,go.mod还反对用表达式模糊地定义依赖版本; · 在Go modules机制下,还反对创立Go依赖包的公共仓库。这是因为应用程序蕴含的Go模块,必须从数千个独立的源代码存储库中解析,而每个存储库的保护纪律可能各不相同。因而,须要存在一个可公开拜访的存储库,通过Go modules提供的依赖形容、解析机制,为Go的开发者提供统一的、可分享的、反对反复构建的、稳固的Go依赖包源。GoCenter就是这种Go依赖包公共仓库的重要实现。 三、GoCenter简介GoCenter通过创立Go模块的公共地方仓库,提供可反复和疾速依赖解析的依赖包治理计划,解决了Go开发人员查找和获取Go依赖包的艰难。GoCenter将间接从源代码存储库获取Go我的项目,转变为解决和验证不可变的、具备版本控制的Go模块, 并将其收费提供给Go利用的开发人员。 GoCenter(https://gocenter.io)提供了通过公共Go代理解析模块, 包含通过托管收费服务搜寻模块的能力。从创立开始, GoCenter曾经包含了数千个广受欢迎的 Go我的项目的模块, Go开发者能够立刻应用这些我的项目进行本人的构建。 ...

August 20, 2020 · 1 min · jiezi

关于devops:德国老牌制造企业西门子如何使用-Artifactory-进行单一可信源的建设

1. 背景在3年前,西门子公司外部存在不同的工具来寄存他们的制品: 有的团队放在TFS 上托管制品,然而从实践上来说,TFS并不适宜用来托管制品。有的团队将他们的制品托管在他们的Clear Case中。还有的团队创立了不同的共享文件夹,并将他们的制品寄存在外面。这样的现状带来很多问题,例如: 所有的工具都须要满足一些重要的公司要求,例如如何保障制品的平安? 如何将制品分享给其余我的项目团队?如何满足所有的合规性要求?如何升高治理老本?如何为开发者们进步零碎的性能和可用性?综上所述,对于西门子公司而言,创立一个对立的地方仓库来治理制品是很有必要的。 2. 解决方案西门子应用 JFrog Artifactory作为繁多可信源,存储西门子寰球所有的制品,反对 6000 研发,250 个我的项目团队,43 个 Artifactory 节点。 当你有了好的工具,在大公司里提供制品库服务的时候,还须要其余的服务能力,包含高可用性,和 CI/CD 集成,培训,自助式服务的体验。 西门子 IT 部门花了在这方面做了很多工作,对于开发者,IT 团队提供了: 0 宕机的繁多可信源制品库n 主动巡检 Artifactory 首页的可用性 n 主动上传测试制品保障制品库的可用性,如果 3 次测验均失败,在证实 Artifactory 服务处于不衰弱状态。 n 运行模仿的制品上线,散发的过程,并且验证权限。 对开发者提供onboarding 的培训定制化,提供和 CI/CD 工具的集成技术支持和培训对于我的项目方的经理,IT 团队提供: 我的项目资源的整体状况(机器,存储,数据库,Artifactory 节点数)我的项目 onboard服务我的项目的保护配合我的项目进行翻新在Artifactory监控方面,IT 团队用了ELK 进行日志的剖析,疾速定位问题。 通过监控,也能够看到一些乏味的数据,比方下载最多的包是什么,哪个团队的部署频率最快等等。 3. 收益 应用 Artifactory 之后,西门子达成了以下收益: 在西门子建设了繁多可信制品库第三方制品库有了惟一的中央进行破绽扫描和 License 扫描缩小了反复的IT 建设,由一个团队负责满足了法律的合规性满足的平安的需要寰球对立的制品库服务缩小了企业的老本***欢送观看JFrog杰蛙每周二在线课堂,点击报名: https://www.bagevent.com/even...**

August 17, 2020 · 1 min · jiezi

关于devops:DevOps最佳实践建设单一可信源

怎么了解繁多可信源呢?通过思考之后,笔者感觉用咱们小时候最常听到的一句话来形容:“事实的假相只有一个”,没错,就是柯南的这句话,来形容繁多可信源最为贴切。繁多可信源这个概念其实很早就被各个行业所提出,尤其是在身份管理系统中(比方咱们的身份证),打造繁多可信源能够说是重要的一项工作。那么什么是繁多可信源呢?咱们先来理解上面两个概念 Single source of truth(SSOT)SSOT是在信息系统的设计实践中,构建信息模型和关联模式的实际,确保每个数据元素只能在一个中央把握。 Single version of truth(SVOT)SVOT是一种向决策者提供清晰精确的数据的实际,确保数据的准确性、唯一性、及时性、对齐性等。 繁多可信源与下面两个概念有什么关系呢, “繁多可信源”中的两个形容词“繁多”与“可信”是本文须要探讨的两个关键词。咱们分这两个维度来阐明: 繁多“繁多”对应的实践是SSOT,保障咱们信息是从一个繁多及对立的地位获取。 落地到DevOps中,须要咱们的数据资产有对立的源码仓库、制品仓库、文档等管理体系,并且要笼罩研发环境及生产环境,确保软件开发整个生命周期的数据资产治理的连续性。该对立体系须要在组织内共享,并将积攒的常识与教训在组织内复用。 可信“可信”对应的实践是SVOT,确保咱们获取的信息是真实可信的,具备权威性的。 落地到DevOps中,须要咱们软件、版本在部署到测试或生产环境时都是可信的,其中可信蕴含两个方面,品质与平安。 可信品质: 指开发过程中的代码品质、测试通过率、审批后果、合规性、所属人等。 可信平安: 指开发过程中的代码平安危险、内部依赖平安危险、开源许可证合规性危险、开源软件应用危险、动静利用平安危险等。 如果企业不建设DevOps体系的繁多可信源会导致什么问题呢? l 信息孤岛,生产率降落 大研发团队波及的所有人员没有繁多的版本获取地位。对于协同开发的团队,该问题愈发显著,代码及版本存储地位扩散,导致获取工夫缩短,生产率降落 l 谬误频出,代价昂扬 大研发团队波及的所有人员没有没有可信的版本获取地位。尤其是对于运维人员,获取的版本如果不可信,会导致公布故障频出,修复代价昂扬。 企业建设DevOps体系的繁多可信源会有什么收益呢? l 对立治理、进步生产率 信息很容易在繁多可信源中获取,缩小应用老本,防止反复造轮子、节约生产力 l 故障修复成本低 品质可信、平安可信。开发过程中能够做到全流程品质及安全监控,保障交付物内建品质高标准。升高沟通老本,缩小保护及修复工作量。 DevOps中落地“繁多可信源”的最佳实际与案例 参考 《CapitalOne – 千亿资产银行如何进行惟一可信源的建设》 《从凌乱到有序 –AppsFlyer如何通过惟一可信源改良制品治理》 **欢送观看JFrog杰蛙每周二在线课堂,点击报名: https://www.bagevent.com/even...**

August 14, 2020 · 1 min · jiezi

关于devops:JFrog助力Google-Anthos混合云Devops实践实现安全高质量的容器镜像管理

自Google Anthos推出以来在混合云畛域受到极大关注,作为Google进入ToB混合云市场的策略级产品,Anthos集成了如GKE (Google Kubernetes Engine)、GKE On-Prem、Istio on GKE等……引起业界的关注。能够说这又是Google又一大利器。那么混合云作为企业数字化转型的重要基础设施建设,既留了外围数据,升高了迁徙危险,又能在原来资源的根底上减少公共云的弹性,一举多得,成为以后云计算倒退的热门话题。而作为数字化转型的另外一个风向标DevOps如何与以后的混合云倒退进行合作,带向企业进入云原生时代,将会成日今后数字化建设的一个重要主题。 JFrog交融Anthos平台实现混合云下的利用镜像同步============================ Google Kubernetes Engine,这是Anthos进行核心指挥的控制中心。客户应用GKE管制立体来治理在谷歌的云、外部数据中心和其余云平台上运行的分布式基础设施。GKE On-prem提供了一个与GKE统一的基于kubernetes的软件平台负责用户公有资产局部的基础设施治理。作为以容器为根底的混合云平台,利用容器化后如何同步并放弃私有云和公有云的镜像一致性方面,JFrog起了关键作用。JFrog Enterprise解决方案以其Artifactory通制品管理器为外围,反对镜像仓库以及Helm,以无缝形式桥接这两个环境,从而平安地,间断地将生产就绪的应用程序交付给Kubernetes。 JFrog作为寰球首个反对混合云环境的多语言制品治理平台,为Google Anthos平台提供平安的,自动化,高性能的容器利用镜像管理中心,为GKE用户提供一致性的镜像治理体验。 JFrog与Anthos的CloudDevops计划 在这种混合架构中,来自不同产品团队的开发人员能够在Google Cloud Platform上构建其应用程序,并应用测试数据对其进行验证。GCP上的Artifactory在构建过程通过软件交付管道进行治理时,可对构建的受信赖存储库进行治理,并通过XRay扫描会验证没有已知的安全漏洞,并且所有许可证都合乎企业的合规性策略。 一旦确定了应用程序的合规性和安全性,它就会被推广到在GKE On-Prem上运行的Artifactory,在那里能够将其平安地部署到生产K8s集群中。该应用程序将在公司本人的数据中心内运行,并且能够依照政府法规的要求拜访防火墙后爱护的敏感数据。 整个pipeline流程: 一 开发侧1开发人员在版本控制系统(例如GitHub)中保护利用程序代码 2当开发人员提交代码更改(即“提交”)时,它将触发新的构建工作 二 On Cloud的平台工作流:CI Server(例如,Jenkins)执行构建过程 JFrog Artifactory: 1从存储在Google Cloud Storage中的代理存储库中提取依赖项将利用包和最终构建映像推送到存储在Google Cloud Storage中的存储库 2 将每个镜像的元数据(“构建信息”)存储到Google Cloud SQL数据库中,以跟踪构建映像。 3 Artifactory部署在具备三个或更多负载平衡节点的高可用性配置中,以确保在高负载下疾速响应,并可能在零停机工夫内执行降级和保护。 4 CI Server应用并保护Artifactory元数据,以通过GKE主动部署构建的映像以测试群集。胜利验证构建后,CI服务器会将构建晋升(复制或挪动)到Artifactory中的下一阶段制品库 5 JFrog Xray - 扫描构建映像是否存在安全漏洞,以及组件是否合乎组织的许可策略。 - 利用VulnDB,这是由基于危险的安全性创立,保护的最全面,最新的破绽情报。 - 发送检测到违规的警报。这些警报能够触发Webhook采取行动,或者能够阻止违反映像的部署。 7 Artifactory将通过齐全验证的镜像和Helm chart表推送到复制到On-Perm的Artifactory中 三 On-Perm工作流1 On-Perm Artifactory承受来自On Cloud的合规合质的Release版本的镜像。 2 Spinnaker(或其余间断交付工具)驱动service/job的更新,从Artifactory中的存储库中提取受信的容器镜像和Helm chart。 ...

August 14, 2020 · 1 min · jiezi

关于devops:容器云环境你们如何监控应用运行情况-JFrog-云原生应用监控实践

引言自从2018年从Cloud Native Computing Foundation(CNCF)呈现以来,您可能曾经在应用K8操作系统,随着容器云技术大倒退以及落地,进步了企业运维的效率和品质,并且升高了企业经营老本,但同时带来的问题是运维的复杂度和难度,举个例子????:因为容器的生命周期短,随时可能飘移到其余物理资源上运行,因而日志的采集和运行的监控很难像传统形式登录到服务器上查看,而经营团队须要理解有价值的数据来进行问题定位以及经营数据分析。 为了更宽泛地提供这种可察看性,咱们须要提供满足云原生环境下的监控能力。 JFrog 通过应用Elasticsearch和Kibana套件,以及Prometheus 和Grafana套件来监控Artifactory 制品库以及Xray 破绽扫描工具的运行状况,上面咱们一起理解JFrog 如何在云原生环境进行利用运维。 日志剖析Easticsearch是一个分布式且可扩大的搜索引擎,可用于搜寻全文,结构化文本和剖析。它通常用于搜寻大量数据以及搜寻不同类型的文档。 Kibana是Elasticsearch最罕用的可视化和仪表板。Kibana使您可能通过构建可视化和仪表板的Web UI摸索Elasticsearch日志数据。 上面咱们将向您展现如何利用同类最佳的开源日志剖析技术:Elastic,Fluentd和Kibana为经营团队提供100%收费的开源日志剖析平台 首先应用Fluentd,咱们提供了与开源数据收集器Fluentd 的JFrog日志剖析集成配置,该集成可随JFrog Platform部署的每个产品实例装置。Fluentd在JFrog平台中为每个产品执行日志输出,字段提取和记录转换,从而将该数据的输入标准化为JSON。 因为所有日志数据均以这种通用格局提供,因而Fluentd将通过Fluentd的可插入体系结构将其传送到您的Elasticsearch剖析工具。 装置FluentD装置FluentD,每个JPD(JFrog Platfrom Deployment)节点都须要装置Fluentd日志记录代理。该代理将负责为新的日志行增加各种JPD日志文件以解析到字段中,利用相应的记录转换,而后发送到Fluentd的相干输入插件。 例如,对于运行Red Hat UBI Linux的节点,td-agent必须装置Fluentd代理。对于基于root的程序包管理器(须要root拜访): $ curl -L https://toolbelt.treasuredata... | SH 配置FluentD依据咱们是刚刚实现基于根的装置还是基于非根的装置,可能须要将Fluentd配置文件搁置在不同的地位。 默认状况下,对于软件包管理器根装置,该td-agent.conf文件位于中/etc/td-agent/。 $ ls -al /etc/td-agent/td-agent.conf -rw-r--r-- 1根root 8017 May 11 18:09 /etc/td-agent/td-agent.conf 对于非root的装置,咱们能够将td-agent.conf文件存储在咱们具备写许可权的任何地位。运行td-agent时,能够应用该-c标记将fluentd指向该文件地位。 该配置文件必须替换为从JFrog日志剖析Github存储库派生的配置文件。 在此存储库中,弹性文件夹蕴含配置文件模板。应用与节点中运行的JFrog应用程序匹配的模板: Artifactory 7.xXray 3.xArtifactory 6.x以Artifactory 为例子,增加采集日志配置如下: 咱们将须要应用match指令更新此配置文件,该指令指定指向咱们的Elasticsearch实例的主机和端口: ELASTIC OUTPUT@type elasticsearch @id elasticsearch host elasticsearch port 9200 index_name unified-artifactory ...

August 14, 2020 · 2 min · jiezi

关于devops:OSC源创会线上直播分享基于插件注册和流程编排的渐进式DevOps体系建设

8月13日(周四)早晨20:00-21:00 议题:基于插件注册和流程编排的渐进式DevOps体系建设议题简介    随着云计算、大数据等技术颠覆性趋势持续在利用经济下发挥作用,DevOps这一理念愈发受到企业与开发者青眼,无效促成了团队合作并缩短开发周期。     通常来说,DevOps的施行会波及到两个层面:一是针对开发、运维、测试、平安等角色,为了对他们日常工作中的技术性工作进行效力晋升而施行的工具链或平台的建设;二是与企业文化、组织架构、人员构成更相干的,为了在企业范畴内晋升团队合作从而缩短价值交付过程的文化与实际落地。从这两个层面,不难看出咱们在DevOps施行过程中会遇到的艰难,比方:DevOps工具链或平台的布局建设与现有的IT撑持零碎体系之间的矛盾,现有企业文化、组织架构和业务流程对DevOps实际落地以及流程优化的妨碍等等。 在本次议题中,咱们将会化身为温和的改革者,通过尝试在企业内建设一个可能容纳现有技术体系和文化体系的DevOps平台,来整合企业IT零碎生命周期内的流动,以缩小在DevOps体系建设初期遇到的摩擦与阻力。 听众播种如何通过复用现有IT体系内的零碎和服务来建设DevOps工具链平台如何对现有业务流程进行继续改良来推动DevOps的渐进式落地对应的开源工具实现嘉宾介绍刘超,微众银行开放平台资深架构师,负责微众银行开放平台解决方案的设计工作。曾任顺丰科技零碎架构专家,安全科技零碎架构师。 报名形式

August 12, 2020 · 1 min · jiezi

关于devops:OSC源创会线上直播分享基于插件注册和流程编排的渐进式DevOps体系建设

8月13日(周四)早晨20:00-21:00 议题:基于插件注册和流程编排的渐进式DevOps体系建设议题简介    随着云计算、大数据等技术颠覆性趋势持续在利用经济下发挥作用,DevOps这一理念愈发受到企业与开发者青眼,无效促成了团队合作并缩短开发周期。     通常来说,DevOps的施行会波及到两个层面:一是针对开发、运维、测试、平安等角色,为了对他们日常工作中的技术性工作进行效力晋升而施行的工具链或平台的建设;二是与企业文化、组织架构、人员构成更相干的,为了在企业范畴内晋升团队合作从而缩短价值交付过程的文化与实际落地。从这两个层面,不难看出咱们在DevOps施行过程中会遇到的艰难,比方:DevOps工具链或平台的布局建设与现有的IT撑持零碎体系之间的矛盾,现有企业文化、组织架构和业务流程对DevOps实际落地以及流程优化的妨碍等等。 在本次议题中,咱们将会化身为温和的改革者,通过尝试在企业内建设一个可能容纳现有技术体系和文化体系的DevOps平台,来整合企业IT零碎生命周期内的流动,以缩小在DevOps体系建设初期遇到的摩擦与阻力。 听众播种如何通过复用现有IT体系内的零碎和服务来建设DevOps工具链平台如何对现有业务流程进行继续改良来推动DevOps的渐进式落地对应的开源工具实现嘉宾介绍刘超,微众银行开放平台资深架构师,负责微众银行开放平台解决方案的设计工作。曾任顺丰科技零碎架构专家,安全科技零碎架构师。 报名形式

August 12, 2020 · 1 min · jiezi

关于devops:你问我答DevOps完美实现一定要用容器吗

BoCloud博云微信公众号【你问我答】小栏目,将收集和整顿企业在IT建设所遇到的问题与难题,由博云产品与技术团队进行针对性答复,每周五通过【你问我答】栏目进行公布,心愿能为企业IT建设提供思路与办法。无论您是哪个行业的IT建设者,如果您有在容器云平台建设、微服务架构转型、DevOps平台建设、多云治理平台建设等技术方面所遇到的问题,欢迎您间接评论留言发问。 以下是本周问题精选: 01 网友1:DevOps完满实现肯定要用容器吗? 博云产品团队:首先DevOps不肯定是要用容器的,传统部署形式也是能够进行DevOps实际。DevOps是一种文化理念是方法论,任何提高效率、晋升业务价值交付程度的形式办法,在特定的组织内都能够称之为DevOps,要害是要从思维上有转变,而后再来谈用什么流程、什么工具、什么标准、什么组织构造来反对DevOps的实际。 Docker是利用运行时环境的一种抉择,它能够疾速的生成应用环境,疾速的启动实例,疾速的在不同的宿主机间移植,他的劣势在于运维的效率,当然是很适宜并且合乎DevOps理念的。 那么, DevOps 的完满实现是不是就肯定要用 Docker 容器技术,还要取决于你的业务,你的现状是怎么样的,如果你的业务变更不是很频繁,技术架构要去做容器化的革新挑战也十分大,那就不是很适宜了。 02 网友2:容器云平台个别是否蕴含DevOps相干的性能,如不蕴含,将来是否须要与DevOps联合? 博云产品团队:从DevOps的端到端一体化治理的概念来讲,咱们把DevOps的性能划分为四个局部,别离是项目管理(需要、工作等)、研发过程治理(环境、版本、cicd、配置、公布、品质等)、运行治理(网关、运行监控、故障解决、中间件等)、经营治理(度量、经营剖析、继续反馈等),每个局部都能够是一个独立的平台,而容器云平台正是咱们所说的运行治理的局部,它提供了利用的统一的运行环境、利用的标准化自动化治理等DevOps提倡的相干理念,所以说容器云平台是DevOps的一部分,减速了DevOps的落地。 目前市场上很多容器云平台都把DevOps的相干能力需要到集成到外面,从而造成局部用户认为容器云平台就是DevOps的不残缺的意识,但从用户真正落地来讲,每个用户的落地门路都不太一样,不论做哪个局部,都是在进行DevOps的实际。 03 网友3:传统能源行业业务系统升级更新慢,适宜上DevOps吗,如何寻找切入点? 博云产品团队:古代社会市场变动很快,到处都在强调企业业务翻新以适应市场变动。所谓传统能源行业业务系统升级更新慢,是以后的IT技术无奈提供疾速变动的能力而造成的一种景象。换句话说,当IT技术具备变动的能力时,天然就会感知到市场和前端的压力,被动寻求变动。 首先在剖析企业业务需要和场景的根底之上,从宏观层面思考IT建设的思路和架构,把可能的问题分门别类的梳理分明。这样一来,在解决某一个具体问题的时候,咱们就能意识到这个问题处在整个架构图中的什么地位,它的上下文是什么,解决的过程中应遵循哪些准则,保障解决方案不缺失关键步骤,也不会适度设计。 其次是思考迭代建设,不过分谋求大而全,特地是在整体架构的领导下,优先解决当下最紧急的问题。 04 网友4:银行对生产测试开发环境要求物理隔离,容器云平台提倡DevOps、CICD,如何均衡这之间的矛盾? 银行对生产测试开发环境要求物理隔离,容器云平台提倡DevOps、CICD,如何均衡这之间的矛盾?有什么好的案例能够提供给大家做参考。 博云产品团队:这里要留神一个问题,部署组因为更关注部署的可靠性和准确性,对CICD / DevOps 的技能把握是十分弱的。开发测试之后要交付的版本,特地是在配置上,肯定要最大水平地模仿生产环境,对于部署脚本,配置信息,要提前为生产环境做好筹备。 如果通过镜像流转的形式来交付,特地要留神对根底镜像和部署配置的修改,不能把这问题留给生产环境的部署和运维人员。 下周预报 与 “ 容器云 ”相干想理解的问题,欢送给咱们留言,下周咱们将为大家解答无关 【容器云】 建设的相干问题。

August 10, 2020 · 1 min · jiezi

关于devops:企业玩转DevOps转型由弱到强只需7步

【摘要】 在参考业界办法并总结客户胜利故事的根底上,本文提出了“七步法”路线图,心愿能帮忙更多的企业顺利进行DevOps转型。从2009年诞生,DevOps曾经悄悄走过了10多个年头。Gartner在技术热门度曲线报告“Hype Cycle for I&O Automation, 2019”中指出,DevOps处于俯冲期(Slope of Enlightenment)。越来越多的国内企业关注DevOps,大有掀起一番大干快上热潮的架势。然而,在这种情景下,企业还是应该感性对待DevOps,将DevOps视为50多年来软件工程办法的扬弃,正如瀑布、麻利一样,DevOps是软件工程特定的时代标签。 如何防止DevOps改革的六大“焦油坑”一文指出了企业践行DevOps转型面临的许多挑战及应答办法。那么企业应该采纳怎么的路线图(Roadmap)来具体实施DevOps转型呢? 在总结客户胜利故事的根底上,咱们提出了“七步法”路线图(如下图所示),心愿能帮忙更多的企业顺利进行DevOps转型。 实践上,DevOps是软件工程办法的进一步倒退,然而对于企业,DevOps转型并不是轻而易举的。企业须要达到引爆点,即企业在此时将改革作为首要任务。通常来讲,引爆点无外乎2类:生死关头(Burning Platform)与愿景领导(Visionary Leadership)。对于大多数的企业,DevOps转型的最大能源往往来自于“火烧屁股”,被动转型少数时候是奢谈。企业通过引爆点的了解对DevOps改革造成清晰的愿景并确立驱动因素。 第一步:抉择适合的价值流对于企业来讲,期望全面的DevOps转型往往是不事实的。因而,通常状况下,企业能够抉择1-2个价值流(或者产品)来进行尝试。这一步工作能够从以下方面进行思考: (1)抉择新产品(绿地我的项目)还是现有产品(棕地我的项目); (2)抉择记录型型产品还是交互型产品; (3)抉择创新型团队还是激进型团队。 管理学巨匠彼得·德鲁克曾说过:“小鱼在小池塘里成为大鱼”。抉择适合的价值流是DevOps转型的十分要害的一步。 第二步:辨认撑持价值流的团队在抉择好试点的价值流后,必须确定价值流的所有成员,来独特为客户发明价值。价值流团队应该为跨职能交融团队,至多包含业务人员、产品负责人、开发团队、QA团队、运维团队、信息安全团队等等。 第三步:绘制价值流图并确定改良指标价值流团队深刻须要深刻了解工作形式,能够应用价值流图(Value Stream Mapping)进行记录,通过工作坊的形式确定价值流关键环节的Lead Time、Value Added以及%C/A,来充沛辨认出妨碍价值流疾速流动的环节,并将其作为改良指标。 第四步:组建专门的团队并培养能力DevOps转型面临的最大挑战是与公司以后业务与交付模式的抵触。因而尽量将转型团队从诸多现有的规定和规定中解放出来。企业能够参考康威定律、Kotter的Dual Operating System等来设计团队构造。对于Kotter的Dual Operating System的论述能够参考SAFe的“Business Agility”。在组建团队后,企业应该对团队进行体系化培训。然而不少企业往往因为投入老本问题,漠视了培训,后果可想而知。 第五步:利用办法和最佳实际进行转型转型团队在了解业界DevOps办法与实际的根底上,联合人员技能程度、工具平台以及业务场景等,针对第三步确定的改良指标,循序渐进地进行转型。DevOps办法与实际涉及面十分广,从咱们的服务企业的教训来看,企业应该聚焦2+1。所谓的2指的是麻利项目管理、代码版本控制,1指的是继续交付流水线。其中的2是根底,很多企业在这2点没有做好的状况,就谋求1,很多时候是缘木求鱼。 第六步:应用工具平台以强化预期行为DevOps转型,首当其冲的是文化与思维的转变。文化与思维通过行为进行体现。如果办法与实际等只是纸质规章制度,那么是难以标准并强化预期行为的,文化与思维的转变也就勉为其难。因而企业组织应该应用工具平台(例如华为云DevCloud)来晋升交付效率与品质,更为重要的是强化预期行为。如何在华为云DevCloud上玩转DevOps,能够百度搜寻查阅。 第七步:扩大到组织的其它价值流正如后面提到,企业能够抉择1-2价值流进行试点,有条件的企业,倡议采纳2个,造成对照组。在DevOps转型合乎预期成果,并且试点价值流良好运行后,能够扩大到组织的其它价值流,实现规模化(Scaled Size)。当然企业应该留神的是规模化有它固有的挑战,并不能看做是价值流的线性规模化,特地是当价值流之间耦合度较高时。 在组织内全面实施DevOps绝非易事,转型可能会给集体、团队、部门以及整个组织带来危险。改革须要勇气,同时也须要正当的路线图,做到危险可控。既然DevOps转型曾经势在必行,企业依照七步法路线图有序施行,凤凰涅槃可期。 华为云DevCloud作为一站式云端DevOps平台,集成华为近30年研发实际和前沿理念,面向开发者提供研发工具服务,让软件开发简略高效。百度搜寻“DevCloud”能够预约收费的产品演示和技术交换,详情查看华为云官网。 点击关注,第一工夫理解华为云陈腐技术~

August 4, 2020 · 1 min · jiezi

关于devops:阿里巴巴-DevOps-实践手册免费下载

在施行DevOps之前,开发和运维团队是两个独立的团队,每个团队都有本人的指标。这些团队之间的差别和沟通不足,通常会影响产品,从而最终影响用户体验和公司效益。 为了更好地沟通和构建更好的产品,DevOps已成为每个公司中最要害的职位之一。 DevOps的定义是“一种软件工程文化和实际,旨在对立开发和运维” 。这个术语最后是由Andrew Shafer和Patrick Debois于2008年发明的,尽管花了几年工夫才成为一个通用概念,但现在,简直每个企业都在应用DevOps。 明天给大家分享的《阿里巴巴 DevOps 实际手册》,笼罩 DevOps 演进史、核心理念与阿里巴巴 DevOps 最佳实际的全方位解析手册,揭开阿里巴巴高效研发的机密! 如何收费下载 扫码,发送" DevOps",即可收费取得 ▲继续关注 获取更多收费福利 代码治理篇 解决方案篇 阿里麻利开发篇 继续交付篇 额定福利 上面是之前入门学习Python时候的学习材料,十分全面,从Python根底、到web开发、数据分析、机器学习、深度学习、金融量化通通都有。 Python常识手册 Linux常识手册 网络编程、正则、mysql常识手册 爬虫查问手册 数据分析常识手册: 机器学习常识手册: 材料支付: 扫描下方二维码,发送:学习手册 即可获取全副手册的电子版本

July 27, 2020 · 1 min · jiezi

关于devops:新一期DevOps认证培训圆满结束下期学员招募同步开启

近日,灵雀云最新一期EXIN DevOps认证培训在北京圆满结束,来自某出名运营商畛域ISV的近40名学员以百分百的通过率为此次培训画上圆满的句号。 灵雀云是国内首家在DevOps培训畛域与EXIN单干的厂商级合作伙伴,可能提供业余、标准的面向DevOps从业人员的DevOps培训,包含DevOps Master和DevOps Professional两大业内最权威的DevOps认证,帮忙企业客户疾速搭建DevOps团队,拥抱DevOps文化,落地DevOps实际和方法论。 EXIN(国内信息科学考试学会)是最驰名的ICT业余人员考试认证机构,领有ICT畛域内残缺的认证产品组合,由EXIN颁发的人员能力资格证书遍布寰球出名五百强企业。在DevOps、麻利和精益的认证考试常识体系中,EXIN面向不同岗位能力要求,提供了全系列多层级的认证体系。EXIN DevOps培训以欧盟官网ICT人员能力框架模型为背书,具备很高的含金量,是寰球范畴内惟一基于DevOps畛域集大成之作DevOps Handbook的认证,具备很高的国内认可度。 DevOps培训的目标群体包含: 软件和网站开发人员 零碎工程师、DevOps工程师 产品和服务负责人 项目经理 测试工程师 IT服务治理操作和反对人员 流程经理 精益IT从业人员 Agile Scrum从业者麻利项目经理 为进一步满足寰球企业数字化能力建设的需要,继续晋升证书的含金量,EXIN于往年2月底公布 《EXIN DevOps、麻利及精益认证体系的前置认证规定》,要求考生基于以后集体能力倒退门路在满足前置认证资格条件下,主观抉择EXIN DevOps、麻利及精益系列认证。 对于想要获取EXIN DevOps Master、EXIN DevOps Professional认证的考生,均需先取得相应前置认证。 EXIN(国内信息科学考试学会)是最驰名的ICT业余人员考试认证机构,领有ICT畛域内残缺的认证产品组合,考试业务遍布寰球165个国家和地区,考试语言笼罩25种。EXIN DevOps培训具备很高的含金量,是寰球范畴内惟一基于DevOps畛域集大成制作DevOps Handbook的认证,具备国内认可度的权威中立认证,以欧盟官网ICT人员能力框架模型为背书。 EXIN作为寰球中立的数字化治理认证机构,长期以来致力于打造数字化治理国内最佳理论常识体系。在DevOps、麻利和精益的认证考试常识体系中,EXIN面向不同岗位能力要求,提供了全系列多层级的认证体系。由EXIN颁发的人员能力资格证书遍布寰球出名五百强企业。 DevOps目标群体包含: 软件和网站开发人员 零碎工程师、DevOps工程师 产品和服务负责人 项目经理 测试工程师 IT服务治理操作和反对人员 流程经理 精益IT从业人员 Agile Scrum从业者麻利项目经理 为进一步满足寰球企业数字化能力建设的需要,继续晋升证书的含金量,EXIN于往年2月底正式公布 《EXIN DevOps、麻利及精益认证体系的前置认证规定》,要求考生基于以后集体能力倒退门路在满足前置认证资格条件下,主观抉择EXIN DevOps、麻利及精益系列认证。 对于想要获取EXIN DevOps Master、EXIN DevOps Professional、认证的考生,均需先取得相应前置认证。   具体前置认证规定 灵雀云是DevOps理念的动摇践行者,在DevOps研发和我的项目实际中,总结了丰盛的方法论,丰盛实操教训,具备上述认证培训的全副资质。灵雀云领有国际化的师资团队,单干讲师均为 EXIN 厂商受权的 DevOps Master 教练,DevOps Professiona 讲师 ,是亲自操盘国内外大型DevOps我的项目的专家。 数字化转型,指数级倒退的第四次工业革命为各行各业带来了新的时机和挑战。企业的DevOps 转型被最高管理层视为重中之重。EXIN DevOps认证不仅关注理论知识,更加关注实际技能造就,实现DevOps理念在企业的宽泛落地,打造开发运维一体化的麻利文化,助力疾速开发疾速迭代。

July 23, 2020 · 1 min · jiezi

关于devops:企业如何通过DevOps在数字化浪潮中C位出道

议题一 DEVSECOPS大型金融企业 如何落地开源治理 高欣 JFrog解决方案架构师 近二十年软件研发和项目管理教训,专一于DevOps畛域十余年,原IBM资深DevOps专家。信通院容器平安、开源治理等系列规范制订委员会专家,GOPS金牌讲师。 主题简介 在继续交付速度越来越快的时代,金融企业面临着严格的安全监管,如何可能在满足疾速公布需要的同时,又兼顾平安、合规性的要求?如何通过自动化的流程,将开源治理和研发、继续交付流程有机地联合在一起?JFrog将为您介绍国内的大型金融企业如何高效地落地DevSecOps最佳实际。 本期话题 落地开源治理的痛点DevSecOps的理念落地DevSecOps的最佳实际听众收益 理解落地开源治理须要解决的问题理解DevSecOps的概念理解落地DevSecOps的最佳实际,及相干标准议题二 DevOps施行门路之团队建设和工具链 伞亚朋 BoCloud博云售前解决方案架构师 近十年在守业公司及上市公司的自动化运维教训, 在电商,金融,游戏等行业有丰盛实际,参加信通院DevOps开发经营一体化平台能力的评级起草和制订、云原生倒退白皮书编写、以及基于PaaS的业务数字化建设体系标准规范起草。当初负责博云售前解决方案架构师,次要负责公司超交融、容器云、微服务,DevOps,自动化运维等产品售前技术支持工作。 主题简介 DevOps在国内的迅猛发展,尤其是国家政策反对,企业都在做数字转型。DevOps成了企业的第一抉择。咱们通过分享来理解下企业在落地DevOps面临的事实问题。如打造一个合格的DevOps团队,如何抉择DevOps工具。 本期话题 企业落地DevOps面临的事实问题抉择一个合格的执行团队管理者打造一个合格的DevOps团队抉择适合的DevOps工具听众收益 理解DevOps落地须要解决的问题如何建设一个合格DevOps团队理解DevOps工具链互动抽奖 流动完结前,讲师会在直播中进行抽奖 不要错过哟~ 7月23日 20:00 扫码立刻报名

July 22, 2020 · 1 min · jiezi

关于devops:创建有效DevOps测试策略的5大技巧

DevOps的惟一指标是自动化和简化整个软件交付过程。目前,大多数组织专一于构建蓬勃发展的DevOps测试策略,该策略开始采纳与继续集成(CI)相干的麻利最佳实际。该操作要求开发人员在一天内屡次查看共享存储库中的代码。每次签入之后都应用主动构建进行验证,从而容许团队辨认谬误和潜在的抵触。 确定正确的DevOps测试安顿 对于大多数DevOps我的项目,指标是将软件交付过程中最大数量的手动过程自动化。跟踪DevOps管道中可能导致部署迟缓的次要阻碍至关重要。这包含容易出错的手动过程,比方从开发团队到测试团队的交接操作。这样的交接表明最终产品不足所有权共享,与根本的开发和麻利测试方法南辕北辙。 如何创立DevOps测试方法?创立适合的DevOps测试策略须要认真评估应用程序或软件。此外,还有几个重要的方面的协调,应该在适当的中央打算一个纯熟的测试安顿。   让咱们把重点放在帮忙构建胜利DevOps测试策略的五个要害技巧上。 1.优先思考软技能测试人员面临的次要挑战之一是采纳侧重于软技能的DevOps核心。简略地说,DevOps要求测试人员在软件开发周期中参加多个测试阶段。因而,须要在测试人员之间灵便地交换,并进一步交融他们过来从未应用过的技能。比方,在DevOps环境中,测试人员须要与开发人员独特加入打算会议,自在地与开发人员交换须要什么测试曾经如何测试,以便撰写测试脚本。   2.专一于根本的编码技能除了更好的软技能,测试人员还须要关注根本的编码技能。这对于晋升它们在整个软件开发生命周期中的角色重要性无足轻重。谈到DevOps,测试人员负责保护产品质量和过程品质,以胜利地将产品推向市场。事实上,测试人员是产品公布的把关人,决定是否将软件从一个环境移到另一个环境。 测试人员所需的基本技能次要是: ●查看构建日志,建设自动化测试的正确性能,并了解软件将如何在根目录下运行。 ●此外,测试人员应该积极参与交付过程,以领导软件以更快的速度通过开发生命周期,这一口头有利于交付更高质量的产品。 3.强调测试优化为了管制疾速的DevOps生命周期,测试自动化是一个根本的必要条件。在现有条件下,有必要思考宽泛和容许要害的变更来加强测试自动化过程。须要优化总体测试策略以取得称心的后果。 依据专家的说法,仅仅强调测试自动化而没有任何优化DevOps测试策略的措施会限度所选工具的效率。相同地,如果测试优化操作被系统地治理,它们通过激活单元、集成以及性能自动化与手工测试的协调的正确合作来帮忙提高效率。   4.及时实现自动化从久远来看,迁延解决问题是有危险的。因而,不应该让DevOps中的问题好转,因为它可能会迅速降级。如果应用大量手动测试而不是利用自动化测试,就会呈现这样的场景。 要解决这种状况,理智的做法是通过自动化测试框架让软件在进入生产阶段之前实现自动化测试。实现自动化的一种办法是通过将测试驱动开发(TDD)与行为驱动开发(BDD)的组合分层,以确保可测试性、更高的效率和促成合作。 5.从云端到公有部署对于一些组织来说,DevOps重大依赖于容许从业者规定和申请资源的云基础设施。这时,外部公有部署的云创立就显得至关重要。在某些状况下,打算晋升DevOps的企业会与遗留的基础设施进行奋斗,以防止与高级工具的互相烦扰。在大多数状况下,从云端到公有部署的转换是胜利采纳DevOps测试策略的必要条件。 本文对正确的DevOps测试策略的重要性进行了粗浅的剖析,下面提到的倡议对于简化测试过程和交付无缺点的软件有极大帮忙。您也能够征询业余的测试人员,这有助于更好地施行无效的DevOps测试策略。

July 22, 2020 · 1 min · jiezi

项目管理如何显性管理并提升Story分解能力

引言: 在“DevOps能力之屋(CapabilitiesHouse of DevOps)”中,华为云DevCloud提出(工程办法+最佳实际+生态)×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列,针对DevOps畛域场景,论述该场景在华为云DevCloud上的施行办法与实际。 在麻利我的项目中,用户故事(User Story)是产品团队用来形容用户需要的次要形式。每个用户故事是小的、独立的行为,最好能够在一个迭代中增量式实现,并为最终用户提供价值。Bill Wake提出的INVEST模型,形容了良好的用户故事应该具备的特色,是用户故事应该遵循的准则: Independent:独立性Negotiable:可协商性Valuable:有价值Estimable:可估算性Small:短小Testable:可测试性将业务个性合成成为合乎INVEST模型的用户故事,成为每一个麻利团队的必备技能。LeffingWell在《Agile SoftwareRequirements 》一书中提出了合成故事的10种办法: Workflow stepsBusiness rulevariationsMajor effortSimple/complexVariations in dataData entry methodsDeferred systemqualitiesOperationsUse-case scenariosBreak-out spike不少人常常会说合成用户故事在增量式开发中既是艺术性又是科学性工作。麻利产品团队能够参照10种办法进行故事合成,并使之尽量合乎INVEST准则。然而麻利产品团队如何在软件交付中记录故事合成办法,以更好地分享办法或者预先回顾改良或者统计分析呢?当然比拟好的形式是采纳麻利项目管理工具,例如华为云DevCloud的项目管理(ProjectMan)。 在华为云DevCloud的项目管理中Story并没有缺省字段来记录合成办法,因而须要通过“Story设置”个性来自定义此字段。用户能够在我的项目中通过“设置”-“我的项目设置”-“Story设置”-“字段与模板”进入工作项模板页面,如图所示: 在工作项模板页面,点击“编辑模板”,并在字段配置处点击“+新建字段”,在下图中输出字段名称、字段类型以及字段选项等。将工作项模板编辑后进行保留。 新建字段“故事合成办法” 这样,在新建Story或者编辑Story的时候,团队成员能够记录故事合成办法。如下图所示 在Story中记录故事合成办法 随着麻利我的项目的迭代进行,产品团队将一直积攒此我的项目的故事合成办法,团队成员能够基于此数据进行分享与学习,将部分的、隐性的合成办法变为了全局的、显性的合成办法。这也正是DevOps三步法(Three Ways)在继续学习与试验中提倡的实际之一“将部分常识转化为全局知识”。 一旦在我的项目迭代开发过程中,团队积攒了故事合成办法的过程数据,那么团队能够在适当的理论进行相应的统计分析。对于故事合成办法的统计分析,目前华为云DevCloud的项目管理的自定义报表个性尚未提供基于自定义字段的维度剖析,产品团队能够应用工作项导出个性,将Story导出到Excel进行统计分析,发现合成办法的一些法则,能够领导产品团队更好地有重点地晋升合成能力。 点击关注,第一工夫理解华为云陈腐技术~

July 17, 2020 · 1 min · jiezi

使用华为云DevCloud-高效敏捷搭建托马斯商城

现在网上购物已成为一种新的生产形式,但看着那些形式多样的网页和目不暇接的商品。你会不会心里有一点疑难:商城是如何搭建的,商品是怎么出现在商城里的?如果我也想本人独立搭建一个商城,是否实现?事实上,学会华为云微认证,借助华为云DevCloud,你就能够轻松搭建托马斯商城。 DevOps——突破开发运维壁垒 传统的开发运维总存在这样的三种景象: 1.运维人员要求稳固牢靠,认为变更充斥危险,开发人员则被激励频繁公布新代码,认为运维部门对流程的保持,妨碍了开发的速度; 2.开发人员说软件在我的机器上运行没问题,运维团队却遇到了麻烦,开发和运维之间的脚本、配置、过程和环境存在差异; 3.开发和运维团队通常处于公司组织的不同部门,有不同管理者,且往往在不同的地点工作,沟通会有妨碍。 打算、编码、构建、验证、公布是开发人员应该做的事件,而部署、运维/经营是运维人员应该做的事件,二者认为分工明确,所以壁垒坚硬,而DevOps却让二者通过文化之间的分享,突破壁垒,也就解决了开发人员和运维人员之间的重重矛盾。 华为云DevCloud——一站式DevOps云平台 作为一站式DevOps云平台,华为云DevCloud集华为研发实际、前沿研发理念、先进研发工具为一体,面向开发者提供研发工具服务,让软件开发更加简略高效。 DevCloud平台具备多场景、全集成、全云化、高性能、高平安、高智能等劣势,利用该平台,开发者能够随时随地在云端进行项目管理、代码托管、流水线、代码查看、编译构建、部署、测试、公布等工作,开启疾速又轻松的云端开发之旅。 利用DevCloud平台 四步实现托马斯商城搭建 那如何搭建商城呢?利用DevCloud平台,四步即可实现。 首先咱们来理解一下托马斯商城,托马斯商城是一个在线零食电商平台零碎,普通用户能够通过该平台进行零食的购买,管理员能够对普通用户和零食进行治理,比方:新增零食,下架零食,零食价格调整等等。 在搭建托马斯商城时,咱们须要进行四个步骤,首先购买所需的资源,通过云服务器环境配置、推送代码到DevCloud、编译构建和部署利用,并实现对商品进行增删改的操作。 资源筹备:筹备代码开发所需应用的资源; 云服务器环境配置:将咱们所需的数据放入到高斯DB中; 推送代码到DevCloud:将本地曾经开发结束的代码,上传到DevCloud代码仓库中; 编译构建:把软件源码编译成指标文件,并将指标文件和必要的文档制作成软件包。 事实上,随着企业数字化的转型,软件云化是大势所趋。通过应用华为云DevCloud对托马斯商城进行一系列的云端项目管理,你不仅能够学会应用DevOps平台、麻利项目管理,晋升工作效率;还能理解学习虚构公有云、平安组、弹性云服务器等常识和技术,更能取得华为官网认证证书哦! 马上开启华为云微认证《基于华为云DevCloud的托马斯商城》的学习之旅吧。

July 15, 2020 · 1 min · jiezi

一站式敏捷研发与-DevOps-平台-Worktile-宣布完成新一轮融资将发力研发管理赛道

技术编辑:王治治丨发自 思否编辑部 一站式麻利研发与 DevOps 平台 Worktile 近日发表实现 B+ 轮融资。本轮融资由亿联凯泰基金领投,老股东斯道资本、宽带资本跟投。该轮融资将用于公司产品技术研发及市场拓展。 Worktile 始终以打造世界级的办公软件作为公司倒退的外围指标。成立 6 年来,Worktile 服务了来自互联网、电商、游戏、教育、外贸、批发、 金融、地产在内的 30 多个行业,付费企业近 4000 家,用户超 50 万,在用户群体中积攒了良好的口碑。 过来几年,Worktile 始终专一于合作办公场景,以国内当先的工作与我的项目合作零碎被宽广用户熟知,在此过程中发现 50% 以上都是研发场景的用户,晋升研发效力是许多企业在数字化转型过程中亟待解决的问题,但市场中并没有一款真正符合中国企业研发习惯的 SaaS 工具。 为了填补市场空白,自 2019 年 11 月以来,Worktile 陆续上线了包含 Agile、Testhub、Wiki 等研发系列产品,发表正式进军研发赛道,并致力于为企业提供更业余的麻利研发治理平台,晋升研发效力,助力企业更好更快地公布产品。本轮融资,将反对 Worktile 在保障协同服务持续提供市场最佳体验的同时,实现团队扩张,在研发效力赛道上为中国企业奉献新的价值。 “咱们想创建一家有价值、有意义、有影响的公司,能够慢点,但必须走的足够远。” Worktile 示意,将保持以“通用合作+软件研发”两条产品线并行倒退,心愿为以软件开发和合作为根底的企业数字化将来,提供最好的SaaS工具和生态。从寰球市场来看,以 Jira 和 Confluence 为代表的研发管理工具在海内市场占有很高的当先劣势,而国内将同样存在复制这个市场的过程和差别,贸易战带来的科技国产化趋势也将加剧国内科技公司在工具基础设施的投入,Worktile 将立足国内 1000 万软件开发者群体,打造世界级的麻利开发与研发管理工具矩阵。 对于此次融资,Worktile CEO 王涛认为:“Worktile 作为企业合作赛道的当先产品,通过数年深耕,播种了数千家中大型付费企业客户的信赖,Worktile 帮忙用户实现更好的合作,撑持不同行业与场景的工作流程和我的项目合作,积淀知识库,数字化治理。同时,咱们也在软件开发与研发效力畛域建设了宽泛的客户认知和口碑,从通用合作根底上切入软件开发合作垂直畛域瓜熟蒂落。研发治理将成为 Worktile 的第二增长曲线,咱们看到越来越多的研发专业人才遍布在不同的畛域和行业,也预示着研发治理赛道将成为对标海内千亿美元市场的微小机会,咱们将一直打磨世界级的产品,让 1000 万软件开发人员的工作更加简略、高效与智能。本次亿联凯泰基金的新一轮融资,将助力Worktile在新赛道实现新冲破,成为国内软件开发与合作畛域的领导者。同时,亿联网络也将给Worktile团队带来继续的产品、业务到治理方面贵重的教训和洞察,助力公司继续衰弱迭代。” 本次融资的领投方亿联凯泰人工智能创业投资基金合伙人卢荣富学生示意:“在智能经济时代,以 5G 网络、AI、大数据、云计算和云服务等为代表的新技术逐渐在各个行业利用,企业组织状态和企业办公合作模式将产生扭转,一个扁平化与网络化、无边界、散布协同、动静凋谢的企业组织状态将催生新的智能办公和合作需要。此次亿联凯泰对 Worktile 的策略投资,是公司踊跃布局企业通信与合作生态的重要一步。亿联网络与 Worktile 都深度聚焦企业合作畛域,且领有类似的企业基因,即求真务实、放弃专一,崇尚通过技术当先、体验敌对的产品帮忙企业晋升效率及竞争力。很荣幸参加 Worktile 的新一轮融资,以王总和李总为代表的守业团队行业经验丰富,对企业合作畛域曾经有了深刻的了解,整体团队的产品化能力、技术创新、学习及进化力都很强,咱们也非常期待接下来在研发畛域的摸索和倒退。亿联凯泰人工智能创业投资基金心愿通过此次投资行为,助力 Worktile 打造以产研团队为外围、面向企业研发场景的全流程合作 SaaS 工具矩阵和生态,帮忙企业进一步晋升竞争力。” ...

July 13, 2020 · 1 min · jiezi

古有七步成诗今有六步完成DevOps上华为云DevCloud实践

引言:在“DevOps能力之屋(Capabilities House of DevOps)”中,华为云DevCloud提出(工程方法+最佳实践+生态)×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列,针对DevOps领域场景,阐述该场景在华为云DevCloud上的实施方法与实践。本文阐述了企业A在实施DevOps过程中,如何一步步采用华为云DevOps平台。此客户成功故事,希望为采用DevOps平台的企业提供借鉴。为行文阅读,本文中企业A将以第一人称(“我”或者“我们”)来进行阐述。 目前,在产品团队的不断努力下,从第一次接触华为云DevCloud开始,现在我们终于拥有了优雅、全面的一站式DevOps解决方案,团队成员不必再费心劳力地使用和维护多种工具及版本。然而回首过去,我们的DevOps持续交付流水线,就像大多数公司和开源项目一样,有很多混杂的产品、服务和脚本,都松松散散勉强一起使用。同时来自不同公司的不同DevOps工具并不总是能够很好地兼容,情况越发复杂。简而言之,我们有很多工作要做,但最终,我们决定要统一工具的行为和目标。 采用华为云DevCloud,我们经历了6个关键阶段。我们希望这会给通往DevOps涅槃路上的企业提供帮助。 第一步:找到你的痛点也许,对于大多数的企业,包括我们自己,DevOps转型的最大动力往往来自于“火烧屁股”,主动转型多数时候是奢谈。正如微软Donovan Brown在谈论到DevOps时经常说:“找到最伤人的东西,围绕它去做很多很多的事儿,使它越来越好,直到它不再伤人。”这也成为我们的座右铭。 如果你打算采用DevOps,并且正在考虑使用DevCloud,那么首先审视一下自己:在我们的DevOps流水线中,最痛苦的事情是什么?没有足够的单元测试?部署新版本太多手工操作导致容易出错?即使你已经到达了DevOps的顶峰,即使你的发布是可以一键部署,你仍然可能在生产中中断某件事情。然而,你会发现你没有合适的工具来告诉你错在哪里;也许是某些事情遇到了瓶颈,或者只是没有按预期的方式工作。因此,让我们找出这些痛点并从那里开始。 第二步:源代码版本控制“代码”作为软件研发的核心产物,因而源代码版本控制是DevOps的基石。在DevOps异地协同上,集中式的SVN远不如分布式Git,因此,很多公司(包括我们自己)将代码从SVN迁移到Git上。这样,你可以使用华为云DevCloud的代码托管服务。华为云DevCloud也提供了迁移指南通过工具或者脚本来帮助企业进行迁移,大大简化了相关工作。 当然,如果你采用Git,应该充分意识:No Pains,No Gains。对于新手来讲,Git需要一个巨大的学习曲线,合并、推送、拉取,变基等很多操作有一点儿复杂。这儿有一个很好的建议,当你开始使用Git时,可以像对待以前的版本管理系统一样对待它,如果你把你所知道的相关知识转义一下应用到Git上,你就可以摆脱初始学习的困境了。对于其他复杂的操作,随着时间的推移,你将开始适应它,水到渠成地学会使用那些强大的功能。 现在整个行业最近都在迅速采用Git,但愿你不会迟到。Git有一个真正具有变革意义的杀手级功能——轻量级分支。Git创建分支的本质只是只是创建一个指针。当然选用哪种分支模型(GitFlow、Gitlab Flow、GitHub Flow或者自定义flow),产品团队需要考虑团队生产力和个人生产力之间的平衡。建议从成熟的flow模型开始。 第三步:任务管理任务管理是产品团队除了源代码版本控制外必须做好另一个基础工作。我们一直在使用业界某主流敏捷项目管理工具T。我们非常喜欢它的简单,在看板的工作跟踪时,只有“未完成”、“进行中”、“已完成”等3个状态。但是随着研发需求的增加,简单的状态跟踪无法满足我的需求。此外,我在拿到客户需求的初期,希望对产品做一个需求规划,让团队可以按照发布或迭代进行需求拆解。 DevCloud的项目管理服务解决了这些痛点,例如思维导图可视化按层级进行需求规划、标准的Scrum方法、可以自定义工作项状态。当然这意味着你失去了简单明了的方式。 图1 在Scrum板视图中查看工作项状态 归根结底,你可以选择你钟爱的工具,例如至为简洁的敏捷项目管理工具T,它可以工作得很好,但是你将丢失可追溯性。而华为云DevCloud可以帮你在DevOps方面做得更多,例如需求工作项与代码提交的关联,需求工作项与测试用例和缺陷的关联等。 第四步:拥抱CI/CD在使用华为云DevCloud前,我们使用的是某主流工具C。它实际上是一个非常好的持续集成产品,它提供On Premises与SaaS版本。 使用DevCloud编译构建服务的一个好处是构建启动的速度变得飞快。对于工具C,每当我们需要一个新的构建时,就会提供一个VM,这可能需要5到10分钟。这个前置时间太久,变得很烦人。而华为云DevCloud拥有了一个热的、随时可以在云中构建的机器池,所以只要有人提交一个新的提交,构建就会立即发生。 以前,我们的部署过程是手动的,我们需要运行一堆批处理脚本。而使用DevCloud流水线是一种乐趣,它不仅仅可以支持一键全自动部署,将变更投入生产,而且提供了完美的可视化编排,可以将构建、部署、自动化测试等纳管起来,并根据实际需要定制多级流水线,加入质量门禁、人工审核等控制。 第五步:Bug跟踪在此之前,我们使用Excel对Bug进行跟踪,随着团队人数的增加,分清Excel版本已经足够让我们头疼了。使用了DevCloud之后,简直给我们的工作带来了不可思议的改变。 首先,Bug跟踪在早例会的直观展示。当我们开早会时,将Scrum缺陷跟踪板投屏,可以通过过滤筛选每个成员手中的Bug状态和等级,便于识别风险。 其次,Bug跟踪与需求、测试的关联。DevCloud中基于需求创建测试用例,测试用例失败生产Bug,实现了需求-测试用例-缺陷双向关联。 最后,多维度的Bug统计。在DevCloud统计报表中,预置了多种Bug统计报表,用户也可以根据自己的需要自定义统计报表。 图2 在DevCloud预置的缺陷统计模板 第六步:定制DevCloud适应项目需求不要陷入DevCloud希望你工作的方式中。如果有众多不同的状态,比如批准、已提交、已解决、已验证,请不要盲目屈从于产品对敏捷或Scrum的定义或者那些对你不起作用的东西。先问问自己什么是可能起作用的最简单的事情,然后在DevCloud上开展工作。最为重要的是,不要因为DevCloud产品经理想的太多而强迫自己过度思考,无所适从。 自定义相对比较简单,因为DevCloud提供了工作项字段、模板、状态流转等的可定制性。你可以用它来增加东西,但你也可以用它来减轻东西。所以,把对你没有意义的东西拿走,只保持最低限度。你只需把它作为一个工具来了解你的团队在做什么,并传达优先事项,保持它的简洁与实用。 采用华为云DevCloud最重要的是,它作为一个全面的解决方案所带来的聚集效应。你可以选择只使用其中的部分服务,然而如果你选择使用尽可能多的服务,你将发现令人震惊的积极变化。当然,这并非没有困难,一蹴而就。DevOps转型面临不同层面的变革,从改变企业文化,到整个组织的新的工具平台的投资,到团队成员的知识与技能水平。但请相信,这确实是一个短期痛苦、长期收益的改变! 全面的解决方案无疑会是一个赢家。一旦我们采用了一体化工具平台,向我们的客户交付软件就变得更容易、更自动化,甚至是一个很好的体验。无论如何,采用华为云DevCloud会失去什么呢?我相信无论只使用部分服务,还是全部服务,它只会给你带来更多的业务效益,以及高效的交付体验。 点击关注,第一时间了解华为云新鲜技术~

July 7, 2020 · 1 min · jiezi

切忌一步到位谈谈DevOps实施落地

2020年6月19日,由云计算开源产业联盟指导,高效运维社区和 DevOps 时代社区联合举办的GNSEC 2020线上峰会圆满举办。BoCloud博云参加了本次峰会并分享了博云帮助客户实施DevOps的真实案例,以及博云内部推行DevOps落地的实践经验。 01 DevOps范围、愿景和目标 过去我们谈到DevOps的时候有很多不同的认知。早先说DevOps可以是CICD,持续交付,后来有人把敏捷开发管理放进来,之后有客户跟我们聊DevOps是指运维SRE。得利于中国信息通信研究院主导的研发运营一体化的标准,终于把DevOps包含哪些内容给说清楚了,如下图所示: DevOps标准中主要包含5大块内容:研发运营一体化、应用设计、安全积极风险管理、组织架构、系统工具。核心的模块在第一部分“研发运营一体化过程”里,而且标准中把最佳实践是什么样、不同等级实践对应有哪些具体细节都说的很清楚。 基于如上这个框架,实际上可以看到DevOps的目标是很多的,涉及开发、测试、运维三个模块。 因为目标很多,所以DevOps到底要怎样落地?是不是照着蓝图做就能很好的实现DevOps落地?因为有蓝图有最佳实践、有标准,按理说DevOps落地应该是非常轻松的。我们回答也很明确:不是这样的。这里我举2个例子,管中窥豹的看看DevOps实践过程中的一些弯路。 02 照着蓝图做,是否就能轻松DevOps落地? 第一个是大型央企DevOps推广案例:内部云团队想规划建设PaaS平台,包括DevOps平台,因为PaaS包含DevOps,所以云团队想将PaaS平台中的DevOps能力推到研发部门。 整体建设范围是敏捷开发管理、持续交付管理、运营一体化,这个事情花了很多精力,也做了很多内部团队的沟通,整体来讲在业务团队推广效果不是特别好,后来就逐渐搁置了。这个事情不是说做失败了,至少效果没有显现出来。总结来说的话:DevOps平台应该是谁使用谁建设可能在起步阶段会更容易一些。 第二个是我们某个中型金融机构案例。这个案例建设目标起的比较高,并找了咨询公司做了咨询。咨询公司做的东西确实比较好,比较完整也比较细致。整个的建设目标包括开发管理、持续集成、测试部署、持续监控的,规划的很完整。 到了落地阶段,这个项目整个落地周期10个月,上线7套系统。整个落地模块包含项目协同,流水线制品库等等,落地了项目协同、CICD流水线、度量仪表盘、管理驾驶舱。客观说实际推广效果还是可以的,尤其开发团队感受还可以。但是整个项目后来总结时运维团队提出了很多意见,说前期运维团队也参与了,领导也提了目标要求,但最后做了10个月,运维团队没有感受到这个平台带来价值。 这个实际应该算是比较成功DevOps项目,但是后来评估的时候运维团队却提出了明确的负面意见,影响了项目评价。总结来说:项目前面调起的太高,范围过大,各个团队落地的期望比较高,但是实际上落地的时候可能有些团队没有得到想要的效果,效果评价受到了影响。DevOps落地初始目标设计,要更合理一些。 如上两个小案例,以点带面说明下DevOps落地的典型问题。 基于前面的案例,我想回答一下为什么DevOps蓝图很难一步到位。第一是因为组织架构, DevOps项目希望同时在开发部门、测试部门和运维部门都得到很好效果很难,最好分步来做,先解决单部门问题是比较合理。 第二个DevOps自动部署的工具仅仅是一部分,其实还涉及DevOps文化和共同认识的建立过程,这需要一个较长的过程。DevOps整体蓝图要解决的问题,涉及的底层工具非常多,很难短时间在没有很好的基础前提下快速落地,良好的DevOps落地需要一系列标准规范的推广落地。但一般来说,因为历史包袱原因,标准规范的推广需要一个逐步甩包袱的过程。这些规范非常需要,但是因为历史包袱问题推广是很麻烦,遇到业务部门业务需求是很大的,所以说标准规范推广是比较难,但必须要做,但是推广需要过程。整体来说,这几个原因是DevOps有了蓝图和最佳实践还是很难一步到位原因。 03 DevOps落地实施路径建议 DevOps具体实施有哪些好的实施路径,我们也想尝试回答一下。理论上从DevOps每个领域都可以发起DevOps,然后去落地,而且根据不同公司情况、业务基础设施情况,实施路径可能不同。根据我们的落地案例,我们尝试性的找几个比较通用合适的实施路径,举几个例子跟大家分享一下。 第一个国内某股份制银行,他的推广路径首先是在研发过程管理中,敏捷开发管理、配置流水线、度量;然后在运维视角发布自动化、变更管理自动化;后来紧随着整个前期的研发推广,同时在底层专业平台、专业数据库管理中建立容器化。 从开发测试角度:他们的流水线已经大规模应用,所有开发团队在开发第一步就可以把流水线建立好,开发人员只基于流水线就可以做整个CI和CD上线,是非常有价值的事情。另外,敏捷开发管理也已经落地到了整个研发流程管控里(这个行业经验很多,但是对开发测试来说,也是最重要的)。 从底层能力方面:容器化大规模应用,对于CICD非常有帮助的。 目前呢,他们正在推进DevOps能力整合优化,实现更大价值。这个案例应该说是非常好的DevOps实践路径。尤其是已经大规模推广起来了,是非常厉害的。 第二个是安信证劵。第一步做了敏捷开发和自动化测试和度量,主要在开发侧;在运维视角做了容器化,也已落地。然后安信证券比较好的一点是除了推广和落地,在于很好选择了试点团队。 试点团队选择了技术能力比较强,希望能够快速发布,根据这几个点选了几个团队进行试点,进行项目实践,整个试点达到比较好的效果。第一,已通过DevOps三级认证。第二,流水线真正标准化落地,度量指标及指标指导下研发改进效果明显。第三,目前已经启动了大规模推广。是DevOps比较好的落地,并能够达到设计效果的一个项目。 第三个是我们自己博云。其实我们做DevOps时间挺长,我们内部2018年开始推行DevOps,当时也是通过工具链来做。后来我们做了自己的DevOps平台,目前已经全部切换到自己的平台来用了。推广路径如上图,自研DevOps平台推广周期相对比较短,基本上4个月就全部切换过来了,主要是因为内部在工具链使用方面已经有比较多的经验。 我们是软件公司,没有所谓线上发布这个过程,所以说DevOps落地更多集中在研发测试环节。我们的需求本身是比较明显,有两个核心需求,第一个实现快速迭代发布,第二个实现能够更好去把研发进度效率实现自动化,把度量的事情搞定。路径上来说,我们首先DevOps团队自己先去试点推广,DevOps产品现在整体来说1个月一次正式的版本发布,进度质量效率数字化,实时可见。第二个通过公司管理层的直接推进快速扩展到全公司研发团队。 实施路径选择建议 尝试性的总结下DevOps实施路径选择原则。 第一个要制定合理目标。核心原因是每个团队最为关注目标是不太一样的,像刚刚讲到我们作为做软件的公司,更多偏向于快速迭代发布和度量这两块的内容,但作为一个线上系统可能更重要是别的一些指标,所以说基于自己现状从核心痛点出发,制定合理项目目标比较重要,同时在运维发布和CICD流水线都有需求。 第二个是管理好内外部期望。其实我们一开始要提出自己的目标,一个方面要有很好价值,另外也不要好高骛远,不要把期望搞的很高,推广是没有那么容易,要有合理期望值,包括领导,期望太大容易失望,失望了之后推广就失败了。 第三个是系统设计取决于组织架构。最好不要一上来做组织架构的事情,这个肯定可以做,但是比较麻烦。在DevOps实践里面组织内部做的事情很多,可以从本身组织开始,然后逐步实现整合跨部门,这个很合理。除了平台之外还有人的文化认知,所以分步实施、逐步演进,也不需要规划一步到位,一个月就把DevOps做到位,这个其实不太现实。一步到位非常难,而且效果不好。那么试点团队是先试点,配合比较好、意愿比较强再去推广,这个是几乎所有DevOps做得比较成功企业的工程实践。 另外一个周期上要有持续的推进机制,可能刚开始大家推进挺好,那么过了半年推广是不是忘了,必须要有持续的推进机制,要有打持久战的准备,逐步把DevOps这事落地优化到最好。 最后一个是:规范。越规范越有用,规范价值是非常大的。在可能情况下可以先推行规范,有了规范,很多事情会变得非常容易,而且对于使用者,落地之后的使用体验也会很好。所以规范越早推越好。 整体上这个就是DevOps落地实施路径的规划原则,大家可以作为参考。

July 7, 2020 · 1 min · jiezi

课程报名-如何通过-IM-实现分布式任务调度系统这里有答案

在谈到如何实现 DevOps 时,往往面临两大方面的问题 :开发测试管理问题和运行管理问题。开发测试管理问题一般表现在开发效率低、版本质量差、环境交付慢,无统一工具设置,整体的研发运维过程管控不足。因此,通过 DevOps 平台进行流程化管理变得尤为重要。 另一方面,随着云计算的发展,企业机器数量逐渐增多,规模逐步扩大,机器的管理和维护成为 DevOps 不可或缺的一个环节。而且,随着业务发展和架构演进,多云和混合云成为常态。企业的基础设施,从早期单机房,开始覆盖到多个地域。在混合云、多地域等各种异构网络环境下,运行管理也是必须面对的问题,因此,势必需要一套调度系统来管理、控制各类资源。 作为运维平台的基础,任务调度系统的职责,是控制、分发任务到对应的机器或容器上。而任务调度系统往往面临着:物理机、虚拟机、容器等不同类型有差异;Linux、Windows 等操作系统兼容问题;公有云、私有云等环境存在差异,网络不在同一平面;时效性、可用性要求高;Agent 安装、升级、插件管理问题…… 那么面对这些问题时,企业和开发者应该如何解决呢?7 月 2 日,来自京东智联云、博云的两位讲师将通过线上公开课的形式,为大家分享各自的实践。 通过本次课程,大家可以了解从开发到测试,如何通过 DevOps 平台进行流程化管理,以及企业在研发流程规范、团队配合、统一工具设置、代码发布环境质量管控等方面如何选择落地路径。也可以了解到京东智联云的任务调度系统是怎样设计的,如何用 IM 实现分布式控制系统。 《_DevOps平台高可用架构与实践_》活动日程 议题简介 1、分布式任务调度系统面临的机器控制与管理、效率与性能问题 2、京东智联云在任务调度系统设计中遇到的“坑” 3、如何用 IM 实现分布式控制系统设计 4、公有云、私有云等多种异构网络下的 C/S 架构设计 1、DevOps 的范围、愿景、目标 2、DevOps 中各研发岗位之间如何协作 3、DevOps 如何实现工具链的统一管理 4、企业 DevOps 落地实施路径选择 课程时间 2020 年 7 月 2 日(周四) 19:30-21:15 扫描下方二维码 立即报名 注意!!报名成功后,开课前会有短信/邮件提醒,所以报名时请填写正确的手机号码及邮箱地址哦! 点击【阅读】了解课程参与方式及更多在线公开课详情 添加小助手,回复:DevOps进入公开课交流群 ???????????? ENJOY :)

June 28, 2020 · 1 min · jiezi

CODING-DevOps-系列第四课DevOps-中的质量内建实践

什么是质量内建随着时间的推移,我们项目的开发效率会逐渐降低,直到几年之后整个项目可能就无法维护,只能推倒重来。具体的表现首先就是随着时间推移,我们会发现整个需求列表里面能做的需求越来越少,因为每当我们增加一个新特性,需要改动的代码就非常多,所以最后每提出一个新的需求,团队评估出来的改动成本都非常高,导致最后难以增加新的特性。 第二个表现就是缺陷难以修复。我们做出来的系统只要有人用就会有反馈一些线上的故障,一开始代码很简单的时候修复起来是很快的,但是随着代码越来越复杂、代码行数越来越多,我们会发现定位问题太难了。尤其是现在我们的项目采用的是非常复杂的架构,所以当用户线上报错的时候,我们很难去定位到是哪里出了问题。但其实只要定位到了问题,修复起来是很快的。 第三个表现我们称之为“打地鼠现象”,简单来说就是当你“按”下一个缺陷的时候,又会蹦出来几个新的缺陷。这样会导致大家在工作的过程中压力非常大、心情也会比较沉重。 所以对于这些挑战,我们也有想办法去解决,CI、CD 以及 DevOps 的出现都让我们看到了很好的方向。但是我看到很多团队其实只是靠 DevOps 解决了一些基本的问题,并没有解决核心的问题。这是为什么呢?因为核心问题主要是靠开发人员的能力提升来解决的,但由于改变一个人是很难的,所以企业往往会绕开这些问题。所以我今天分享的内容主要会涉及到开发人员如何去写代码等一些实践。 我们在刚开始启动一个项目的时候,我们会制定一些代码规范,所以代码相对来说是比较清晰的。但是随着需求的演变,在实现这些需求的时候,每个人都会选择最低成本、最保险的方式。这就会导致没有人敢去大幅度地改动代码,只会在里面追加一些代码,造成了代码里面有大量的重复、过长的方法。同时开始的时候设计的架构也是非常清晰的,但是如果后续没有很好的落地、监控、自动化地发现问题,架构就会在这过程中腐化,变得一团乱。 Deming 先生曾提出“问题发现得越早,修复的成本越低”,这句话也是我们去降低软件开发成本、更高效地保证质量的重要原则。所以我们采用质量内建的方式,可以把整个软件质量的保障内嵌到开发的过程中去,而不是留到后面再去检测,因为越往后修复的成本越高。 85% 的缺陷都是在代码编码阶段引入的,然而大部分的缺陷并不是在编码的时候发现的,而是在后面的单元测试、功能测试、集成测试发现的,越往后发现的缺陷越多。按照刚刚那个原则,假如在编码阶段发现的缺陷只需要 1 分钟就能解决,那么单元测试阶段需要 4 分钟,功能测试阶段需要 10 分钟,而到了上线之后再发现可能就需要 640 分钟,这个成本是非常高的。 那么质量内建的方式是怎么样的呢?首先我们通过自动化测试、重构、简单设计等手段,可以使在编码阶段引入的缺陷变少,因为我们代码写清楚了,bug 就藏不住了。同时当我们做到自动化测试等工作时,在编码阶段发现的缺陷也变多了。那么通过质量内建,我们在编码阶段就把大部分的问题都捕获到,同时引入的缺陷也更少,它就降低了软件的开发成本。 大家可能会有一个疑惑,就开始开发人员原本只用写功能就行了,现在却还要写测试代码,而且测试代码的比例和实践代码的比例不一定,这样会不会增加成本。这里想跟大家说一下,很多人会把我们编写代码的时间当成整个软件开发的时间,其实不是。在编写玩代码之后,还得开发自测,然后还要去联调,之后还要进行内部测试、线上故障修复等,所以整个软件开发有这么多的过程,而我们现在解决问题的办法是在第一阶段投入更多的时间,做更多的测试、更多的代码优化等,从而减少后面所要花费的时间。根据刚刚说的修复时间越晚,成本越高的原则,我们这样做是划算的。 技术债与质量门禁技术债是什么呢?债是一种比喻,与我们金融方面所说的债务意思相同,那么在我们技术范畴里面也有这样的债务问题。在我们编写代码的过程中留下了一些重复的代码,或者没有起好名字、没有给出注释,类似这样的问题就是我们欠下的技术债。 对比金融里的债务,技术债也有相应的特性。首先这个债我们必须得还,否则到了后面越欠越多可能会把整个团队压垮了,导致大家没有动力去开发新的功能。同时技术债是有利息的,假如最开始写代码的人留下了问题没有去解决,那么下一个接手这个代码的人可能就没法理解这个代码,就不敢大胆地去改代码,越晚就越不敢。 既然技术债存在这么多问题,大家为什么还要去欠债呢?因为技术债也有好处,有的时候我们要做的产品并不是一个非常靠谱的产品,我们就会追求更快,用一个比较粗糙的手段做完交给客户去进行测试。得到反馈之后,靠谱的话我们就会用心去优化、迭代;不靠谱的话我们就会放弃这个项目,这是它的成本也很低。所以由于互联网行业的这种快节奏,人们会倾向于欠下很多的技术债务,从而快速试错。当我得到反馈,确认用户的痛点之后再来进行代码的优化。当然我今天更想讲的我们为什么会欠下债务,其实还是是因为态度以及习惯问题。如果我们能改掉我们的坏习惯,我们就会少欠下一些技术债。 当我们搭建好一个项目的基础框架,写了一些示例的代码,后面就会上很多的人来做一些新需求。这个时候就会出现“失控”,我们会发现一开始的代码非常整洁,但是人一多之后就会形成“破窗效应”——简单来说就是一旦一扇窗户上出现了一个破洞,那么很快上面的破洞就会越来越多。代码库也是如此,当一个人没有按照规范写代码,同时没有人制止,那么很快其他人也会纷纷开始这样做,很快代码就会变得乱七八糟。 那么应对这种“破窗效应”的方法就是“童子军军规”,就是不管原来的质量怎么样,我们也得保证我们接手处理完之后,代码的质量要比原先好上一点、干净一点,哪怕是改一个变量命名也好,改一个格式也好,人人都这样做的话我们的代码库就会越来越干净、质量越来越高。这种方式就是我们所谓的“质量门禁”。 接下来讲一下偿还技术债,首先第一点是并非所有技术债都应偿还,或者说技术债的偿还应该有一个优先级,我们更应该关注的是那些频繁地需要变更的代码。第二点是应用童子军规则,也就是有债就还,不要拖欠太久,保证每次提交代码的时候比接手时要干净一点。第三点是先偿还高息技术债,就是看哪些问题不处理的话带来的后果会更严重,我们就优先处理这些问题。接着是分期偿还技术债,将我们的技术债管理起来,每次迭代的时候就一边做有客户价值的工作,一边偿还技术债。这里很关键的就是不能依赖开发人员的自觉性,而是在迭代的时候就要明确那哪一块要优化、要重构,分到个人的头上,同时后面要进行评测、验收,经过这样一个流程正式地去对待技术债。 自动化自动化是一个实践,我们经常会听到像自动化发布、自动化打包、自动化构建、自动化测试等,尤其是自动化测试是一个反复被强调的一个实践。我们的流水线其实整个都是自动化的,构建是自动化的,检查是自动化的,包括后面的测试和部署也都是自动化的。 有一个原则叫自动化一切,就是“一切能被自动化的都应该被自动化”。除了常见的编译、检查、测试和部署,服务器的配置也可以进行自动化,甚至业务上的一些部署,比如一些迁移之类的,能自动化的我们都把它自动化。我们作为开发人员,最擅长的其实就是写代码,很多人会觉得自己的工作没什么挑战,这是因为你天天都在手工地做一些重复的事情,当然没有挑战了。这时候你可以尝试去自动化一些事情,你会发现很好玩,也能学到新的东西,个人能力能得到成长,同时做的事情也有价值。 我体会到自动化的几个好处,跟大家分享一下。第一个是沉淀知识,就是把知识沉淀到了自动化的脚本里面,而不是存在于某个人的脑子里。而对于掌握知识的这个人来说,他也减少了被打断的可能。第二点就是自动化能够提高效率,解放生产力,这一点其实是一个很明显的好处,原来手工要花五个小时的事情,自动化可能几分钟就跑完了。最后一点就是固化流程,降低出错率。也就是将我们的这个流程固化下来了,原本一件事情今天是 A 做,明天是 B 做,他们在做的时候可能就基于自己的理解来做,中间就会引入一些错误。而自动化就可以规避这种问题。 其他有效实践①结对编程:结对编程是我非常推崇的实践,很多人认为结对编程就是一个人写一个人看,这样就浪费了一个人,其实不是的。其实结对编程有点像汽车拉力赛,领航员会看地图然后告诉 driver 前方的路线,例如前面的弯道该怎么走,所以他的视野会更加宏观,看得更远,也有助于对我们的 driver 做一个思维上的引导。写代码的时候也是这样的,操作键盘的人在考虑代码该怎么敲,而另一个人则是在引领思路,所以他俩是在互相配合的。 ②代码评审:代码评审就是大家坐在一起,分享代码的收获、踩过的坑以及解决问题的方法、技巧。这是一个开发人员的交流活动,而不是一个类似于质量门禁的东西,这是有温度的一场交流、分享,传播有价值的东西。 ③暴徒式编程:暴徒式编程是结对编程的一种方式,由一个人操作键盘,同时设置定时,每隔一段时间换人。其他人就负责盯着大屏幕告诉他该怎么操作,这个也是一个很好的学习手段。 小波老师将在完整视频中继续为大家带来 更多精彩分享以及重构的在线演示 点击观看完整视频

June 18, 2020 · 1 min · jiezi

CODING-DevOps-系列第二课标准化助力-DevOps-转型

DevOps 涉猎的范围非常的广泛,包括软件研发全生命周期的方方面面,对于刚开始涉及 DevOps 的人来说会有种盲人摸象的感觉,这正是 DevOps 转型的一个难点。在 DevOps 转型过程中,标准化是重要手段。那么,标准化关注的具体是什么内容呢?DevOps 的转型目标在于缩短前置时间,加快部署频率,提高系统的可用性,减少服务恢复时间,降低变更失败率。这就要求我们在设计运行平台的时候,除了具备自动恢复功能的以外,还要提供丰富的运维监控数据以及强大的数据分析能力,这样能够帮助运维人员在极短的时间之内恢复服务。变更失败的原因主要有 2 个,一是功能质量没有达标,二是需求理解不到位。 图片中是我们整理的一些标准化的关注点。作为产品经理或业务分析的人员,需要关注需求如何顺利到达研发团队,并能够适应他们进行敏捷的开发。作为研发人员需要关注的点相对比较多,尤其是要关注配置信息标准化管理。 标准化的目的是为了实现自动化,包括集成的自动化、部署的自动化、测试的自动化和运维的自动化。下图是一个典型的 DevOps 循环图。我们认为业务敏捷是前提,DevOps 流程是从敏捷型需求为起点,经过了运维监控这个最后的节点回到计划,实现闭环。 编码过程标准化的重点在于测试驱动的开发,这也是敏捷要求的一个标准,但是实际上能做到这个标准的团队并不是很多。测试驱动开发首先要面向接口做一些测试和开发,面向接口做测试的时候需要关注接口名称、接口协议、接口参数名称和类型、接受条件。其次我们需要关注数据,包括每个接口输入的数据以及其得出的结果。针对引用的相对复杂业务逻辑的其他服务,需使用 mock 工具来减少依赖。每个测试用例的测试场景需要完整注释。 最后我们总结一下前面的内容:一、需求敏捷化是起点。二、TDD 开发模式是快速迭代开发时代保障软件质量基线的有效手段。三、注重环境配置文件的标准化,保证程序的可测试性。四、研发流程的标准化是建立自动化 CI、CD 流程的前提,而 CI、CD 流程的自动化是实现 DevOps 的关键点。五、Jenkins 是实现 CI、CD 流程的有效工具,但是在处理复杂业务场景时还需要有其他合适工具的帮衬。六、服务器运行环境的标准化,可以促进流程脚本的标准化。 点击观看课程完整视频。

June 17, 2020 · 1 min · jiezi

CODING-DevOps-系列第一课基于开源工具链打造持续交付平台

当下软件发展趋势当今 IT 行业发展中比较流行的几个技术,首先是微服务化,将原有的一个系统拆分成多个,意味着有多个系统需要构建、测试、部署和运维。 第二个是敏捷开发模式,需求粒度更细化,要求一个可独立部署单元快速开发、快速测试、快速部署上线,实现快速迭代。 还有一个就是容器化,随着容器技术的快速发展,越来越多的应用迁移到了容器上。 这时候就会出现一些问题,如果当下软件交付继续使用传统模式,就会需要花费大量的人力物力,同时有大量的重复部署任务,且交付无法做到快速型。那么有没有一种更好的交付方式满足当下的软件发展趋势呢?答案肯定是有的,正是在这样的背景下,DevOps 横空出世。 DevOps 简介及特点DevOps 是 Development 和 Operations 的组合,即开发、运维一体化。通俗地来说就是通过一系列工具及制定一些规范,尽可能地实现软件交付自动化,同时保障软件交付质量。 DevOps 总得来说有以下几大特点,首先是自动化,通过引入一些列工具,实现从需求到上线整个交付工程自动化,必要环节进行人工确认。 第二点是规范化,单有工具是不行的,需要一系列的规范支撑,比如版本管理规范、测试管理、测试数据管理等。 第三点是缩短交付周期,交付过程基本是一键式或者全自动,省去了中间不必要的环节,缩短了交付周期。 第四点是交付质量有保证,交付过程中可以引入静态代码扫描、单元测试、接口测试等环节,并对每个环节设置质量门槛,降低了生产出现 bug 的概率,真正做到了防患于未然。 基于以上四个特点,我们整个产品有了相应的提升,交付过程自动化解放了劳动力,又保障了交付质量,自然会带来更大的收益。 工具集选型版本控制系统版本控制系统(VCS)也叫源代码管理系统,顾名思义,提供最基本的版本控制功能,他会在文件修改的历程中保留修改历史,让用户可以方便地查看该文件的修改历史。并且可以方便地让用户撤销对文件的修改。 目前业界使用比较广的版本控制系统主要有两个,首先是 SVN,它是一个开放源代码的版本控制系统,基于 CVS 发展而来,用于多个人共同开发同一个项目,共用资源。简单、上手快,易操作,但是无法实现分支管理,比较依赖网络。 第二个是 GIT,它是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或大或小的项目,作为一个开源的分布式版本控制系统,可以有效、高速地处理各种项目版本管理,可以实现很好的分支管理。 持续集成持续集成这一块也给大家介绍一款常见的工具——Jenkins,相信很多小伙伴都使用过,它是一个开源自动化服务器,作为一个可扩展的自动化服务器,Jenkins 可以用作简单的 Cl 服务器,或者变成任何项目的持续交付中心。它的社区非常活跃,插件也较为齐全,可以集成打通需求管理、版本管理系统等。 持续测试持续测试这块我们会有一个测试分层,分为单元测试、接口测试、联调测试。单元测试是方法级的测试,开发同事需要针对源码编写测试类,目的是为了验证功能代码是否有问题,可以使用 junit+jmock 实现,对接到 pipeline。 接口测试是针对外暴露的接口或者为本系统提供服务的方法进行测试,需要编写测试案例,可以将 Jmeter 集成到 Jenkins 上实现接口自动化测试 及结果收集。 而联调测试是指系统间连通性测试,需要人工介入。 持续部署我们部署的东西不仅仅只涉及到应用部署包,还会牵扯到一些配置文件以及数据库脚本。配置文件在大多数情况下是与环境进行绑定的,每套环境使用一套配置文件,需要对配置文件做统一管理,发布时选择对应文件或者动态替换。 数据库脚本需要将 SQL 变更文件纳入到版本管理系统中,发版时增量执行变更 SQL。 持续集成将构建包推送到制品库中按照一定规范管理起来,部署时从制品库中拉取对应版本的应用包部署。应用可能部署到物理机,有可能是虚拟机、私有云或公有云。 分支策略方案在整个交付环节中,版本控制是最重要的一块,而版本控制又跟分支策略有关。如果前期分支策略做得不好的话,后期的版本控制肯定是很糟糕的。只有前面做好了,后面才有做好的可能。 分支管理的必要性这里相信小伙伴们都会有一定的了解,分支管理可以帮助我们避免代码的丢失,如果没有合理的分支管理,在某个功能还没有开发完,代码推送到远程会影响其他功能,如果不推送到远程仓库中,本地数据丢失会导致代码丢失。 同时,分支管理还可以提高代码质量。设置分支权限后,feature 分支向主干分合并需要 master 角色 review 评审,保障了主干分支代码质量。 最后,随着软件的迭代,版本号也随着变更,为了追溯每个版本的需求、变更集及线上 bug 修改,需要设计合理的分支策略并管理到需求和部署包。 ...

June 17, 2020 · 1 min · jiezi

自定义敏捷项目看板体验再升级博云DevOps平台发布31版本

6月9日,BoCloud博云BeyondDevOps平台更新了V3.1版本。新版本在上一版的基础上完善了产品功能,进一步改善产品易用性——支持敏捷项目看板自定义,集成Jira software,丰富工作项类型,对敏捷项目管理体验进行优化。 版本亮点 集成 Jira software灵活的敏捷项目看板丰富的工作项类型版本展示 集成 Jira software 通过和 Jira Software的集成,实现平台间工作流的对接,可向jira平台推送需求、任务的工作流状态,实现 Jira Software 需求管理模块相关信息的同步与更新。 灵活的敏捷项目看板 平台提供可灵活配置的敏捷项目看板功能,用户可根据自己的需要定义合适的项目看板。通过看板用户可以更明确地区分每个任务所处的阶段,了解项目中的每个任务在各个迭代中的进度。 丰富的工作项类型 平台提供了以版本,迭代,工作项(史诗、需求、任务、缺陷、子任务)为核心的任务协同工具。从支撑大型工作的史诗开始,到处理具体工作细节的需求、任务、缺陷、子任务管理,能够帮助用户更好划分项目的工作层级,将工作从大粒度拆分到小粒度逐一跟踪与交付。 BeyondDevOps平台 BeyondDevOps提供从“需求->开发->测试->发布->运维->运营”端到端的开发运营一体化平台解决方案,覆盖项目管理、研发管理、测试管理和运行管理的协同服务和研发工具支撑,将线下 IT 生产过程转变为线上高度自动化、可视化的 IT 生产线,提升产品研发效率,快速响应业务需求,保障工作质量,并通过度量分析、风险预判,持续提升 IT 运营能力。

June 16, 2020 · 1 min · jiezi

漫画版-小朋友都能看懂得-DevOops不允许你有问号

DevOps消除了障碍,并减轻了开发人员和运营人员之间的紧张关系。革命性的DevOops! 什么是DevOps?DevOps是开发和运营相结合而产生的一个术语。DevOps工程师的作用是按照开发人员的方式自动化所有操作工作。这个想法是为了鼓励频繁发布以提高质量并获得早期反馈。 DevOps来自哪里?“ DevOps是敏捷软件开发的后代。” — 丹尼斯·埃勒( Dennis Ehle)。如今,敏捷是一个超负荷的流行语。每个人都已经或正在敏捷。不仅开发,而且其他部门(例如BA,QA,构建和发布工程师等)也应保持最新。DevOps工程师可以帮助所有这些利益相关者优雅地采用敏捷。他们使从计划阶段到发布阶段的所有过程实现自动化。他们帮助团队在保持高质量的同时更快地行动。 DevOps解决什么问题?“想法很便宜。想法很简单。想法很普遍。每个人都有想法。想法被高度评价。执行至关重要。” —凯西·尼斯塔特。敏捷软件开发是近几十年来软件开发实践发生的革命性变化之一。它提倡适应性计划,渐进式发展,早期交付和持续改进,并鼓励对变化做出快速而灵活的反应。为此,应优化整个开发生命周期。至于优化,在可能的情况下,自动化是关键,这是理所当然的! 好文推荐: 整整127页!这是一份阿里云内部超全K8s实战手册 大厂0距离:网易 Linux 运维工程师面试真题,内含答案 牛x公司有一群牛x的人,鹅厂大佬如何玩转技术?内附腾讯技术合集

June 10, 2020 · 1 min · jiezi

DevOps-从渐进式交付说起含实践-Demo

作者:CODING - 王炜 1. 开篇如果让你主导一款千万、甚至亿级用户产品的功能迭代,你会怎么做?你需要面对的挑战可能来自于: 商业战略的变化带来新的产品诉求,而产品的任何改动哪怕仅是界面调整,都将面临无数存量用户的挑战这时候,作为产品负责人,你会选择稳定压倒一切?还是自我革新,继续追求用户和市场的价值呢?笔者通过对 Facebook、Twitter 等互联网巨头的调研,试图窥探他们在瞬息万变的市场中仍然保持“稳定”迭代的秘密 - 渐进式交付 通过本篇文章,你将收获: 什么是渐进式交付,为什么 DevOps 能够天然与其结合为什么渐进式交付能赋予大规模组织下的产品持续交付及稳定迭代的能力小项目,大项目同样适用的实践经验2. 什么是渐进式交付移动互联网时代的爆发,诞生了一大批巨型互联网企业和项目,部分大型项目的技术复杂程度和组织复杂程度甚至不亚于传统的工业项目,为了实现对这些项目的管理和迭代,我们试图将目光投向已经完成工业革命的传统工业寻找答案。 而“渐进式交付”一词最早起源于大型、复杂的工业化项目,比如:铁路、汽车和军事产业、新基建的 5G 网络产业等等。 它和 DevOps 的目标一致,试图将复杂的工程化项目进行分阶段拆解,通过持续进行小型迭代闭环,降低交付成本和节约交付时间可查询的资料显示,“渐进式交付”流行于互联网产品是在近两年 Kubernetes 以及云原生大规模使用之后。这两项技术的出现,为“渐进式交付”在互联网的应用提供了基础设施和实现方法。 DevOps 是“渐进式交付”的实现手段,而其中的“流水线”为“渐进式交付”提供了实现途径在产品的迭代过程,可以将“渐进式交付”的具体行为附着在“流水线”中,将整条交付“流水线”看做是产品迭代的一个过程和一次“渐进式交付”周期。 说了这么多“渐进式交付”的理论基础,在实践中又是以哪些技术方法落地呢? A/B 测试金丝雀 / 灰度发布以 Facebook 为例,每次发布重大功能,都会经历一次典型的“渐进式交付”过程: 迭代发布公司全员 A/B 测试特定用户 A/B 测试灰度发布全量发布这种渐进式交付的好处是,对于新迭代正式推向市场前提供了灰度用户的数据支撑,帮助决策者充分了解用户倾向和市场诉求。 在“渐进式交付”的过程中,A/B 测试环节以及灰度发布环节都可以根据用户数据和市场反馈决定是否进入全量发布,这种方式既能够保证迭代敏捷进行,又能够保证迭代的用户和市场安全性。 2.1 A/B 测试 例如通过对用户画像中地理位置和性别组合条件进行 A/B 测试,使其访问新版本,而其他的用户则继续访问旧版。一段时间后,研究用户行为数据和用户体验报告,决定功能是否继续进入下一个发布环节。 2.2 金丝雀 / 灰度发布 使用特定分流技术使流量由新老版本共同承担,如典型的“MurmurHash”算法 3. 技术价值和商业价值从原理上来看,这些技术并不是多么新的技术,比如 A/B 测试,我们用最原始的方式:业务代码增加逻辑判断条件也可实现,但为什么没有大规模运用呢? 原因很简单:纯业务代码的实现依赖于技术开发,需求方无法自主控制 A/B 测试的环境和条件,这种过度依赖于技术开发并不能带来规模化的运用。 我们需要的是一种完全脱离业务代码的实现方式,最好能以自动化/半自动化实现,并且尽量能把这个动作加入到已有的内部流程内现在,有了云原生和 Kubernetes 的支持,结合 DevOps 的流水线,自动化的渐进式交付成为了可能。 我们参考 Facebook 的发布方式,设计了这个 Pipeline Demo ...

June 3, 2020 · 4 min · jiezi

ONES对话效能专家顾宇-坚持正确的研发管理转型之路

以下内容为 ONES 访谈效能专家顾宇对话实录整理。 近些年在国内的研发管理领域,有两个较为明显的趋势: 一是伴随着 DevOps 运动的顺利发展,无论是何种类型的企业,是否采用敏捷开发,都已经在使用 DevOps 作为开发体系并配合一系列的工具和人员付诸实施。 二是伴随着敏捷开发的普及,中大型的研发团队正面临规模化带来的一系列问题与挑战。 与这两个趋势相对应的,是国内企业的技术团队在纷纷进行各自的转型升级,而相对于互联网企业来说,传统行业的研发管理转型之路则更具有代表性。在帮助众多客户进行研发管理转型咨询的过程中,顾宇发现了一些成功企业身上的共性特征: 01 比较先进的企业在践行 IT 定义业务 这样的模式可以帮助企业远远跑在其他企业前面。特别是在传统行业的某一个领域中,例如工业、消费领域,如果它能像互联网企业一样,用 IT 来定义自己的业务就意味着他已经把其他企业甩在了身后。 02 处在第二层次的企业在做 IT 帮助业务 主要是让 IT 提供一些数据,分析管理,仅仅把 IT 作为一种制度的固化和数据存储的平台,对企业的管理进行了一个赋能,节约了企业的管理成本和信息的成本。 03 疫情之下,公司暴露出哪些管理问题 业务的整个过程其实是不需要 IT 的,IT 团队的工作内容主要是一些仓库管理员或记录员的职能, IT 还没有作为企业业务的一部分。 这几个层次企业的区别,如果我们放在现在疫情的大背景下来看就是:后面两个层次的企业其实已经受到了更大的冲击与影响,因为IT并没有帮助他们完成一个在数字化时代疫情特殊情况下,通过远程办公来进行真正的协作办公和协作生产的效果。 但是如果你已经是 IT 定义业务的话,那么本身就意味着你已经是这个世界上一个唯一的供应商,在你所处的行业内就会有着垄断性的地位。 那么如何能让我们的企业做到软件定义业务,实现「IT Define Business」呢?顾宇也给出了他的一些建议。 首先在谈任何转型与升级的过程中,都要伴随着思维和工具两方面的改变。如果现在谈到 DevOps 仍然还处在工具链打通的阶段,这个组织的 DevOps 水平往往较低。工具往往是最好改变的,但是它产生的价值比较有限。短期内,三个月到六个月的时间,工具落地并适应后,DevOps 工具将会帮助大型的研发组织减少组织的沟通摩擦并提升企业的反馈速度,从而提升质量和加快交付速度。 在工具选择上,在保证安全性与灵活性的基础上与自身业务模式有相关性的工具是最好的选择,简单概括就是可以利用工具搭建起一套符合公司运作工作流,还有一个很重要的因素是这套工具最好可以实现在不同部门间流转,让跨部门跨团队形成有效信息流通。 而刚开始的研发效能提升中间蕴含着的是组织的变革。根据逆康威定律,你会得到一个符合 DevOps 的组织。但根据康威定律,组织也会对 DevOps 工具产生影响。究竟是组织影响工具还是工具影响组织,要看哪方的变更成本更大。 _知名科技公司的组织架构_在工具落地建成的六个月之后,工具的投资可能就不会再产生新的价值,瓶颈也就随之而来。这就是经济学里的边际收益递减规律——只是单独增加某一要素,它的边际收益一定是逐渐递减的。很多企业也是在这个阶段数字化转型的脚步就停滞不前。接下来所能做的就是不断优化流程和不断地替换工具。而这些都不会带来质的转变,只有我能从上到下重新梳理我的企业数字化策略的时候才能带来质的改变。通过对产出价值的度量很容易得到这个结论。 DevOps 的主要阻力来自于组织内部的思想,特别是工作者自身的素质提升。做产品的思维和做项目的思维是不同的。做产品需要考虑如何用杠杆原理撬动最大的价值。而做项目则只是固定在一个回报率上,当然这个回报率也会随着竞争者的增加而递减。国内很多的组织的高管很难意识到自己是组织的瓶颈,即便是遇到了,也很难变革。每个企业都有自己的文化和基因,不可能通过复制另外一个企业而生存,也不可能把对方的高管挖过来而成功。都要走出自己的路。这个时候就需要外部顾问的力量。从第三方的角度来观察和提供那些被忽略的事实和“房间里的大象”。 ____________________ 现代管理学家德鲁克说:效率是“以正确的方式做事”,而效能则是“做正确的事”。 ONES 致力于企业级研发管理解决方案,我们将持续邀请到研发管理领域的顶尖咨询机构、大型企业过程改进专家、资深敏捷教练等专家老师,分享研发管理的价值观和方法论,助力企业更好更快发布产品。 企业 DevOps 转型,工具的使用和思维的转变缺一不可。ONES 通过 ONES Pipeline 和 ONES Project 等产品打通 DevOps 全流程,为企业提供专业的技术解决方案。通过搭建 Devops 流水线,将代码提交关联、持续集成与交付、部署结果关联等能力高度集成,软件交付流程可视化展现,加强研发、测试、运维、产品等多角色共同协作,加速交付,提高产品交付质量。 ...

May 28, 2020 · 1 min · jiezi

用敏捷的DevOps拳打研发低效脚踢管控不足

在为客户进行DevOps咨询和提供解决方案时,除了“又快又好”的发布之外,我们发现客户通常还有两大方面需求:开发测试管理问题和运行管理问题。以某大型金融企业为例,该企业开发测试问题主要表现为研发过程的管控不足,这带来了开发效率低、版本质量差、环境交付慢等一系列问题。另外,整个运行环境缺乏统一管理,资源申请和获取周期长,资源利用率低也是当前运行管理中频繁出现的问题。 问题1研发过程无法清晰度量、查看和分析流程规范不标准,各项目各自为战缺少统一的研发管理支撑工具,已有的流程规范无法有效落实解决方案 流程的平台化、固化,自动驱动流程运转 不同的公司有划分阶段不同,同一个公司也有可能会分为不同的阶段。在整个流程体系下,每个角色、每个人要做什么是DevOps落地非常重要的一个关键点。通过平台去把所有的规范固化,需要在流程的每个阶段,把每个人的工作职责,需要遵守的规范,甚至是考核指标、度量数据都确认下来。这样每个人能清晰的了解自己的职责,按图索骥去完成自己的工作。 规范的落地是DevOps能够正常运转的一个重点。从立项到整个需求任务、开发测试、发布上线的过程里,大概50%能规范化并落地到平台中,另外还有些工作例如会议需要人员管控。每个企业中可能有1-2套标准流程,不仅要匹配不同客户的需求,和同一企业中不同项目的需求,还有随着企业对DevOps认识的不断提升,流程也会随着认知不断演进。流程的自定义和灵活性就显得非常重要。 如何自动驱动流程也是一个关键。博云为该企业设计了自定义工作流引擎,整个流程的固化,从前期的准备到后面的需求、研发、不同的测试阶段,都可以通过devops平台上企业自定义的研发工作流来驱动。它不仅能展现当前标准流程的进度,同时企业能够用标准流程去驱动底层的工具链与整个研发管理过程。不管从需求、评审或是运维等角度,整个底层、研发流程的状态变化能够驱动流程和工作引擎的状态变化。例如从需求待开发进入开发阶段后,整个版本也从待规划阶段自动变化到开发阶段。 问题2开发测试环境搭建交付慢,耗时长同一业务系统跨多平台部署,效率低,耗时长,管理复杂物理机、虚拟机、容器各自管理,没有统一视图解决方案 多视角的环境管理 环境管理既重要又很困难。首先底层环境有很多种,可能需要与虚机环境,跟云平台、云管平台对接,还有容器化环境等不同的环境。其次,环境管理有时候是有项目视角的,有时候为这个项目分配了多少环境,同时项目里还有应用、服务、系统等概念,项目中可能有三套系统,并给这三套系统分配了不同的环境。还有一种是按最小粒度去分配,例如有5个服务,每个服务有不同的环境。这几个情况都有可能会出现。从环境角度来看,应用服务是个核心视角,也有项目视角,所以我们为客户设计了树状结构的多视角环境管理支持。这个树状结构有项目—应用—服务三级视角。现在的研发管理流程中,包含非常多的对象。从项目视角来看,它注重的是开发阶段,需求任务缺陷和非常重要的研发管理的项。从代码提交开始,它的管理对象是应用和服务,比如代码是和哪个服务关联,制品是和哪个服务关联,pipeline和部署也是与应用服务关联。也就是说项目/版本,应用/服务是我们两个核心的管理对象,那如何才能实现兼容这两种方式? 我们在实践中发现,以应用服务视角去统一或以项目视角去统一这两点都是需要的。在代码之前需要的是项目视角,在代码之后最核心的是应用服务视角。通过应用服务去关联代码、环境、pipeline、制品,这是最自然的也是最好用的一套逻辑。还有一个就是人员,除了角色对象这些东西外,它核心也会体现在所有绩效、工作量和团队。 环境管理的落地流程从整个环境规划开始。在流程的前端,一开始就给项目申请环境与配额,最后环境细化的分配到各个项目和应用中去。然后通过pipeline的自动化把环境部署起来,由环境申请到环境释放这样一个过程,底层与各种各样的资源平台去对接。 整个资源环境管理的设计能够兼容各种各样的需求。应用本身是可能有很多环境的,我们实现了一个应用能随时创建一套自己可用的环境,在整个资源平台与不同的容器平台、虚机环境、云管平台上创建的项目相匹配,并进行多个关联。 问题3缺乏开发测试发布环境的质量管控缺乏开发规范或者规范难落地,代码质量差编译打包部署自动化程度低,效率低,易出错解决方案 以版本为核心的过程管理和追溯 以版本为核心的过程管理和追溯,我们理解是整个DevOps管理设计或是研发管理过程的核心的需求。从需求开始,代码、制品、包括线上的实例,都是能与版本进行关联。但一直以来,很多企业的研发管理过程是做不到这点的。我们通过DevOps平台的整体自动化驱动,以版本为核心,从整个的从需求到代码、制品、构建、部署和实例的管理过程给支撑起来,将它与关联项进行匹配,使信息实现同步。这样能实现线上运行的版本对应它的需求,能够清晰的了解制品关联哪些需求和版本。这样能够解决整个线上版本和线下版本或不同测试环境里的版本不一致的问题。 这里关键的核心点是研发提测过程。整个研发过程中,研发提测把需求圈出来告诉测试,圈完之后就会走自己的pipeline,pipeline最后生成制品,这样就实现了制品与需求的关联。平台还有提测单,提测单中不仅有制品和需求的信息,还会有质量检查的信息。这个信息会一直跟着流转到整个的版本测试报告中,也就是说我们不但知道这次测试的报告,还能知道所有中间过程中安全检查和自动化测试的结果,是清晰可见的,这是一个关联和信息匹配的过程。 另外一个就是以版本为桥梁打通开发测试和生产环境。在开发测试和生产的过渡过程中,版本包含提测单、需求,也包含制品、配置、脚本这些所有的信息,这样从开发测试转化生产时,不仅是把制品转过去,也包含了整个配置和脚本信息,这样不仅能实现制品包移植,它的配置信息、脚本信息与开发测试环境也是一致的。 问题4企业或项目个性化的问题和需求如何满足解决方案 强大的配置能力,适应当前与未来 不管是驱动团队运转的自定义工作流,还是自定义的度量指标等功能,DevOps平台都能够随着客户内部团队的演进适应当前的需求还有未来的变化。另外,前台的自定义DevOps门户能够把整个DevOps流程驱动起来并可视化展现出来。对开发人员来讲,接收到的需求能在界面上看到,做代码也能在同一个界面上看到,制品、部署发布上线,需要处理的流程的工作,都能在门户中心看到。这样就不需要用许多工具和每天登录十多个系统,就按看到的流程走。 整个工具的驱动也是一个重点与难点。工具较多,每个客户使用的工具也不一样。不管是对接还是纳管,通过工具链和门户的能力,把各种不同的工具驱动和管理起来,为开发人员和管理人员带来价值。 问题5平台可用性差解决方案 灵活与可用 目前市场上开源的或一些工具最大的特点就是能力很强,不管是插件化还是配置化,能力很强但是可用性比较差。所以在这个方面,我们花了巨大精力考虑如何实现产品可用性和灵活性的平衡,让可用性强但又很灵活,适应客户的不同需求及特性。整个DevOps实施落地包含三个关键因素——人、流程、工具,博云从团队协作,流程再造和工具集成三个方面,帮助某金融企业实现了业务驱动型团队和标准化规范的敏捷流程,形成持续完善能力。由点及面,循环迭代完成研发测试运维的持续交付转型,打造能够真正落地的DevOps研发运维体系。 将原有的团队转变为以产品组和能力组共同组成的业务驱动型团队;落实敏捷支撑的标准化规范,简化流程从而实现快速迭代;打通应用全生命周期工具集成,形成DevOps的工具链。通过一套敏捷作业管理框架,一组IT工具链和一个能展示所有环节和过程的可视化平台,博云帮助企业实现面向需求-开发-测试-上线等全流程的端到端自动化流水线,驱动整个研发测试管理流程运转,提高企业内部IT资产能力和开发质量管控水平,从而解决开发测试及运行管理中的种种问题,最终使得研发运维团队业务支撑水平能力得到提升。 随着企业数字化转型的加速推进,DevOps将持续发展,BoCloud博云将继续探索用户真实需求,提升产品能力,为用户提供更加灵活、可用性更强的DevOps平台,帮助企业真正建立DevOps文化,推进业务部门与开发团队深度配合,提升研发运维效能,专注创造价值。

May 28, 2020 · 1 min · jiezi