312312

尊敬的华为云客户：为了进一步提升客户体验，华为云软件开发平台DevCloud计划于2021/04/05 和2021/04/18对DevCloud进行升级，升级详情如下：升级时间影响区域升级影响2021/04/05 00:00-06:00（北京时间）东北-大连、华北-北京一、华北-北京四升级期间，DevCloud所有服务不可用2021/04/18 00:00-06:00（北京时间）东北-大连、华北-北京一、华北-北京四升级期间，DevCloud所有服务不可用请留意您的业务情况，如有操作请避开升级时间进行，相关事宜做好安排。如您有任何问题，可随时通过工单或者服务热线（ 4000-955-988或950808 ）与我们联系。给您带来不便，敬请谅解。感谢您对华为云的支持！ 

当前，华为云企业主机安全在功能上又有了新的突破，一举发布四大功能，为云主机的安全防护，再添坚硬 “铠甲”！安全防护无边界，应对未来物联网时代的安全挑战，智者需虑远，华为云企业主机安全服务此次发布的新功能中，就有不少是基于主流发展趋势而拓展的防御能力。01支持ARM，鲲鹏主机可安装使用在云计算飞速发展的今天，功耗更低，成本更低的ARM，相对更符合云时代的企业计算需求。鲲鹏的出现，让ARM的魅力得以展现。未来华为云的全部基础服务和大量的主要服务都会基于鲲鹏来构建。虽然ARM架构的安全性和稳定性更高，但与X86架构一样会面临主机安全风险，账户破解、弱口令和恶意程序等威胁。华为云服务也都将于鲲鹏生态完全匹配，企业主机安全的第一大功能就是能完美适配ARM，鲲鹏主机可放心安装使用。02支持IPV6，可阻断IPV6地址发起的攻击 IPV6的发展趋势2019年11月24日，欧洲RIPE确认全球的IPV4地址正式耗尽，随着云计算、大数据、人工智能等新兴互联网的兴起，IPV6地址的使用人数越来越多。据中国信通院统计，截至2019年7月起，全国已有12.78 亿用户获得IPV6地址（如图1），互联网应用IPv6 活跃用户数也已达到2.01亿（如图2）。图1.IPV6用户数现状（来源于中国信通院）图2. 2019 年我国IPv6 活跃用户数增长情况（来源于中国信通院）在政府部门的推动下，IPV6将会实现快速的大规模部署，在此形势下，网络安全将会遇到更多新的挑战。 IPV6带来的安全挑战较之IPv4，虽然IPv6在设计之初就将安全因素考虑了进去，因其地址空间巨大，在应对部分安全攻击方面有着较大优势。但仍然存在着不少安全风险。随着IPv6 网络和业务开始上线，IPv6 网络攻击事件也开始出现，IPv6 网络安全问题相继浮出水面。中国信息通讯研究院发布的《筑牢下一代互联网安全防线—IPv6 网络安全白皮书》指出，据国内安全厂商统计，2019上半年共监测发现超过9 万起IPv6 网络攻击，其中，攻击对象覆盖政府部门、事业单位、教育机构等单位（如图3）。图3. 2019 年上半年政企事业单位遭受IPv6 攻击情况（来源于中国信通院）在 2019 年3 月，国内安全厂商拦截到攻击源为IPv6 地址的网络攻击8000 万起（IPv6 网络攻击包括攻击源为IPv6 地址的攻击，以及利用IPv6 网络或安全问题发起的各类攻）。随着IPV6的发展，带来的安全挑战在于：1因IPV6的地址空间巨大，接入网络的设备将会更多，设备数量增加，遭受到的网络攻击及潜伏的安全威胁也将会更大；2IPV4向IPV6升级需要一个长期的过渡，这就需要安全产品能同时支持IPV4和IPV6；3随着IPV6规模的扩大，会不断出现一些新型的攻击方式；华为云企业主机安全同时支持IPV6和IPV4，可检测阻断源于IPV6地址发起的攻击，为用户提供IPV6的防御能力，有足够底气应对IPV6时代带来的安全挑战。华为云企业主机安全 IPv6测试用例03支持安全报告订阅一份完整的安全报告，有助于帮助企业更加精准、及时的了解主机的安全状态，以便快速实施有效的安全防护措施。华为云此次发布的主机安全企业版，即新增了安全报告订阅功能。· 可保存180天，满足等保合规安全报告统计周期分周和月，可保存180天，满足等保合规的要求。· 支持在线查看和下载报告可在线查看，也支持下载，方便内部人员传阅。· 多维度展示，全方位掌握报告会从入侵风险、漏洞风险、基线风险等多种维度展示当前主机的安全现状，让企业全方位掌握主机的安全状况。04支持漏洞一键修复扫描漏洞容易，但修复漏洞是一个大工程，尤其是针对有着上百台云主机的大企业，耗时长，还可能误操作。华为云企业主机安全此次发布的一键修复漏洞就完美解决了这个问题，支持漏洞批量修复，助力企业实现自动化运营。01丰富的漏洞库，实时更新13万+的漏洞库足以覆盖大部分漏洞，支持实时更新，新型的漏洞也能在24小时内添加入库。02一键修复，方便运维支持一键下载补丁文件并静默安装更新，及时查缺补漏，把漏洞风险降到最低，尤其对有着成百上千台主机的大企业来说，能大大提高运维效率。目前漏洞一键修复功能处于邀测阶段，如有需要，可通过您的客户经理进行申请。防护主机安全的重要性不言而喻，主机一旦中招整个系统都将被攻陷，必然造成巨大损失。360°全方位守护主机安全，为您的主机安排一位防御能力MAX的保护神——主机安全，十分必要！原文链接：https://mp.weixin.qq.com/s/DDqYdNb6LTMIHZPP9vNOvg

尊敬的华为云客户：华为云对软件开发平台DevCloud基础版的产品规格容量与价格进行调整，新价格于 2021/03/26 12:00 （北京时间）正式生效，生效后软件开发平台DevCloud基础版新购、续费均按调整后价格收取费用，已购买基础版的用户自动调整为新规格容量。具体产品规格容量与价格详情如下：产品规格调整前调整后              基础版产品规格容量 免费，5人（含）以下 项目管理：500M存储空间 代码托管：500M存储空间 代码检查：每任务最大1个并发 流水线：每任务最大5个并发 编译构建：每任务最大5个并发，600 分钟累计构建时长 部署：1个并发 测试管理：测试计划和用例管理 接口测试：5个并发用例，2个并发套件，每套件最大10个并发用例，30分钟累计测试时长 发布：500M存储空间5人（含）以下免费，新增人数50元/人/月项目管理：10G 存储空间代码托管：10G 存储空间代码检查：每任务最大1个并发 流水线：每任务最大5个并发编译构建：每任务最大5个并发，600分钟构建时长/月 部署：1个并发 测试管理：测试计划和用例管理 接口测试：5个并发用例，2个并发套件，每套件最大10个并发用例，30分钟测试时长/月 发布：10G存储空间具体价格请在新价格生效后参考产品的计费详情页。如您有任何问题，可随时通过工单或者服务热线（4000-955-988或950808）与我们联系。感谢您对华为云的支持！ 

吉佳通达作为专业的定制软件开发商，一直秉承为政府和企业信息化建设提供先进技术、成熟产品和优质服务为目标。凭借多年来为行业客户提供定制、开发、维护服务的经验，建立了一套完整的软件定制开发服务规范及流程。吉佳通达软件定制化开发遵循的项目开发管理流程：根据用户的要求进行需求调研、进行软件设计，提供新建系统的方案设想，并进行可行性分析；在开发过程严格遵循开发管理规范：在程序编码前进行系统的概要设计和详细设计；在程序编制结束后进行软件测试、项目交付、对用户有关人员进行操作培训，并提供软件正常运行后常规维护。公司根据定制软件开发项目特点，建立了符合CMMI2.0三级的标准化软件开发规范，使项目开发过程更加具有稳定性和可控性；通过建立项目管理流程，形成一个有机的整体，实现软件开发时间、成本和功能可跟踪和可控制，保证产品的质量。成熟的软件开发框架软件开发框架就如同是软件开发系统的地基, 属于软件开发系统核心因素，对于一个系统所存在的基本功能、宏观特性、主体结构起到决定性的作用。当定制项目实施的时候，如果没有一个完整架构，会导致接口不统一、业务逻辑接口多样、代码混乱，整体开发效率也会相应降低，后期维护相对繁琐。吉佳通达软件定制开发采用基于VUE的先进的、成熟的软件开发框架。基于此框架创建可维护性和可测试性更强的代码库，为客户带来更加丰富的交互体验；为企业和客户降低成本，提高项目质量；改善客户满意程度、控制开发进度等。同时采用基于VUE的开发框架可将相关技术以代码、文档、模型等方式固化下来，便于项目二次开发及升级。专业的技术团队公司核心团队由具备10年以上资深高级系统分析师、高级软件架构师、软件设计师等人员组成，根据业务的需求合理调配人员,保障开发效率最大化,提高客户满意度。技术开发团队包括：前端开发、后台开发、算法分析与建模，JAVA开发组、C++开发组、Python开发组、移动开发组、VUE框架、测试组和系统集成组，团队人员分工明确；设计、产品和运营构成后端支撑，对接客户的需要,进行前期的业务沟通、项目跟进、后期的运营指导和维护。14年行业定制开发典型案例 吉佳通达凭借完善、成熟的管理和开发流程，确保为客户提供高质量的服务和专业定制化产品；遵循严格的安全标准，实施严密的安全措施，以保护客户的信息安全；公司的综合实力是帮助客户建立成熟可靠、切实可用的定制应用的基础、是提供最专业定制开发服务的坚实保障。

互联网改变人们的衣食住行，也在悄然无声间为根植之上的软件行业带来颠覆性的变化，尤其是在云服务这样新的基础设施的助推下，从早期的瀑布开发，到中期的敏捷开发以及如今大热的DevOps，互联网正在重塑软件开发模式。2013年踏入互联网浪潮的张浩，在8年的软件开发中，一一经历了这三段“历史进程”，感受到技术迭代更新背后的魅力。 瀑布开发，漫长而又痛苦张浩的开发经验丰富，既在中兴做过大数据分析系统的开发，也在富士通参与过安卓底层系统的研发工作。2013年，张浩投身互联网大潮，陆陆续续做了联通定制应用以及一些政府定制项目的研发。回忆起当年做安卓开发，张浩觉得万分“痛苦”，憧憬着“如果按一个键就把整个流程处理掉”的美好愿景。彼时的软件开发迭代周期非常漫长，项目规划起步半年起。由于涉及到系统底层代码，每修改一次查看预览都需要编译整个Android系统，雪上加霜的是当时他们还缺少编译服务器，编译一下又是半天起步，非常影响开发效率。后来有了编译服务器，虽然速度从半天缩短到2小时，但由于编译服务器是环境复杂的Linux，团队只有一人会操作。“一旦他休息，大家都没法验证自己的代码，更别提部署。”这也是做Android开发最痛苦的阶段，然而编译的繁琐只是第一关，后面还有开发周期的问题。互联网早期的软件开发是瀑布开发模型，在需求评审阶段，产品经理给到的是完整、清晰、固定的需求，研发人员只要根据需求在约定的时间点进行交差即可，迭代的频率可能是1月1次，也可能是1个季度1次。在这种开发模式下，研发人员聚焦于功能开发，完成后交付测试团队进行测试。测试团队经过反复的测试与问题修复后，交付运维团队进行上线，此后生产环境的可用性稳定性等工作全由运维负责。看似一马平川的开发模式背后却有不少痢疾：需求不能快速得到验证，团队花费半年的时间开发出来的东西可能早已经不适合市场了，或者在开发阶段研发需求理解不到位，等到后期验证时发现有问题再去做调整耽误整体工期。这种“能用、能解决问题即可”的开发模式显然与后期互联网的短平快格格不入，张浩意识到这一点后，将眼光投向了敏捷开发。互联网节奏下，从敏捷开发到DevOps此时已经到了移动互联网的红利初期，业务开发的关注点向着“好用、好玩”转变，开发模式也渐渐演变为敏捷开发模型。敏捷开发模型面对的是频繁的需求变化，要求快速开发。张浩提到，敏捷开发比较流行的实际案例是Scrum、XP极限编程。在新迭代（一般2-6周）开始前，产品经理将需求拆分成具体的开发任务，研发人员认领人物，每日站会进行任务的review，直到开发完成，发布新的可用版本。然而，敏捷开发依然很难跟上互联网乃至新技术的步伐。《中国互联网发展报告2020》中提到，截至2019年底，我国移动互联网用户规模达13.19亿。移动互联网跑马圈地的红利期渐渐消失，互联网企业之间的竞争也愈加激烈。当同一块蛋糕很多人来抢，快速迭代产品占领市场、占据用户心智成为各互联网公司的目标。为了实现快速交付，应对市场变化和用户需求，此时的开发模型演变成DevOps：持续开发、持续集成、持续测试、持续部署、持续监控，每一次代码的改动都触发一次校验，每天每时每刻都可进行新版本的上线。虽然DevOps市场需求显现，但很多团队对如何选择DevOps工具和如何开展DevOps实践没有清晰的认知。张浩强调，相比于传统软件模式，公有云服务模式成为企业快速实践DevOps的优先选择。 DevCloud的魅力恰巧在2019年这一年，一个特殊的机会，张浩接触到了华为云DevCloud，当时他所在的公司引入DevCloud对所有项目进行升级管理。DevCloud是集华为30年研发实践和理念，打造的全云化研发场景。开发、测试、部署、运维、运营等一切研发活动都在云中完成，全面支撑落地DevOps。这段升级经历带给张浩最大的感触是，“我们的开发进度一下子提升了一个台阶。”以前是开发人员在自己电脑上打包再远程连接到服务器去部署，整个项目部署完大概需要半小时到一小时，如果同时部署多台服务器，半天时间就浪费了，而且还时不时会碰到开发者不小心把测试代码部署到服务器上的情况。整个项目管理迁移到华为云上后，所有开发者对用户需求更明确，也不容易遗漏bug。而且云上的自动部署不仅节省时间，还杜绝了开发者将自己本地测试代码部署到服务器的情况。整个开发流程从需求设计、开发编程，再到测试、bug修复、发布运营形成了一个完整的闭环。有着十多年开发经验的张浩，叹服于DevCloud带来的开发效率的极大提升。“从需求下发、代码提交、编译构建、测试与验证到部署与运维，DevCloud提供了软件研发托管运维端到端的支持。”在他看来，有云厂商的推动，DevOps势头会越来越猛。一方面云厂商在不断吸引和转化自身云平台的用户使用其DevOps服务，另一方面也在不断加强市场教育培育。预计未来1到2年，DevOps的企业级用户和个人开发者数量将呈现高速增长态势。

尊敬的华为云客户：为了进一步提升客户体验，华为云软件开发平台DevCloud计划于2020/12/13 00:00-04:00（北京时间）对DevCloud进行升级。影响范围：华东-上海一、华东-上海二、华南-广州、华南-深圳升级影响：升级期间，DevCloud所有服务不可用。请留意您的业务情况，如有操作请避开升级时间进行，并提前做好相关事宜安排。如您有任何问题，可随时通过工单或者服务热线（ 4000-955-988或950808 ）与我们联系。给您带来不便，敬请谅解。感谢您对华为云的支持！

最新动态2021.9.2【云享MindTalks·第十七期】#探索性数据分析方法#复杂数据的调查、汇总、理解与应用之道2021.8.12【云享MindTalks·第十六期】#AI在高性能领域的应用#要不要搞AI，听听中科大学霸的介绍吧！2021.6.3【云享MindTalks·第十五期】#迎接vue3.0的时代#VueConf 2021开发者大会全面解读2021.3.4【云享MindTalks·第十三期】#Copy攻城狮与ModelArts情史#AI应用开发实践过程直播分享2021.2.4【云享MindTalks·第十二期】#中科院研究所研发工程师黎老师讲双目摄像头视觉#为机器装备“人眼”2021.1.21【云享MindTalks·第十一期】#用Python开发飞机大战#华为云云享专家王新从理论到实操的全套分享2021.1.07【云享MindTalks·第十期】#2021新年第一弹#华为云DevCloud首席布道师直播赋能#赶快加群与大佬对话吧~2020.12.24【云享MindTalks·第九期】#深度学习就像个傻瓜#东南大学博士张铄与你一起探讨诱导AI行动！2020.12.17【云享MindTalks·第八期】#神秘的夜幕团队成员张冶青加入群聊#Python与Go不得不说的选型之争2020.12.10【云享MindTalks·第七期】#35岁的IoT新人李万龙教你什么叫什么时候开始都不晚！#一个成功出圈的demo——家校物联2020.12.03【云享MindTalks·第六期】#嗯嗯嗯？Vallnet创始人刘兵也进群了？#风风雨雨这些年，区块链技术未来大可期!2020.11.24【云享MindTalks·第五期】#云享专家玉城老师这回带了TA来！还有一沓会员卡？#vue.js3.0版本那些不为人知的秘密2020.11.17【云享MindTalks·第四期】#多年敏捷转型经验大咖黄灵现身群聊#介绍如何借助用户故事地图拆解MVP2020.11.12【云享MindTalks·第三期】#云享专家技术拆解官林韩秋现身群聊#揭秘python与2020美国大选之间不得不说的事……2020.10.29【云享MindTalks·第二期】#云享专家张常乐在线陪聊#探秘双十一百万PV，Java电商平台开发技能图谱你get了吗？2020.10.20【云享MindTalks·第一期】#云享专家张宇已加入群聊#可盐可甜张老师进群聊前端，直播说不完我们群里继续讨论活动介绍云享MindTalks 由华为云DevCloud团队携手云享专家共同策划进行的系列轻量级知识分享类活动。各业界大咖纷纷现身微信群聊，以即时对话形式，来进行最直接的技术交流和思想碰撞。他们将多年的学习历程结合一线实战经验，将方法，将结果，将他们看到的风景展现出来，予以方向。一周一个二十分钟，碎片化的时间学习高度压缩的知识内容，一次一位业界优秀的专家老师面对面的交流，有问必答，资源共享。没有冗长严肃的讲座，没有复杂的系列课堂，仅一个主题一群朋友，没有回放，也没有留存，微信群聊限时解散。人数有限，时间有限！与数百名云享专家近距离接触的机会有限!仅此一次！不可错过！课后习题点击链接即可收到课后习题，还有勋章可以拿点击链接通过考核进入云享MindTalks VIP群截图发给小助手，更多资源和活动特权等你来拿！有什么需求和反馈也可以直接联系小助手哦！（小助手微信）

【摘要】本文将从DevOps模式下对测试人员的活动的变化，以及常用的测试技术层面进行解读。项目的软件开发模式主要经历瀑布模型、敏捷开发和DevOps这几个阶段，其中DevOps主要解决开发和运维、运营之间的隔阂，更强调自需求设计至生产部署的端到端协同运作，更强调精益、高效；更强调想尽办法剔除每个环节的浪费，极致追求每个环节的高生产率，达到快速、高质量上线的目的。本文将从DevOps模式下对测试人员的活动的变化，以及常用的测试技术层面进行解读。1、为什么会有DevOps？项目的软件开发模式主要经历了以下几个阶段：瀑布模型解决了分工协作困难的问题，但是一年1~2次的发布流程太慢，且无法满足日益变化的需求变更。敏捷开发解决了需求频繁变更、上线慢的问题。但是未解决开发和运维的鸿沟，甚至给开发和维护之间增加了非常多困难和争议。DevOps在敏捷的基础上，从E2E的角度来考量。主要解决开发和运维、运营之间的隔阂，更强调自需求设计至生产部署的端到端协同运作，更强调精益、高效；更强调想尽办法剔除每个环节的浪费，极致追求每个环节的高生产率，达到快速、高质量上线的目的：2、DevOps模式给软件测试带来了哪些变化：一个DevOps活动的流程如上图所示，可以看到测试已经融入到DevOps流程中的一环，DevOps模式下的测试流程也会发生变化。以我们团队为例，看下在DevOps模式下常用的测试方法和活动：可以看出，1、全流程测试：测试活动已经贯穿到DevOps全环节，DevOps模式下测试并未消失，而是嵌入到全流程的阈值评估点中。2、测试向左移动：开发团队也要承担起测试的任务，测试团队也会接入到开发阶段的测试及测试指导活动3、自动化权重增加：接口自动化、契约自动化测试、功能自动化被大量使用，用来提高上线测试进度4、UT弱化，API和契约测试更被愿意接受：UT自动化依旧存在，由于UT维护工作量巨大，且需求变化快，导致UT的投入产出不成比例，UT自动化权重下降，使用API和契约、Mock等测试替代。5、测试菱形模型：有专家指出，DevOps模式下，测试的倒三角模型依旧存在，但是测试层依旧很重要，甚至要做厚测试层，呈现菱形模型，个人认可这种菱形模型。6、部署自动化，灰度发布越来越受欢迎：服务的部署已经完全被自动化工具替换，测试基于部署的环境进行自助测试。同时，灰度发布和A/B测试很好的解决了流程过快导致的全局性风险，升级和回退成为常规活动。7、测试人员依旧必要：服务测试和解决方案测试依旧很重要，同时也是DevOPS流程中发现问题最多的环节，是DevOps环节中不可或缺的一环。8、在线测试和度量兴起：OPS阶段的测试和在线监控越来越被接受，权重增加，比如在线拨测、在线测试、在线度量。9、平台工具的重要性：DevOps流程环节打通后，更加依赖平台工具的能力做支撑，比如华为的DevOps平台DevCloud软件开发云、ServiceStage等都提供了很好的流程打通能力，使整个流程得心应手，降低准入门槛。结语：以上就是DevOps模式下常用的测试方法和活动，希望对相关小伙伴的工作带来一些指导意义。下一期，我们将介绍下具体的DevOps测试技术和测试实践，敬请关注！

欢迎小伙伴们体验《基于CloudDeploy十分钟搭建minikube》实验，有任何问题都可以在这里讨论交流哦！通过本实验：§   您将学习    了解和熟悉使用一台ECS搭建Kubernetes测试集群（Minikube），并在该集群部署一个容器应用，针对该应用做升级，扩容和删除等操作。通过实战让您对容器的概念有更深理解。§   您将体验    通过本实验，您可体验如何完成部署主机、部署脚本和部署任务，并访问主机，部署应用和访问应用等操作§   您将掌握       完成此实验后，您可以掌握以下内容：     1、 如何搭建单机环境下的Kubernetes集群     2、 如何在单机集群部署和测试容器应用    3、如何使用云上部署服务CloudDeploy简化部署搭建工作实验开始前，推荐您先学习相关课程，掌握实验背景知识：《人人学云容器》《管理与部署：业务云化助推器》《7天玩转容器之基础入门课》实验过程中，如有任何问题可在该帖进行交流，也可以添加华为云学院小助手（微信号：HWcloudedu），专业人员为您实时解疑答惑，互相交流，共同进步！如要提出问题，请详细描述您的问题及出现的步骤，附上实验操作截图，如有其他参考信息可一并附上。

获奖名单当前参与抽奖有效层数23层，抽取3个礼品，获奖名单如下，请获奖用户反馈收货地址和礼品名称。收货地址反馈：https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=f692a7064e7c49f781bf377a296ed314>>什么是微认证？一站式在线学习、实验与考试，零基础也可学习前沿技术，快速获得场景化的技能提升。持证人才，在申请以下权益时，享有优先权哦~01 活动说明5折订购微认证时间： 10月19日-11月13日 彩蛋时间：11月11日12:00-14:00 限时免费 基于华为云DevCloud的托马斯商城 活动时间：10 月19日-11月30日活动说明：1.呼朋唤友来学习，华为云DevCloud无限量提供5折优惠券！！彩蛋时间可0元购买指定微认证。2.截止11月30日通过以下03 微认证选购中任一微认证的用户，可参与抽奖。02 激励计划激励活动      规则：10 月19日-11月30日期间通过以下任意1门微认证（请见03 微认证选购板块），即可参与抽奖！10 月19日-11月30日期间，通过（请见03 微认证选购板块）中的多门微认证，每多通过一个微认证多一个抽奖名额。抽奖时间：12月1日抽奖礼品：              华为智能体脂秤（黑色）                           JavaScript高级程序设计  说明：抽奖比例：每15名通过指定微认证的用户抽取1个智能体脂称，1本JavaScript高级程序设计书籍，不足15名时只抽取体脂秤或JavaScript高级程序设计其中一个礼品。例如当有19人参与抽奖时，则礼品包含1个体脂秤，2本JavaScript高级程序设计。注意：封顶抽取5个体脂称，5本书。03 微认证选购5折订购微认证时间： 10月19日-11月13日，点击以下标题，立即前往>>>基于华为云DevCloud的托马斯商城随着企业数字化的转型，软件云化是大势所趋。通过本实验的学习能够在华为云Devcloud进行一站式云端项目管理。解决了开发人员和运维人员之间的冲突。华为企业级JAVA编程规范对软件开发人员来说，此规范可以保证软件产品的质量，可以作为和其他程序员沟通的标准，若编码规则是建立在广泛的共识之上，更有利于产品的发展。搭建个人博客平台使用华为云DevCloud、RDS等云服务在SpringBoot基础上搭建BootDo个人博客，让软件开发简单高效。黑白棋实时对战游戏开发以黑白棋开发为例，借助华为云服务以及DevCloud，实现高效的软件开发，体验云端部署带来的便捷。0元购微认证时间：11月11日12:00-14:00 基于华为云DevCloud的托马斯商城04 活动规则1、开发者通过微认证后，请在本活动贴回复微认证证书截图（已设置仅作者可见）+华为云账号，每一门微认证单独回复一楼。2、活动结束时，我们将挑选满足条件的用户进行抽奖。

     一、初见        我很高兴再次来到华为云DevCloud软件平台，进行一次系统化开发的实践，几个月之前完成了口罩预约管理系统的开发，这次完成了啤酒供需数字化管理系统的开发。对于系统开发非常感兴趣，能够学习到总体框架知识，所以，我看到了这次比赛，决定继续学习App Engine开发平台的开发，掌握更加深刻的知识。        华为云提供的这次大赛给了我一次很好的实战机会，有老师专业的指导和QQ群里面大家的热情帮助，大赛竞争也比较激烈，大家也非常积极。我觉得在这个比赛过程中，平台提供的开发资源和相互学习交流，这些收获是最大的。下面我分享的是赛道二啤酒供需数字化管理系统开发的整个过程和思路。     二、开发        开发周期短，获得的效果好。这得益于App Engine平台的友好界面和丰富的系统教程，这也是平台很大的优点。        1、主赛题                因为有详细的指导手册，我在较短时间内完成了主赛题的完整开发，这部分我进行比较顺利，让我有更多时间测试系统找出不足之处。其中，第一个Bug是在期望到达时间的Date类型，从预约上面没有错误，在出库时候发现变为了Datetime类型，经过一段时间的观察和修改，解决了这个问题。第二个，接关单按钮不起作用，这个排错需要从模型绑定开始，开始我从自定义JS代码入手，但是没有起效果，后来仔细研究了一番，发现是模型绑定错误，服务模型是takeAndclose而不是editMgtInfo。第三个，接关单对于订单状态没有验证，测试系统过程尝试了不同订单状态的接关单，都可以通过，导致了数据错误问题，后来修改了自定义JS代码，传入订单状态的参数进行判断，符合当前操作才能接关单。这是我开发的系统界面，包括手机端和电脑端        2、附加题        这部分完成了DMAX大屏界面的开发，关键步骤在于与主赛题开发的系统各个接口 进行交互，从接口获取订单数据信息，呈现于大屏的各个统计图上面。    三、总结这次在App Engine平台实践开发确实收获许多，啤酒供需数字化管理系统的开发是一个相对完整的系统开发过程。平台提供了很方便的图形化交互，很大的减少了编写代码的繁琐。另外，在啤酒管理系统的开发中，App Engine将项目合理地呈现处理，包括前端页面设计、模型数据的绑定，后端脚本的逻辑处理，以及各接口的调用。这些对于系统开发都是很重要的因素。我对此赛题的见解，在主赛题有详细的教程，题目更侧重于熟悉平台的各项功能，其中也有需要自己根据前面学习之后，运用到系统开发中，比如接关单功能的数据模型，附加题也是学习之后的一种应用，考验开发者细心和app实现的细节，向优秀学习！最后，贴上我的系统开发二维码。

敏捷这个词虽然被很多开发人员挂在嘴边，但真正理解并能用敏捷解决实际问题的其实少之又少。很多公司开始实践敏捷，但多数被伪敏捷折腾一痛，失败告终。为什么会这样？难道敏捷出了问题，或者说敏捷转型有这么多痛点，敏捷还适合软件开发吗？在敏捷专家黄隽看来，“如果本身对敏捷开发就存在误解，这很容易导致错误的实践方式。”那么，敏捷的正确打开方式是什么？且听黄隽慢慢道来。与敏捷结缘黄隽最开始接触敏捷时，其实是有点排斥的，因为他一直处于传统开发模式状态下，一时很难改变传统软件开发的固定思维模式。直到2012年初，当时在IBM工作的他，接触了非常多的相关培训和实践，随着了解的深入，黄隽逐渐跳出了当初的思维定式，对敏捷产生深厚的兴趣。黄隽认为，“敏捷开发只是一个指导思想和原则，并没有给出具体的实施步骤。在实际工作中，如果企业只是觉得不用敏捷好像很老土，一再对外强调敏捷开发是没有意义的。重要的是在敏捷原则和核心价值观的指引下，哪些实践和方法可以帮助达到目标，或者如何解决这些问题从而达到目标。”在从事敏捷开发过程中，黄隽看到许多企业因为认知偏差走进了死胡同，更加坚定了他的敏捷开发之路。也正是因为一直从事敏捷开发工作，黄隽机缘巧合下接触到了华为云软件开发云DevCloud。DevCloud是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台，它面向开发者提供研发工具服务，让软件开发简单高效。“和华为云几位敏捷专家分享布道的日子里，接触了很多企业用户、老板、高校教师和领导，更深刻的了解到企业转型和高校产教融合的很多痛点，一种要帮助解决痛点的责任油然而生。”黄隽笑言，“随后，我们就一起创建了‘敏捷江湖桃花岛社区’，专门解决敏捷和DevOps转型痛点问题。”                                               图：敏捷江湖桃花岛线下沙龙101敏捷转型痛点主题配图在诸多转型问题中，黄隽发现多数企业有一个共性的难题：研发团队经常会提到的Backlog管理问题，特别是那些突发性的工作应该如何管理。下面黄隽将对提到的这些痛点问题做详细阐述，从事研发的团队可以参考。研发团队如何管理琐碎、突发性工作？先看看解决方案思路：管理好工作项是解决问题的核心，那么在形成工作项之前，我们需要解决谁对工作项负责或者说工作项来源的问题，然后要针对工作项做好工作计划，这样开发团队才能很好的执行。首先，明确产品经理为需求责任人，做到需求来源唯一。其次，梳理产品待办列表，高优先级的工作项先做。第三，重新定计划，确保团队容量适合，合理更新迭代目标。第四，回顾总结，选出改善点，下个迭代做得更好。最后，几个迭代下来，度量分析，不断改善。另外，同步需要进行的是人才的培养，向跨职能型团队努力。解决方案思路示意图如下：解决方案思路示意图 剖析解决方案，一步步解决Backlog管理问题1、明确需求责任人一方面，需求责任人必须很好地理解项目中的利益干系人、客户和用户的需要（包括前面提到的突发工作项）及其优先级。同时，需求责任人还要在版本、迭代和Backlog层面都持续做出良好的经济决策，管理经济效益。为了统一叫法、便于理解，后面需求责任人都由产品经理充当（类似Scrum框架中的产品负责人）。总结一下，产品经理的主要职责如下图所示：产品经理主要职责图产品经理需要与利益干系人充分沟通，确定这些突发的工作优先级别，同时从业务价值和管理经济效益等维度考虑，明确是否一定要在本迭代中完成。一旦确定这些突发工作属于高优先级，必须在本迭代中完成，那就需要重新梳理工作项了。 2、梳理产品待办列表梳理产品待办列表，就是将高优先级的工作项放到迭代待办列表中先做。下图说明了通过梳理活动改变Backlog的结构：梳理活动改变Backlog的结构图梳理后，对应DevCloud中的体现：DevCloud梳理活动结果图产品经理梳理后，如图高亮部分，突发性培训任务的工作项得到了合理的优先级，同时它是被细化的，而且是经过工作量估算的。产品经理是梳理活动的最终决策者，优秀的产品经理能够充分协调利益干系人，安排足够的时间，并根据团队的特点和项目类型来开展梳理活动。同时团队还要估算新加入突发工作的工作量，帮助产品经理根据技术依赖关系和资源约束排列工作项的优先顺序，如果新加入突发性培训任务的工作项优先级高，那么就会纳入本迭代代办列表中。 3、重新定计划重新定计划，确保团队容量适合，合理更新迭代目标。敏捷宣言中提倡“响应变化高于遵循计划”，盲目的相信计划往往会让我们忽视“计划可能有错”这个事实。在敏捷开发过程中，目标是快速重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。原计划准备做的工作项可能被移入到下一个迭代中实现，这里体现的是“等价交换原则”，意思是用优先级高的突发性工作项，替掉了同等工作量的其它工作项，这也是为了保证团队按照稳定的节奏交付，等价交换示意图如下：等价交换示意图具体在DevCloud中的体现，如等价交换图一和等价交换图二所示。等价交换图一等价交换图二最后，从迭代中选取差不多工作量的低优先级工作项移回到Backlog中，即在DevCloud中完成了工作项的等价交换。 4、迭代回顾，识别改善点迭代回顾是一个会议，目标是持续改进流程，以提高士气和效率。几个迭代下来，需要对这类突发工作进行度量分析，识别改善点，持续改善。虽然我们提倡响应变化高于遵循计划，但执行迭代的时候也需要团队在不受干扰的情况下全力以赴。因此，就得思考为什么每个迭代中都有外界的干扰（突发工作）存在，团队共同分析和找到办法才是解决问题之道。这里给出一个DevCloud的小实践，可以提供客观数据帮助回顾。新纳入迭代待办列表的突发性工作项可以在DevCould的“模块”下进行管理。也就是说，在新建User Story之前建立一个“突发任务”模块。这是为了在后续几个迭代中对这类突发性工作进行度量分析，为持续改善做准备。图：新建突发模块图图：新建User Story图选择报表—新建报表—自定义报表—增加筛选条件（模块）—按迭代维度—保存。然后对统计出来的数据进行分析，可以以图和表两种方式展示。图：按图展示图图：按表展示图 5、同步进行人才培养如果团队成员都是T型技能的时候，每个任务都有好几个人可以做，那么团队就能够在迭代执行期间全力完成制约工作项流程的任务，更灵活地平衡资源，使团队更高效。所以，同步需要进行的是人才的培养，向跨职能型团队努力。不仅仅可以应对处理突发性工作，而是让团队更高效。以上就是黄隽对于敏捷开发中，研发团队如何管理琐碎、突发性工作的一些思考。总而言之，降低或解决突发性工作对团队的干扰非常重要，它直接影响团队工作的进度和速率，间接影响迭代目标是否能完成，甚至整个项目的成败。所以，一定要重视并想办法一劳永逸解决它。

软件开发过程中你遇到过最让你胆儿颤的bug是什么样的？ 大家来聊一聊

来自一个CEO的叙述在一次企业交流会上，一个公司的CEO提道，“我们公司做敏捷开发的转型有一段时间了，采用的是4周一迭代，相比之前的瀑布式开发，我们可以在每一个月就让客户看到我们的成果物，这确实为公司和客户搭建起了良好的沟通桥梁。但是，也出现了一个不好的情况，就是开发和客户之前的矛盾激化了，由于采用了迭代，所以每个月都有2天开发团队要通宵熬夜，大家苦不堪言。有个别的开发同学，骂完公司骂同事，骂完同事骂客户的，甚至连自己都不放过……”那些暴走在发布前夜的开发，你是否也遇见过呢？感同身受的无奈和愤怒来自开发的一波怒气“我晕，这谁提的代码啊，上来就白页面了，还玩个球啊！”“我倒，我本地都是好用的啊，怎么部署到环境上不行了呢！”“我去，这哪个大兄弟提了这么些代码，太能写了。我和他代码冲突多到想哭！”“我的代码让哪个孙子给覆盖了，我一下午白写了，别让我查出来谁干的哈！”“催催催，催个大脑袋啊，你行你来，不行就别说话，合代码这事是人干的活吗！”“几位大哥，我知道问题出在哪了，我这还有段代码没提交上去呢，嘿嘿，不好意思哈。”“我*！”来自领导的心酸无奈领导：“每次发布前，我都不太想去你们开发那，太压抑了！，你说咋办？”骨干：“咋办，还能咋办，换人呗。一个个都不懂咋开发还能咋办。”领导：“不是都经过笔试面试进来的吗？咋还能不懂开发呢？”骨干：“开发不是开发完了就行，得好用啊。这帮小年轻就知道埋头coding，然后扣出来的都是一堆不好用的代码，不好用倒也没啥，直接就往代码库里提交啊！”领导：“这帮小年轻这么虎吗？”骨干：“这还不算是虎的呢，还那种代码冲突了的，不管三七二十一直接就忽略冲突提交，我有好几回，一拉取最新代码，一面红色啊。”领导：“那你多带带他们，告诉他们怎么做啊！“骨干：“我都告诉过很多遍了，每次都说‘我测了啊！’，‘诶？奇怪了！’，‘不好意思哥，我忘提交了’，就这帮小年轻，我是真心带不动哈。我还是觉得以前瀑布挺好的，要不就变回去得了。“领导：“那不行啊，客户现在挺认可我们的。用敏捷一个月就能看到新做的东西。效果好，客户满意度高。你还是想想办法吧。“骨干：“我看还是换人吧。我是无法阻止别人不**的“领导：“……“问题出在哪里不知道读者读到这里是否感同身受了一下下，如果没有的话，那么恭喜你，你很幸运的加入到了一个优秀的团队或者公司。不过，可能你的IT生涯是不完整的……近些年来，整个IT圈子都在宣扬DevOps，也因此很多人都知道Dev的工作是给应用系统增加新的功能/修复Bug，而Ops的工作是要保持系统的稳定和高性能，而DevOps后就是要调和了Dev和Ops的矛盾、打破二者的壁垒，以更好的面对变化。大家满怀着希望开始了敏捷和DevOps，可是往往在新潮和流行的“上层建筑”往往发现了“形而下”的落地困难。比如Dev侧自身内部的问题。在上面举例中的开发的那波怒火和领导的无奈中，诚然有开发人员自身能力素质的问题，但这并不能算是问题，因为所有人都是从菜鸟过来了，没有人是天生的王者。“怒气”到底因为什么？为什么会有怒气呢？这个怒气几乎都来源于在团队协作中的“别人”，其实就是在沟通上产生了问题，这可以归结为工作方式方法的问题，说得更直白就是没有遵循一个良好的软件开发实践。在传统的瀑布开发的时候，开发往往会在最后“奋力一搏”完成了项目的部署工作，然后就进入了“休息”的状态，如果有bug就修改bug，如果有其他的（如文档补充，但愿你没有这样的经历）做其他的，处于被动触发这种相对轻松的姿态，所以他们从某种程度上说，是可以接受“别人”的问题的，毕竟忍耐一下就过去了。而在敏捷的迭代开发中，每次迭代都要产出潜在的可交付成果物，部署和发布是“永不止境”的，所以就没有仿佛能看到黎明吹响胜利号角的“奋力一搏”，合代码的人率先遭遇一波伤害，紧接着其他的开发一个个承受着伤害（如果出现Bug），然后大家最后再在一起承受某个或某些谁都不知道的问题带来的打击……所以往往每次的发布都是一次心志的磨练和煎熬，尤其以大工作量周期以月为单位迭代为最——这个背后的元凶其实就是“集成”！有什么好办法虽然相对传统制造业软件显得“年轻”，但是也经历了无数的大风大浪，这种问题并不专属于某些公司，这种烦恼和无奈也并非只有他们才经历过。早在软件开发的“上古”时代，软件界的大神——Martin Fowler就有过这样的经历：“我还可以生动记起第一次看到大型软件工程的情景。我当时在一家大型英国电子公司的QA部门实习。我的经理带我熟悉公司环境，我们进到一间巨大的，充满了压抑感和格子间的的仓库。我被告知这个项目已经 开发了好几年，现在正在集成阶段，并已经集成了好几个月。我的向导还告诉我没人知道集成要多久才能结束”。Martin Fowler不仅在他实习的期间认识到集成是一件很耗时并难以预测的过程，并且很多项目和团队并不把集成当回事。所以为了解决集成所带来的问题以及很多人思想上的不以为意，Martin Fowler 提出了——持续集成。持续集成 是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建（包括自动测试）的 检验，以尽快发现集成错误。从其定义上来看，持续集成可以很好的解决开发们的“怒气”的问题，开发的怒气根本上来说就是由于在协作中缺少“沟通”所造成的，进而将问题推到了“别人”身上，试想如果整个开发的过程中，每个团队的成员彼此做的功能，或者说所提交的代码是“透明”的，那么就可以很大程度上减少这种“别人”的问题了。并且这种“透明”化的周期无需太长时间，最长为一天，最短于几个小时内，从而可以很好的解决了开发团队集成的问题，降低了交付的风险。那么，具体的落地应该有哪些呢？应该如何落地欲善其功必先利其器，在谈落地实践之前，首先看看要实现持续集成需要有哪些工具。基础工具一：版本控制系统。持续集成最基本的前提条件是对其代码库的版本控制，即：对于代码库的每一项变更，都必须被安全地存放到专有的版本控制系统中，目前最主流的版本控制系统当属Git。基础工具二：构建工具。构建工具能够通过处理应用的源代码，自动生成所需的软件（包）。软件工具的构建步骤取决于所选用的技术栈。如，Java的应用，可使用Maven作为构建工具。讲完了持续集成的定义和基础工具后，那么持续集成的过程是怎么样的呢？我们一起看看Martin Fowler是怎么带着我们玩转持续集成的吧。（以下内容来自Marin Fowler的持续集成）举个简单的例子：现在假设要完成一个软件的一部分功能，具体任务是什么并不重要，我们先假设这个 feature 很小，只用几个小时就可以完成。一开始，将已集成的源代码复制一份到 本地计算机。这可以通过从源码管理系统的 mainline 上 check out 一份源代码做到。现在拿到了工作拷贝，接下来需要做一些事情来完成任务。这包括修改产品代码和添加修改自动化测试。在持续集成中，软件应该包含完善的可自动运行的测试——自测试代码。这一般需要用到某一个流行的 XUnit 测试框架。一旦完成了修改，就会在自己的计算机上启动一个自动化 build。这会将工作拷贝中的源代码编译并链接成为一个可执行文件，并在之上运行自动化测试。只有当所有的 build 和测试都完成并没有任何错误时，这个 build 过程才可以认为是成功的。当本地build 成功后，就可以考虑将改动提交到源码仓库。但麻烦的情况在于别人可能已经在我之前修改过 mainline。这时我需要首先把别人的修改更新到自己的工作拷贝中，再重新做 build。如果别人的代码和自己的有冲突，就会在编译或测试的过程中引起错误。自己有责任改正这些问题，并重复这一过程，直到自己的工作拷贝能通过 build 并和 mainline 的代码同步。一旦本地的代码能通过 build，并和 mainline 同步，就可以把我的修改提交到源码仓库。然而，提交完代码不表示就完事大吉了。还要做一遍集成 build，这次在集成计算机上并要基于 mainline 的代码。只有这次 build 成功了，修改才算告一段落。因为总有可能会忘了什么东西在自己的机器上而没有更新到源码仓库。只有提交的改动被成功的集成了，这次工作才能算结束。如果两个开发者的修改存在冲突，这通常会被第二个人提 交代码前本地做 build 时发现。即使这时侥幸过关，接下来的集成 build 也会失败掉。不管怎样，错误都会被很快检测出来。此时首要的任务就是改正错误并让 build 恢复正常。在持续集成环境里，必须尽可能快地修复每一个集成 build。好的团队应该每天都有多个成功的 build。错误的 build 可以出现，但必须尽快得到修复。这样做的结果是你总能得到一个稳定的软件，它可能有一些 bug，但可以正常工作。每个人都基于相同的稳定代码进行开发，而且不会离得太远，否则就会不得不花很长时间集成回去。Bug被发现得越快，花在改正上的 时间就越短。上述基本上就是持续集成的过程和步骤了。那么基于此持续集成又又哪些关键的实践呢？主要有如下几个：只维护一个源代码在软件项目里需要很多文件协调一致才能 build 出产品。跟踪所有这些文件是一项困难的工作，尤其是当有很多人一起工作时。所以，一点也不奇怪，软件开发者们这些年一直在研发这方面的工具。这些工具称为 源代码管理工具，或配置管理，或版本管理系统，或源码仓库，或各种其它名字。大部分开发项目中它们是不可分割的一部分。但可惜的是，并非所有项目都是如 此。虽然很罕见，但我确实参加过一些项目，它们直接把代码存到本地驱动器和共享目录中，乱得一塌糊涂。所以， 作为一个最基本的要求，你必须有一个起码的源代码管理系统。成本不会是问题，因为有很多优秀的开源工具可用。当前较好的开源工具是 Subversion。（更 老的同样开源的 CVS 仍被广泛使用，即使是 CVS 也比什么都不用强得多，但 Subversion 更先进也更强大。）有趣的是，我从与开发者们的交谈中了解到，很多商业源代码管理工具其实不比 Subversion 更好。只有一个商业软件是大家一致同意值得花钱的，这就是 Perforce。一旦你有了源代码管理系统，你要确保所有人都知道到哪里去取代码。不应出现这样的问题：“我应该到哪里去找xxx文件？” 所有东西都应该存在源码仓库里。即便对于用了源码仓库的团队，我还是观察到一个很普遍的错误，就是他们没有把 所有东西都放在源码仓库里。一般人们都会把代码放进去，但还有许多其它文件，包括测试脚本，配置文件，数据库Schema，安装脚本，还有第三方的库，所 有这些build时需要的文件都应该放在源码仓库里。我知道一些项目甚至把编译器也放到源码仓库里（用来对付早年间那些莫名其妙的C++编译器很有效）。 一个基本原则是：你必须能够在一台干净的计算机上重做所有过程，包括checkout和完全build。只有极少量的软件需要被预装在这台干净机器上，通 常是那些又大又稳定，安装起来很复杂的软件，比如操作系统，Java开发环境，或数据库系统。你必须把 build需要的所有文件都放进源代码管理系统，此外还要把人们工作需要的其他东西也放进去。IDE配置文件就很适合放进去，因为大家共享同样的IDE配 置可以让工作更简单。版本控制系统的主要功能之一就是创建 branch 以管理开发流。这是个很有用的功能，甚至可以说是一个基础特性，但它却经常被滥用。你最好还是尽量少用 branch。一般有一个mainline就够 了，这是一条能反映项目当前开发状况的 branch。大部分情况下，大家都应该从mainline出发开始自己的工作。（合理的创建 branch 的 理由主要包括给已发布的产品做维护和临时性的实验。）一般来说，你要把build依赖的所有文件放进代码管理 系统中，但不要放build的结果。有些人习惯把最终产品也都放进代码管理系统中，我认为这是一种坏味道——这意味着可能有一些深层次的问题，很可能是无 法可靠地重新build一个产品。自动化Build通常来 说，由源代码转变成一个可运行的系统是一个复杂的过程，牵扯到编译，移动文件，将 schema 装载到数据库，诸如此类。但是，同软件开发中的其它类似任务一样，这也可以被自动化，也必须被自动化。要人工来键入各种奇怪的命令和点击各种对话框纯粹是 浪费时间，也容易滋生错误。在大部分开发平台上都能找到自动化 build 环境的影子。比如 make，这在 Unix 社区已经用了几十年了，Java 社区也开发出了 Ant，.NET 社区以前用 Nant，现在用 MSBuild。不管你在什么平台上，都要确保只用一条命令就可以运行这些脚本，从而 build 并运行系统。一 个常见的错误是没有把所有事都放进自动化 build。比如：Build 也应该包括从源码仓库中取出数据库 schema 并在执行环境中设置的过程。我要重申一下前面说过的原则：任何人都应该能从一个干净的计算机上 check out 源代码，然后敲入一条命令，就可以得到能在这台机器上运行的系统。Build 脚本有很多不同的选择，依它们所属的平台和社区而定，但也没有什么定势。尽管大部分的 Java 项目都用 Ant，还是有一些项目用 Ruby（Ruby Rake 是一个不错的 build 脚本工具）。我们也曾经用 Ant 自动化早期的 Microsoft COM 项目，事实证明很有价值。一个大型 build 通常会很耗时，如果只做了很小的修改，你不会想花时间去重复所有的步骤。所以一个好的 build 工具应该会分析哪些步骤可以跳过。一个通用的办法是比较源文件和目标文件的修改时间，并只编译那些较新的源文件。处理依赖关系要麻烦一些：如果一个目标文 件修改了，所有依赖它的部分都要重新生成。编译器可能会帮你处理这些事情，也可能不会。根据你的需要，你可能 会想 build 出各种不同的东西。你可以同时 build 系统代码和测试代码，也可以只 build 系统代码。一些组件可以被单独 build。Build 脚本应该允许你在不同的情况中 build 不同的 target。我们许多人都用 IDE，许多 IDE 都内置包含某种 build 管理功能。然而，相应的配置文件往往是这些 IDE 的专有格式，而且往往不够健壮，它们离了 IDE 就无法工作。如果只是 IDE 用户自己一个人开发的话，这还能够接受。但在团队里，一个工作于服务器上的主 build 环境和从其它脚本里运行的能力更重要。我们认为，在 Java 项目里，开发者可以用自己的 IDE 做 build，但主 build 必须用 Ant 来做，以保证它可以在开发服务器上运行。让你的Build自行测试传统意义上的 build 指编译，链接，和一些其它能让程序运行起来的步骤。程序可以运行并不意味着它也工作正常。现代静态语言可以在编译时检测出许多 bug，但还是有更多的漏网之鱼。一种又快又省的查 bug 的方法是在 build 过程中包含自动测试。当然，测试并非完美解决方案，但它确实能抓住很多 bug——多到可以让软件真正可用。极限编程（XP）和测试驱动开发（TDD）的出现很好地普及了自测试代码的概念，现在已经有很多人意识到了这种技巧的 价值。经常读我的著作的读者都知道我是 TDD 和 XP 的坚定追随者。但是我想要强调你不需要这两者中任何一个就能享受自测试代码的好处。两者都要求你先写测试，再写代码以通过测试，在这种工作模式里测试更多 着重于探索设计而不是发现 bug。这绝对是一个好方法，但对于持续集成而言它并不必要，因为这里对自测试代码的要求没有那么高。（尽管我肯定会选择用 TDD 的方式。）自测试代码需要包含一套自动化测试用例，这些测试用例可以检查大部分代码并找出 bug。测试要能够从一条简单的命令启动。测试结果必须能指出哪些测试失败了。对于包含测试的 build，测试失败必须导致 build 也失败。在过去的几年里，TDD 的崛起普及了开源的 XUnit 系列工具，这些工具用作以上用途非常理想。对于我们在 ThoughWorks 工作的人来说，XUnit 工具已经证明了它们的价值。我总是建议人们使用它们。这些最早由 Kent Beck 发明的工具使得设置一个完全自测试环境的工作变得非常简单。毋庸置疑，对于自动测试的工作而言，XUnit 工具只是一个起点。你还必须自己寻找其他更适合端对端测试的工具。现在有很多此类工具，包括FIT，Selenium，Sahi，Watir，FITnesse， 和许多其它我无法列在这里的工具。当然你不能指望测试发现所有问题。就像人们经常说的：测试通过不能证明没有 bug。然而，完美并非是你要通过自测试 build 达到的唯一目标。经常运行不完美的测试要远远好过梦想着完美的测试，但实际什么也不做。每人每天要向mainline提交代码集成的主要工作其实是沟 通。集成可以让开发者告诉其他人他们都改了什么东西。频繁的沟通可以让人们更快地了解变化。让开发者提交到 mainline 的一个先决条件是他们必须能够正确地 build 他们的代码。这当然也包括通过 build 包含的测试。在每个提交迭代里，开发者首先更新他们的工作拷贝以与 mainline 一致，解决任何可能的冲突，然后在自己的机器上做 build。在 build 通过后，他们就可以随便向 mainline 提交了。通过频繁重复上述过程，开发者可以发现 两个人之间的代码冲突。解决问题的关键是尽早发现问题。如果开发者每过几个小时就会提交一次，那冲突也会在出现的几个小时之内被发现，从这一点来说，因为 还没有做太多事，解决起来也容易。如果让冲突待上几个星期，它就会变得非常难解决。因为你在更新工作拷贝时也 会做 build，这意味着你除了解决源代码冲突外也会检查编译冲突。因为 build 是自测试的，你也可以查出代码运行时的冲突。后者如果在一段较长的时间还没被查出的话会变得尤其麻烦。因为两次提交之间只有几个小时的修改，产生这些问题 只可能在很有限的几个地方。此外，因为没改太多东西，你还可以用 diff-debugging 的技巧来找 bug。总的来说，我 的原则是每个开发者每天都必须提交代码。实践中，如果开发者提交的更为频繁效果也会更好。你提交的越多，你需要查找冲突错误的地方就越少，改起来也越快。频繁提交客观上会鼓励开发者将工作分解成以小时计的小块。这可以帮助跟踪进度和让大家感受到进展。经常会有人一开始根 本无法找到可以在几小时内完成的像样的工作，但我们发现辅导和练习可以帮助他们学习其中的技巧。每次提交都 应在集成计算机上重新构建 mainline使用每日提交的策略后，团队就能得到很多经过测试的 build。这应该意味着 mainline 应该总是处于一种健康的状态。但在实践中，事情并非总是如此。一个原因跟纪律有关，人们没有严格遵守在提交之前在本地更新并做 build 的要求。另一个原因是开发者的计算机之间环境配置的不同。结论是你必须保证日常的 build 发生在专用的集成计算机上，只有集成 build 成功了，提交的过程才算结束。本着“谁提交，谁负责”的原则，开发者必须监视 mainline 上的 build 以便失败时及时修复。一个推论是如果你在下班前提交了代码，那你在 mainline build 成功之前就不能回家。我知道主要有两种方法可以使用：手动 build，或持续集成服务器软件。手动 build 描述起来比较简单。基本上它跟提交代码之前在本地所做的那次 build 差不多。开发者登录到集成计算机，check out 出 mainline 上最新的源码（已包含最新的提交），并启动一个集成 build。他要留意 build 的进程，只有 build 成功了他的提交才算成功。（请查看 Jim Shore 的描述。）持续集成服务器软件就像一个监视着源码仓库的监视器。每 次源码仓库中有新的提交，服务器就会自动 check out 出源代码并启动一次 build，并且把 build 的结果通知提交者。这种情况下，提交者的工作直到收到通知（通常是 email）才算结束。在 ThoughtWorks，我们都是持续集成服务器软件的坚定支持者，实际上我们引领了 CruiseControl 和 CruiseControl.NET 最 早期的开发，两者都是被广泛使用的开源软件。此后，我们还做了商业版的 Cruise 持续集成服务器。我们几乎在每一个项目里都会用持续集成服务器，并且对结果非常满意。不是每个人都会用持续集成服务器。Jim Shore 就清楚地表达了为什么他更偏好手动的办法。我同意他的看法中的持续集成并不仅仅是安装几个软件而已，所有的实践 都必须为了能让持续集成更有效率。但同样的，许多持续集成执行得很好的团队也会发现持续集成服务器是个很有用的工具。许多组织根据安排好的日程表做例行 build，如每天晚上。这其实跟持续集成是两码事，而且做得远远不够。持续集成的最终目标就是要尽可能快地发现问题。Nightly build 意味着 bug 被发现之前可能会待上整整一天。一旦 bug 能在系统里呆这么久，找到并修复它们也会花较长的时间。做好持续集成的一个关键因素是一旦 mainline 上的 build 失败了，它必须被马上修复。而在持续集成环境中工作最大的好处是，你总能在一个稳定的基础上做开发。mainline 上 build 失败并不总是坏事，但如果它经常出错，就意味着人们没有认真地在提交代码前先在本地更新代码和做 build。当 mainline 上 build 真的失败时，第一时间修复就成了头等大事。为了防止在 mainline 上的问题，你也可以考虑用 pending head 的方法。当团队引入持续集成时，这通常是最难搞定的事情之一。在初期，团队会非常难以接 受频繁在 mainline 上做 build 的习惯，特别当他们工作在一个已存在的代码基础上时更是如此。但最后耐心和坚定不移的实践常常会起作用，所以不要气馁。保持快速 build持续集成的重点就是快速反馈。没有什么比缓慢的 build 更能危害持续集成活动。这里我必须承认一个奇思怪想的老家伙关于 build 快慢标准的的玩笑（译者注：原文如此，不知作者所指）。我的大部分同事认为超过1小时的 build 是不能忍受的。团队们都梦想着把 build 搞得飞快，但有时我们也确实会发现很难让它达到理想的速度。对大多数项目来说，XP 的10分钟 build 的指导方针非常合理。我们现在做的大多数项目都能达到这个要求。这值得花些力气去做，因为你在这里省下的每一分钟都能体现在每个开发者每次提交的时候。持 续集成要求频繁提交，所以这积累下来能节省很多时间。如果你一开始就要花1小时的时间做 build，想加快这个过程会相当有挑战。即使在一个从头开始的新项目里，想让 build 始终保持快速也是很有挑战的。至少在企业应用里，我们发现常见的瓶颈出现在测试时，尤其当测试涉及到外部服务如数据库。也许最关键的一步是开始使用分阶段build（staged build）。分阶段 build（也被称作 build 生产线）的基本想法是多个 build 按一定顺序执行。向 mainline 提交代码会引发第一个 build，我称之为提交 build（commit build）。提交 build 是当有人向 mainline 提交时引发的 build。提交 build 要足够快，因此它会跳过一些步骤，检测 bug 的能力也较弱。提交 build 是为了平衡质量检测和速度，因此一个好的提交 build 至少也要足够稳定以供他人基于此工作。一旦提交 build 成功，其他人就可以放心地基于这些代码工作了。但别忘了你还有更多更慢的测试要做，可以另找一台计算机来运行运行这些测试。一个简单的例子是两阶段 build。第一阶段会编译和运行一些本地测试，与数据库相关的单元测试会被完全隔离掉（stub out）。这些测试可以运行得非常快，符合我们的10分钟指导方针。但是所有跟大规模交互，尤其是真正的数据库交互的 bug 都无法被发现。第二阶段的 build 运行一组不同的测试，这些测试会调用真正的数据库并涉及更多的端到端的行为。这些测试会跑上好几小时。这种情况下，人们用第一阶段作为提交 build，并把这作为主要的持续集成工作。第二阶段 build 是次级build，只有 在需要的时候才运行，从最后一次成功的提交 build 中取出可执行文件作进一步测试。如果次级 build 失败了，大家不会立刻停下手中所有工作去修复，但团队也要在保证提交 build 正常运行的同时尽快修正 bug。实际上次级 build 并非一定要正常运行，只要 bug 都能够被检查出来并且能尽快得到解决就好。在两阶段 build 的例子里，次级 build 经常只是纯粹的测试，因为通常只是测试拖慢了速度。如果次级 build 检查到了 bug，这是一个信号，意味着提交 build 需要添加一个新测试了。你应该尽可能把次级 build 失败过的测试用例都添加到提交 build 中，使得提交 build 有能力验证这些 bug。每当有 bug 绕过提交测试，提交测试总能通过这种方法被加强。有时候确实无法找到测试速度和 bug 验证兼顾的方法，你不得不决定把这个测试放回到次级 build 里。但大部分情况下都应该可以找到合适加入提交 build 的测试。上面这个例子是关于两阶段 build，但基本原则可以被推广到任意数量的后阶段 build。提交 build 之后的其它 build 都可以同时进行，所以如果你的次级测试要两小时才能完成，你可以通过用两台机器各运行一半测试来快一点拿到结果。通过这个并行次级 build 技巧，你可以向日常 build 流程中引入包括性能测试在内的各种自动化测试。（当我过去几年内参加 Thoughtworks 的各种项目时，我碰到了很多有趣的技巧，我希望能够说服一些开发者把这些经验写出来。）在模拟生产环境中进 行测试测试的关键在于在受控条件下找出系统内可能在实际生产中出现的任何问题。这里一个明显的因素是生产系 统的运行环境。如果你不在生产环境做测试，所有环境差异都是风险，可能最终造成测试环境中运行正常的软件在生产环境中无法正常运行。自然你会想到建立一个与生产环境尽可能完全相同的测试环境。用相同的数据库软件，还要同一个版本；用相同版本的操作系统；把所有生产环 境用到的库文件都放进测试环境中，即使你的系统没有真正用到它们；使用相同的IP地址和端口；以及相同的硬件；好 吧，现实中还是有很多限制的。如果你在写一个桌面应用软件，想要模拟所有型号的装有不同第三方软件的台式机来测试显然是不现实的。类似的，有些生产环境可 能因为过于昂贵而无法复制（尽管我常碰到出于经济考虑拒绝复制不算太贵的环境，结果得不偿失的例子）。即使有这些限制，你的目标仍然是尽可能地复制生产环 境，并且要理解并接受因测试环境和生产环境不同带来的风险。如果你的安装步骤足够简单，无需太多交互，你也许 能在一个模拟生产环境里运行提交 build。但事实上系统经常反应缓慢或不够稳定，这可以用 test double 来解决。结果常常是提交测试为了速度原因在一个假环境内运行，而次级测试运行在模拟真实的生产环境中。我注意到越来越多人用虚拟化来搭建测试环境。虚拟机的状态可以被保存，因此安装并测试最新版本的build相对简单。此外，这可以让你 在一台机器上运行多个测试，或在一台机器上模拟网络里的多台主机。随着虚拟化性能的提升，这种选择看起来越来越可行。让每个人都能轻易获得最新的可执行文件软件开发中最困难的部分是确定你的软件行为符合预期。我们 发现事先清楚并正确描述需求非常困难。对人们而言，在一个有缺陷的东西上指出需要修改的地方要容易得多。敏捷开发过程认可这种行为，并从中受益。为了以这种方式工作，项目中的每个人都应该能拿到最新的可执行文件并运行。目的可以为了 demo，也可以为了探索性测试，或者只是为了看看这周有什么进展。这做起来其实相当简单：只要找到一个大家 都知道的地方来放置可执行文件即可。可以同时保存多份可执行文件以备使用。每次放进去的可执行文件应该要通过提交测试，提交测试越健壮，可执行文件就会越 稳定。如果你采用的过程是一个足够好的迭代过程，把每次迭代中最后一个 build 放进去通常是明智的决定。Demo 是一个特例，被 demo 的软件特性都应该是演示者熟悉的特性。为了 demo 的效果值得牺牲掉最新的 build，转而找一个早一点但演示者更熟悉的版本。每个人都能看到进度持续集成中最重要的是沟通。你需要保证每个人都能轻易看到系统的状态和最新的修改。沟通的最重要的途 径之一是 mainline build。如果你用 Cruise，一个内建的网站会告诉你是否正有 build 在进行，和最近一次 mainline build 的状态。许多团队喜欢把一个持续工作的状态显示设备连接到 build 系统来让这个过程更加引人注目，最受欢迎的显示设备是灯光，绿灯闪亮表示 build 成功，红灯表示失败。一种常见的选择是红色和绿色的熔岩灯，这不仅仅指示 build 的状态，还能指示它停留在这个状态的时间长短，红灯里出现气泡表示 build 出问题已经太长时间了。每一个团队都会选择他们自己的 build 传感器。如果你的选择带点幽默性和娱乐性效果会更好（最近我看到有人在实验跳舞兔）。即使你在使用手动持续集 成，可见程度依然很重要。Build 计算机的显示器可以用来显示 mainline build 的状态。你很可能需要一个 build 令牌放在正在做 build 那人的桌子上（橡皮鸡这种看上去傻傻的东西最好，原因同上）。有时人们会想在 build 成功时弄出一点噪音来，比如摇铃的声音。持续集成服务器软件的网页可以承载更多信息。Cruise 不仅显示谁在做 build，还能指出他们都改了什么。Cruise 还提供了一个历史修改记录，以便团队成员能够对最近项目里的情况有所了解。我知道 team leader喜欢用这个功能了解大家手头的工作和追踪系统的更改。使用网站的另一大优点是便于那些 远程工作的人了解项目的状态。一般来说，我倾向于让项目中发挥作用的成员都坐在一起工作，但通常也会有一些外围人员想要了解项目的动态。如果组织想要把多 个项目的 build情况聚合起来以提供自动更新的简单状态时，这也会很有用。好的信息展示方式不仅仅依赖于 电脑显示器。我最喜欢的方式出现于一个中途转入持续集成的项目。很长时间它都无法拿出一个稳定的 build。我们在墙上贴了一整年的日历，每一天都是一个小方块。每一天如果 QA 团队收到了一个能通过提交测试的稳定 build，他们都会贴一张绿色的贴纸，否则就是红色的贴纸。日积月累，从日历上能看出 build 过程在稳定地进步。直到绿色的小方块已经占据了大部分的空间时，日历被撤掉了，因为它的使命已经完成了。自动化部署自动化集成需要多个环境，一个运行提交测试，一个或多个运行次级测试。每天在这些环境之间频繁拷贝 可执行文件可不轻松，自动化是一个更好的方案。为实现自动化，你必须有几个帮你将应用轻松部署到各个环境中的脚本。有了脚本之后，自然而然的结果是你也要 用类似的方式部署到生产环境中。你可能不需要每天都部署到生产环境（尽管我见过这么做的项目），但自动化能够加快速度并减少错误。它的代价也很低，因为它 基本上和你部署到测试环境是一回事。如果你部署到生产环境，你需要多考虑一件事情：自动化回滚。坏事情随时可 能发生，如果情况不妙，最好的办法是尽快回到上一个已知的正常状态。能够自动回滚也会减轻部署的压力，从而鼓励人们更频繁地部署，使得新功能更快发布给用 户。（Ruby on Rails 社区开发了一个名为 Capistrano 的工具，是这类工具很好的代表。）我还在服 务器集群环境中见过滚动部署的方法，新软件每次被部署到一个节点上，在几小时时间内逐步替换掉原有的软件。在 web 应用开发中，我碰到的一个有趣的想法是把一个试验性的 build 部署到用户的一个子集。团队可以观察这个试验 build 被使用的情况，以决定是否将它部署到全体用户。你可以在做出最终决定之前试验新的功能和新的 UI。自动化部署加上良好的持续集成的纪律是这项工作的基础。（以上内容来自Marin Fowler的持续集成）写在最后“我的脑海中还是会浮现出第一段描述的早期软件项目。他们已经到了一个漫长项 目的末期（至少他们期望如此），但还是不知道距离真正的结束有多远。”这是来自Martin Fowler曾经历过的感受。而文中的第二段的那些开发们的“怒气”是笔者从十年前做开发的时候，所经历过的几个团队所发生过的。在集成的过程中，总会有种种无法预测的事情发生，不论是人还是事，你根本无法预测其进展从而很容易进入到迷茫地带，每一个处在迷茫地带的人都很难去做到轻松应对，久而久之开发人员会产生疲于奔命之感，导致团队无法凝聚成“拳头”打出强有力的一拳。基于这种情况，笔者认为这正是我们引入持续集成的原因所在。笔者认为Martin Fowler关于持续集成的落地实践部分已经比较详尽完全可以用来大家公共参考学习，所以没有在关公面前耍大刀，故引用于此文章。但是在我们持续集成实际的过程中一定会遇到很多问题，比如提升build效率的分段build策略或者其他实际的需求等，这都需要我们在日常工作中，通过迭代不断的来研究和完善其实践的方法，并在回顾的过程中加以讨论、分析总结，最终提升团队的研发效率。也可以使用一些大厂如华为云DevCloud作为持续集成的工具，其提供专业的一站式解决方案，方便了中小企业的DevOps落地。文章博客地址：https://bbs.huaweicloud.com/blogs/196464