【DevOps全栈实践训练营】带你体验华为端到端DevOps软件项目全生命周期管理流程》》基于华为云DevCloud的凤凰商城项目开发实验反馈《《 开始体验前请先确保完成了活动报名 》》》前往活动报名实验任务：根据课堂指导视频，使用华为云DevCloud完成课后实验（共6关），完成任一关或全部并提交实验截图回复本贴（需包含右上角华为云账号）。第一关：动手实验——项目管理第二关：动手实验——测试管理第三关：动手实验——代码托管第四关：动手实验——代码检查第五关：动手实验——持续交付、持续部署第六关：动手实验——流水线完成任一实验或全部实验并提交截图反馈，即有机会领取华为Watch、华为移动硬盘、荣耀体脂称、华为云周边礼品。多次实验完成截图请整合进行一次回帖，多次回复按照单次回帖计算。单一实验与完成全部实验并提交反馈截图的用户，奖励优先后者，不支持重复领取。注意事项：1、请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）；2、任务排名一致，则按截图反馈时间先后为标准，进行排名；3、本次活动，活动获奖名单预计于活动结束后10个工作日内完成公示，15个工作日内完成奖品发放，发放时间根据实际情况动态调整，如有延期敬请见谅；4、本次活动参与用户需真实有效，如有虚假、黑产等行为，一律通报、剔除活动参与资格。

# 编译构建模板的版本号问题 我的代码使用的 JDK 是 17 的版本，maven 版本是 3.8.1 创建流水线的时候，编译构建的 Maven 模板中没有我需要的版本号。 请问这种情况，在不修改我项目代码中的 JDK 和 Maven 版本的条件下，还能使用流水线的编译构建吗？

      经常看到有人问DevCloud里面如何设置一次参数把构建参数值传递到部署任务内，一般这种参数使用的场景是版本号（releaseversion），镜像标签（dockertag）等，下面给大家分享一下操作方法。      跨任务传递参数需要使用DevCloud流水线服务，流水线可以将DevCloud内的其他服务任务串起来，通过手动或自动的方式，按照流水线内配置的编排顺序来执行任务。举例说明，通过流水线统一配置releaseversion参数传递到构建和部署任务。1.创建构建任务，构建任务内添加参数releaseversion，参数值随便填一个，这里填上在用的时候也会被覆盖，后面的运行时设置一定要打开！2.在构建任务里面调用这个参数，这一步一定要设置，否则在流水线内无法添加，任务内使用$符号调用参数，输入$符号之后会自动带出已配置的参数，选择即可调用。图中我在上传软件包到发布仓库步骤调用了刚刚配置的参数。3.创建空模板流水线，在流水线阶段添加刚刚的构建任务。这时能看到，刚刚我们创建的构建任务内的releaseversion参数已经显示出来，点击保存。4.保存后，回到流水线配置页面，我们配置流水线参数，创建流水线参数releaseversion，类型可以根据自己的需求选择自增长或字符串等，设置默认值，打开运行时设置。5.回到流水线工作流配置页面，打开刚刚添加的构建任务，将流水线内配置好的releaseversion参数通过$符号引用到构建任务的releaseversion参数内，点击保存，保存流水线。6.这时我们执行流水线，高级设置内【运行时参数配置】选项里可以看到我们刚刚配置的releaseversion参数，这时我们根据实际情况输入参数值，那么在构建任务内使用的就是此时输入的参数值。其他任务同样的操作方式添加参数即可。这样操作就实现了流水线统一配置参数，其他各任务调用，提高CICD效率和准确性。

背景在一次DevOps线上活动的提问环节中，有这样一个问题：“我们公司刚刚完成了DevOps转型，搭建了一条流水线，流水线确实让我们部署上线的效率提升了，但是也更快的让客户当上小白鼠，因为我们让问题更快的暴露出来了……”可以想象，一个开发人员开心的点了一下流水线的启动按钮，然后就开心的下班了，然后用户看着屏幕的404，然后就没有了然后（坏笑）……其实这真不是开玩笑，如果将项目中的流水线发布权限下放给了开发，那么404真的就是很现实和普遍的问题，因为很多开发认为自己的工作就是开发。像这样的坑你是否也掉进去过，我们一起基于此，来看看什么样的流水线是不坑人的吧。问题分析这些年来，DevOps已经逐渐的深入到软件企业中，尤其是一些互联网的项目中，需要更快的适应市场的变化迎合用户的需求，传统低效的方式来部署生产环境已无法存活， DevOps的流水线（部署流水线）也应运而生。然而在企业追求高效的同时，往往又引入了新的问题——高效的将bug展现给了用户。项目开发的前期，代码都是比较简单的，开发团队的人员也比较少。但慢慢随着时间的推移，代码越来越复杂，团队成员越来越越多，经手变更的也越来越频繁。一旦出现了问题，作为一个开发人员往往首先会想到的是——快速修复上线。DevOps在速度这点上确实帮了大忙，经历过传统部署发布的同学肯定深有体会。但是这样往往却又伴随了新的问题——“打地鼠现象”。何为打地鼠现象? 简单的说，就是一个问题你修复了，可能又会蹦出来几个新的问题。长期下去，不仅开发团队压力大，客户更是成了“小白鼠”。其实，这并不能把问题归结到部署流水线身上（无辜躺枪），借助流水线的快速发布，只是将问题更早的暴露出来，其归根结底上，问题还是出在质量上。那么，我们就不得不谈到——质量内建。戴明（William Edwards Deming）曾提出“问题发现得越早，修复的成本越低”，有数据指出85%的缺陷都是在代码编码阶段引入的，然而大部分的缺陷并不是在编码的时候发现的，而是在之后的测试阶段发现的，甚至是已经上线后。而且随着越往后发现缺陷，修复的成本也越高。来源《Applied Software Measurement:Global Analysis of Productivity and Quality》按照STICKYMINDS网站上上的一篇名为The Shift-Left Approach to Software Testing的文章中所给出的（如上图），假如在编码阶段发现的缺陷只需要1分钟就能解决，那么单元测试阶段需要4分钟，功能测试阶段需要10分钟，系统测试阶段需要40分钟，而到了上线之后再发现可能就需要640分钟来修复，这可以说是很难让人接受的，所以质量内建是至关重要的。在质量问题上，当然离不了我们老生常谈的开发阶段的编码规范、重构、检视等活动，这里不做叙述。随着DevOps的引入，我们需要将质量内建，加入到DevOps的各个环节中，而部署流水线就是贯穿这些环节的重要工具。某种程度上说，部署流水线的质量基本上决定了软件质量——是带伤上阵还是安稳的睡大觉，部署流水线是关键。那么如何算是一条不坑的部署流水线呢？解决方案测试左移（Shift-Left testing）如上面所提到了，在开发完成后，越到生命周期的后面修复的成本越高。那么基于这样的情况，测试应该尽早的开始。在传统的开发周期中，问题都在什么时候发现的呢？如下图所示：来源《Applied Software Measurement:Global Analysis of Productivity and Quality》可以看到传统模式下，问题很少会在开发阶段发现，而现在提出的测试左移，就是在要在开发阶段尽可能的发现更多的问题，而避免问题被发现在之后的阶段。这也就是我们搭建一条不坑的流水线最基本的理念之一。一般来说，在流水线的构建阶段我们会加入静态代码检查，比如使用Findbugs、Sonar等。可按需自行设置是否随代码提交而触发检查（推荐），或伴随持续集成的工程实践开展，可一天一次或多次，这就保障了不会掉进最基本静态代码层面的坑。此外在流水线的设计上一定要有API、UI等自动化测试。一般来说，可按部署到不同的环境，对应创建不同的流水线阶段，如集成环境有对应的流水线的集成阶段，测试环境有其测试阶段。当部署时，就可以在对应的阶段中加入所需要的测试活动。如当开发人员修复某一个bug后，想要保证其他功能的成长，可以通过在流水线的自测阶段通过加入API的测试等。总结来说，就是在流水线的构建阶段加入静态代码的检查，在部署阶段加入自动化的测试活动，以保证代码的质量和功能的可用。质量要求在质量建设中，不能仅停留在质量管控的基本要求——有，还要注重质量的高低。因为某种意义上来说，较松的管控等于没有，这也是最坑的地方——有等于没有，试想如果流水线中只有某个API测试的情况，那么验证的基本就是这个服务有没有成功启动而已。那么，这就需要加入一个质量阀值的要求。质量阀值的高低是一个衡量质量高低的重要标准。这个阀值可以是接口覆盖率达到多少，也可以是静态代码检查出来问题的数量等。一个严格的质量门禁可以说流水线完成后发布上线的定心丸，这也就可以用来解决了上文提到的“打地鼠”现象。一般来说，接口测试的覆盖率建议达到百分之百，而考虑单元测试和接口测试某些程度上的重复以及UI测试的ROI等因素可按需进行配置，因情况不同这里不做叙述。对于代码检查来说，也可设置某一个数值作为阀值，这个数值可以按照某种规则设定。如一般问题记1分，严重问题记5分，安全问题记8分等，当检查后所累积的数值超过10则不能发布或进入下个一个阶段，当然数值越低越好，具体设置（代码检查的维度不再此叙述）也需按实际情况而定。此外，还可以考虑如开源第三方jar包的扫描、安全漏洞扫描等活动。如果考虑划分的更有层级和模块化，相对于接口测试或静态代码检查的质量建设，扫描的可以单独作为一个阶段按需设置。总结来说，质量建设按照项目的实际情况来设置，而且对于团队来说，质量永远不仅仅是某一个人或团队的事情，而是所有人的事情。相对于质量的坑来说，意识上更是我们应该避免掉进的坑。如了解更多请访问华为DevCloud流水线的内容，详见附录。这里提到了意识，意识是关乎人的主观性层面的了，那么应用在流水线上，其实也是需要考虑的。诚然有些时候我们依赖于机器和自动化，如上面说提到的接口测试、安全扫描等。但是也不能完全依赖于自动化，比如我们也需要人工的代码检视活动。这在搭建流水线的时候也可以考虑到把人工环节加入到其中，比如在发布到生产环境的阶段增加一个发布看板，其中包含了是否有人工代码的检视以及检视出来的代码的质量的阀值或要求等。综上，一条流水线除了必须的、按需的自动化+人工以外，还需要在实践的过程中不断的总结结合自身特点加以定制，然后才能放心大胆的点击“启动”而不被坑。最后引用姚冬老师文章中的一句话“流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。”这也是笔者非常认同的，也相信搭建实现这一目标，提供这能力的流水线才能更好的实现持续交付，配合好我们的DevOps转型。参考附录测试左移以终为始，再谈持续交付流水线DevCloud的HE2E DevOps的流水线构建博客