让你的CI跑起来-《持续集成》读书总结

简介: 持续集成已经被公认为极具价值的一项工程实践。在初始化一个项目时一个重要的任务就是搭建持续集成服务器,编写构建脚本。在我工作的所有项目中都引入了持续集成机制。它已经像氧气一样成为软件开发过程中的一项工程活动。

持续集成已经被公认为极具价值的一项工程实践。在初始化一个项目时一个重要的任务就是搭建持续集成服务器,编写构建脚本。在我工作的所有项目中都引入了持续集成机制。它已经像氧气一样成为软件开发过程中的一项工程活动。

《持续集成》站在理论的角度阐述了持续集成能够解决什么样的问题,如何解决,需要遵循那些原则等。这本书的副标题是-软件质量改进和风险降低之道(Improving Software Quality and Reducing Risk)。副标题直指持续集成的两个好处:提高软件质量及降低项目风险。

当前面临的问题

当前软件开发一直存在两大难题:一是确定软件的需求,即确定目标。究竟软件要做成什么样子,在客户的头脑里可能是个三角形,在业务分析员的头脑中可能是个正方形,在开发者的头脑中可能是个圆形,而最终出来的产品或多或少都会给客户带来“惊喜”。

二是确定目前离目标还有好远,即确定剩余的工作量。这个问题就是项目缺少可见性的问题。当一个程序员告诉他的经理说这个功能只剩下20%的工作量时,具体指什么那?这个20%的比例是怎么得到的?是还要再花20%的时间?……

持续集成虽然解决不了第一个问题,但是关于第二个问题,持续集成向我们介绍了一种增加项目可见性,提高开发效率,降低项目失败风险的有效实践经验。

其实持续集成蕴含有哲学思想:分而治之。即我们通常说的 “滴水穿石,硅步千里”。

传统瀑布方法一般将系统集成放置到开发完成后,这样会导致一系列的问题。

  • 没有一致的、可部署的软件。只有等到集成完成之后,我们才能够拿到一个可以使用的软件。

  • 很晚才发现缺陷。接口不一致、接口不满足实际需求、开发人员对功能理解有偏差….这些问题在集成测试时统统暴露出来。由于软件根基已经建立,这时候修改容易伤筋动骨。

  • 低品质的软件。正如上条所说,缺陷发现的越晚,修改的代价越大。在交付的压力下,各种猴子补丁散落在系统的各个地方,软件的品质自然也很难提高。

  • 缺少项目可见性。直到系统集成之前,你都拿不出可用的软件。而且系统集成之时,往往是项目中最棘手、最紧张的时刻,你很难预估集成什么时候能够彻底完成。这样的项目自然谈不上什么可见性了。

CI的价值

引入了CI(Continuos Integration,即持续集成)以后,每个开发人员在提交代码的时候都会自动进行构建,包括代码审查、编译、单元测试、打包、功能测试等。这样保证了开发人员的每次提交都是安全的。打包生成的文件随时可以被测试人员拿去测试。如果需要给客户演示功能,也只需从CI服务器上直接获取指定的打包完成的文件即可。

CI的好处多多。

  • 减少风险

缺陷的检测和修复变得更快,让寻找和修改bug的工作变简单(只修改系统一小部分,无需看太多代码。由于提交后就可以得到反馈,记忆很新鲜,可以进行差异调试。)同时过早的引入集成,使我们能更好的审视各个模块的接口是否满足要求,减少项目中的假定。

  • 减少重复过程

由于CI将大量的工作给自动化了,那么可以让人们有时间做更多的需要动脑筋的、更高价值的工作。而且通过对重要过程自动化,克服了项目中某些成员对实现改进的抵制,有利于持续集成的推进。这样就形成了一个良性循环。

  • 在任何时间、任何地点生成可部署的软件

对于客户来说,可以部署的软件是最实际的资产。而CI则可以轻松做到这一点。

  • 增强项目的可见性

通过对CI服务器的监控,可以随时了解项目的趋势。CI上的红色或绿色表示了当前项目的健康程度。每一个功能的交付都经历了单元测试或集成测试的考验。

  • 对开发团队的软件产品建立起更强大的产品信心

CI可以防止破窗综合症,让开发团队一点点积累起对产品的信息。

CI的特征

img_d4d517e0f6b39fcd10a6d27af3caeb34.png

从上述图中可以看出CI有四个特征:

  • 与版本控制系统的连接

当开发者提交代码时,就会触发CI系统的运行。

  • 构建脚本

构建脚本继承了审查、编译、测试、打包、功能测试等环节,保证了产品的质量与可用性。

  • 某种类型的反馈机制

集成的结果要能很容易的获取到。可以通过一个web页面来呈现,也可以给团队人员发Email。我们公司有些团队做了一些有意思的插件,比如将build的结果映射到一个灯上,或者当构建失败时播放一段音乐等,随时提醒团队成员对build的关注。

  • 集成源代码变更的过程

代码变更会触发构建,保证了CI能够经常性的运行。

CI对团队的要求

很多团队说我们引入了持续集成,但是收到的效果并不好。比如遇到了CI持续失败、没人关注构建结果、没有及时修复build等。那是因为开发团队没有遵循一定的原则。

  • 经常提交代码

  • 不要提交无法构建的代码

  • 立即修复无法集成的构建

  • 编写自动化的开发者测试

  • 必须通过所有测试和审查

  • 执行私有构建

  • 避免迁出无法构建的代码


持续集成是一个实践性很强的工程活动,其实发展到现在也遇到了一些新的挑战。比如如何减少构建时间、怎样实现分阶段分布式构建、如何应用在有Branch的代码库中、从持续集成进阶到持续交付等。这本书基本没怎么涉及这些话题,毕竟它出版有些年头了,但这仍不失为一本好书。

如果你理解了持续集成的好处,那么在应用过程中就不会有抵触心理,而且也更容易理解持续交付。

相关文章
|
6天前
|
测试技术 持续交付 开发工具
《Git 简易速速上手小册》第6章:Git 在持续集成/持续部署(CI/CD)中的应用(2024 最新版)
《Git 简易速速上手小册》第6章:Git 在持续集成/持续部署(CI/CD)中的应用(2024 最新版)
29 2
|
3月前
|
安全 jenkins 测试技术
自动化测试与持续集成/持续交付(CI/CD)的实践与应用
自动化测试是现代软件开发不可或缺的环节,它可以有效地提高测试效率、降低测试成本。而持续集成/持续交付(CI/CD)则是一种基于自动化的软件开发流程,能够将代码的开发、构建、测试和部署等过程无缝连接起来,从而实现快速迭代和部署。本文将结合实际案例,介绍自动化测试和CI/CD的实践与应用。
150 2
|
3月前
|
存储 测试技术 持续交付
自动化测试与持续集成/持续交付(CI/CD):优化软件开发流程的利器
自动化测试与持续集成/持续交付(CI/CD)是现代软件开发中至关重要的环节,通过将自动化测试与持续集成/持续交付相结合,可以实现开发流程的高效优化,提高软件质量和交付速度。本文将探讨自动化测试与CI/CD的概念、原理及其在软件开发中的重要性,以及如何实施这些技术以提升团队的协作效率和软件交付质量。
58 1
|
1月前
|
敏捷开发 监控 Devops
深入理解软件测试中的持续集成与持续部署(CI/CD)
【2月更文挑战第30天】 在快速发展的软件开发周期中,持续集成(Continuous Integration, CI)与持续部署(Continuous Deployment, CD)已成为确保产品质量和加快交付速度的重要实践。本文旨在探讨CI/CD在软件测试领域中的应用与挑战,解析其对测试流程、自动化及团队协作的影响,并分享最佳实践案例。通过深入了解CI/CD,测试人员可以更好地适应敏捷开发模式,提高测试效率,降低发布风险。
27 1
|
1月前
|
Devops 开发工具 数据安全/隐私保护
Docker Swarm总结+CI/CD Devops、gitlab、sonarqube以及harbor的安装集成配置(3/5)
Docker Swarm总结+CI/CD Devops、gitlab、sonarqube以及harbor的安装集成配置(3/5)
54 0
|
4月前
|
jenkins 测试技术 持续交付
深入理解CI/CD与Docker集成:自动化构建和部署的完整指南
在当今软件开发的快节奏环境中,自动化构建和部署是实现敏捷开发和DevOps实践的关键。Docker容器技术为这一过程引入了更高的灵活性和一致性。本文将深入研究如何将持续集成/持续部署(CI/CD)与Docker集成,提供更详细、实用的示例代码,以帮助大家全面了解并成功应用这一重要的DevOps实践。
|
5月前
|
监控 测试技术 持续交付
持续集成与持续交付(CI/CD):探讨在云计算中实现快速软件交付的最佳实践
蓝绿部署和灰度发布: 使用蓝绿部署和灰度发布等策略,逐步将新版本应用程序引入生产环境,降低风险。
|
6月前
|
监控 安全 测试技术
服务网格和CI/CD集成:讨论服务网格在持续集成和持续交付中的应用。
服务网格和CI/CD集成:讨论服务网格在持续集成和持续交付中的应用。
100 0
|
8月前
|
Kubernetes 持续交付 开发者
使用 Docker 和 Kubernetes 实现持续集成和持续部署(CI/CD)
使用 Docker 和 Kubernetes 实现持续集成和持续部署,可以为开发团队带来更高效、稳定的交付流程。这种自动化的部署方式能够显著提高交付速度、降低发布风险,并为应用的扩展和管理提供了强大的工具。然而,构建一个完善的 CI/CD 环境需要根据团队的需求和实际情况进行调整和优化。
302 1
使用 Docker 和 Kubernetes 实现持续集成和持续部署(CI/CD)