怎么强调都不为过的基础要求。
1. 背景
日常工作中,尤其是在接受一个微服务架构的产品之后,一个非常让笔者不适应的状况就是其单次打包和部署的时间加起来基本在四十分钟左右,而这还是一个以java应用为主体的技术体系。笔者在从事了这么多年的java研发经验中,还是头一次见到耗时如此长的架构体系。
而在实际对该架构进行优化过程中,因为打包流程是其他人负责的,所以我一开始的思路是让当事人去优化。但是很明显,既然此文能够出现,那必然是这条路并不是很顺利。
笔者在过往的诸多博文中一直在强调一个概念:"社会上绝大部分的工作岗位所解决的并不是什么前无古人后无来者的开天辟地伟业,工作本身完成的好坏更多取决于当事人的职业素养,态度和认知(其实后面这两者都包括在职业素养里面,但这里我还是单独拉出来重复一遍),而不是所谓的既有能力。很多时候态度够了,事情就不会做得太差,能力也很快就会成为周围人中的佼佼者"。
本文尝试解决一下认知问题。本文属于科普性质,因为这种在软件工程践行者已经属于吃饭喝水一样的常识性东西。只是在实际的工作环境中,发现很多人对其根本毫无概念。
这里尝试将对文本标题的解释归纳汇总一下,避免在这种基础概念上的反复拉锯,浪费时间。
2. 解释
- "快速反馈"。CICD符合人类这一解决问题和学习知识的基础方法 。经典的《重构》一书里,作者在书中不断强调的"小步快跑,频繁测试"也就是为了获取到快速反馈。
- 快速的反馈才是有效的反馈。快速反馈的要求会缩短问题引入时间和问题发现时间之间的间隔,进而减少了两次反馈之间的所引入变量数量,这样发现问题时就可以快速定位原因,快速修复。
- 打包和部署本身就是一种ROI较高的测试。打包测试,部署测试可以在人工测试正式介入之前发现很多因为疏忽所引入低级错误。相较于在人工测试介入才发现这类问题,CICD修复问题的成本可以忽略,而收益会随着软件的迭代不断增加。
- CICD属于极限编程的思想。极限编程中"极限"的含义就是——好的最佳实践就是要做到极限。CICD自然也属于此类。
- CICD增加了应对变更时的灵活性。作为自动化测试基石的CICD,能够让相关方快速看到变更的带来的影响,进而增加各方对于变更的信心(这个信心包括变更后的稳定性,以及变更本身所带来的业务价值等)。
- "一天就打一次包, 慢点就慢点呗"这是错误的。因为"一天只打包一次"是你打包慢导致的结果,而不是因为只在临晨打包一次,所以导致你打包慢。这句话错在搞反了最基本的因果。而且一天只打包一次也就是限定了我今天改的东西明天才能测试,这很明显是人为故意拉长了问题的反馈间隔。
本小节末尾附上一副打包慢/部署慢导致的连锁反应图:
3. 获得动态语言的编程体验(2023/08/08 新增)
一直以来,说到这个"增加开发效率",其它人都觉得"这能够有多少工作量",我虽然知道这种说法不对,但一直没有找到合适的理由来说服他们。
不过最近我突然想到这么一条:"对于熟悉JAVA/C#和Javascript/Python/Groovy"这两类语言的研发人员,我们不考虑长期维护的情况,大家更喜欢使用哪类语言做开发?
就我个人而言,我更喜欢后者。甚至最近我基于 SpringBoot + Groovy构建一套"无需重启即可实现新增业务功能开发"的内部应用,也是切实不断感受到"有什么想法直接就可以线上马上验证",小步快跑的快感。
对应地,使用Java语言,如果整个验证流程全部由人工完成,那么相关人员势必会因为麻烦而选择人为拉长验证间隔周期,这样的结果就是寄希望于一次把全部东西做完,一次把东西做对;而这,在软件研发里本身就是个神话。
在编程体验上,CICD让JAVA这类静态语言获得趋同于Javascript等动态语言的这类特性。
"开发一时爽,重构火葬场",这句经久不衰的调侃点出了动态语言致命问题的同时,也算是承认了其在开发过程中的高效。
现在,Java静态语言开发 + CICD的全面接入,使得"鱼和熊掌兼得"成为一种可能 —— 同时兼顾开发效率和重构/维护成本。
4. ChatGPT给出的回答
2023年了,也要追下潮流嘛。所以我们顺带问了下Chatgpt对于CICD重要性的看法:
在软件研发流程中,如果打包部署慢,可能会导致以下后果:
①延误上线时间;
②增加开发人员的工作量;
③增加测试人员的工作量;
④增加运维人员的工作量;
⑤影响用户体验。快速反馈, 软件开发中的利器 -- 这个也是Chatgpt帮忙搜索到的。
5. 后记
其实这样科普在知情者眼中根本就是废话一样的东西,就像你不会告诉小学三年纪的小朋友1+1是等于2一样。
所以最后我表达下个人观点,当然不是原创,而是从左耳朵耗子那借鉴来的:可以的话, 与其花时间培养,不如花时间寻找。
毕竟,虽然软件注定腐朽,但是CICD如果都做不好的话,软件的质量只会加速下降,如同踩死油门下坡一样。
网友评论