为什么我们迫切需要持续集成?

简介: 本文讲的是为什么我们迫切需要持续集成?【编者的话】持续集成(Continuous Integration),也就是我们经常说的 CI,是现代软件开发技术的基础。本文论述了当前软件开发过程中存在的问题,讲解了持续集成、持续集成服务器的概念,最终探讨了为什么我们需要持续集成来解决这些问题。
本文讲的是为什么我们迫切需要持续集成?【编者的话】持续集成(Continuous Integration),也就是我们经常说的 CI,是现代软件开发技术的基础。本文论述了当前软件开发过程中存在的问题,讲解了持续集成、持续集成服务器的概念,最终探讨了为什么我们需要持续集成来解决这些问题。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。

当前软件开发过程存在的问题

在没有应用持续集成之前,传统的开发模式是这样的:
  • 项目一开始是先划分好模块,分配模块给相应的开发人员;
  • 开发人员开发好一个模块就进行单元测试;
  • 等所有的模块都开发完成之后,由项目经理对所有代码进行集成;
  • 集成后的项目由项目经理部署到测试服务器上,被交由测试人员进行集成测试;
  • 测试过程中出现 Bug 就提把问题记录进行 Bug 列表中;
  • 项目经理分配 Bug 给相应的责任人进行修改;
  • 修改完成后,项目经理再次对项目进行集成,并部署到测试服务器上;
  • 测试人员在下一次的集成测试中进行回归测试;
  • 通过通过之后就部署到生产环境中;
  • 如果测试不通过,则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测* 试服务器上 -> 集成测试”工作。

这个过程中可能会出现如下问题:
  1. Bug 总是在最后才发现
    随着软件技术的发展,软件规模也在扩大,软件需求越来越复杂,软件已经不能简单地通过划分模块的方式来开发,往往需要在项目内部互相合作,模块之间存在一定的依赖关系,那么早期就存在的 Bug 往往会在最后集成的时候才被发现。
  2. 越到项目后期,问题越难解决
    很多开发者需要在集成阶段花费大量的时间来寻找 Bug 的根源,加上软件的复杂性,问题的根源很难定位。而且我们都清楚,间隔的时间越久,Bug 修复的成本越高,因为连开发人员自己都忘了当初写得是什么鬼代码,从而不得不从头阅读代码、理解代码。
  3. 软件交付时机无法保障
    正是因为我们无法及时修复 Bug,或者是没能在早期就修复 Bug,从而令整个修复 Bug 的周期拉长了。不管怎么样,我们不可能把明知存在 Bug 的软件交付给客户。

    而且,大量没有在前期预估到的工作量产生了——开发人员不得不花费大把时间在查找 Bug 上;测试人员不断的需要进行回归测试;项目经理不得不疲命于该死的代码的集成、部署这些重复性工作——最终导致整个项目的周期拉长,交付时间点往后拖。
  4. 程序经常需要变更
    某些项目,程序会经常需要变更,特别是敏捷开发的实践者。由于产品经理在与客户交流过程中,往往实际的软件就是最好的原型,所以软件会被当作原型作为跟客户交流的工具。当然,客户最希望的当然是客户的想法能够马上反映到原型上,这会导致程序会经常被修改的。那么也就意味着“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作无形又爆增了。
  5. 无效的等待变多
    有可能开发在等集成其他人的模块;测试人员在等待开发人员修复 Bug;产品经理在等待新版本上线好给客户做演示;项目经理在等待其他人提交代码。不管怎么样,等待意味低效。
  6. 用户的满足度低
    这里的用户是广义的,可以指最终的客户,也可以是产品经理、公司领导、测试人员,甚至可能是开发人员自己。你想想看,本来三个月做完的项目被拉长到了九个月甚至一年,用户能满意吗!产品经理、公司领导经常需要拿项目作为演示的原型,结果告诉我在演示前一刻发现还有很多 Bug 没有解决,项目启动不了无法访问,这叫人情何以堪。

持续集成、持续集成服务器的概念

那么好了,在上面论述的这些问题中,我们发现有些工作是无法避免的,比如测试工作、修改程序、集成工作、部署工作。但其实在整个工作流程上,是存在可以优化的空间的,比如,集成测试的工作是否可以提前做?可否有自动化的手段来代替测试、集成、部署工作?围绕这些,软件行业的大师们提出“持续集成”口号。
  1. 什么是持续集成、持续集成服务器
    在软件工程中,持续集成(CI)是指将所有开发者工作副本每天多次合并到主干的做法。 Grady Booch 在1991年的 Booch method 中首次命名并提出了 CI 的概念,尽管在当时他并不主张每天多次集成。而 XP(Extreme programming,极限编程)采用了 CI 的概念,并提倡每天不止一次集成。

    而持续集成服务器就是能够采用自动化的手段,来解放人的双手,实现项目持续集成的工具。与之配套的软件有 TeamCity、Jenkins、Go 等。
  2. 怎么样才算是“持续”
    对于一天需要集成多少次数,并没有一个明确的定义。一般就是按照自己项目的实际需要来设置一定的频率,少则可能几次,多则可能达几十次。可以设置按照代码的变更来触发集成,或者设置一个固定时间周期来集成,也可以手工点击集成的按钮来“一键集成”。
  3. 持续集成的工作流程
    • 当开始更改代码时,开发人员会从代码库(如 SVN、Git 等)获取当前代码库的副本。
    • 当其他开发人员将更改的代码提交到代码库时,此副本将逐渐停止反映代码库中的代码。代码分支保持检出的时间越长,当开发人员分支重新集成到主线时,多个集成冲突和故障的风险就越大。
    • 当开发人员向代码库提交代码时,他们必须首先更新他们的代码,以反映代码库中的最新更改。
    • 当存储库与开发人员的副本不同,他们必须要花时间来先处理冲突。

持续集成的好处

  1. 解放了重复性劳动
    自动化部署工作可以解放了集成、测试、部署等重复性劳动,而且机器集成的频率明显可以比手工的高很多。
  2. 更快地修复问题
    由于持续集成更早的获取变更,更早的进入测试,也就能更早的发现问题,解决问题的成本显著下降。
  3. 更快地交付成果
    及早集成、及早测试减少了缺陷遗留到部署环节的机会。在某些情况下,更早地查找错误还会减少解决错误所需的工作量。

    如果集成服务器对代码进行构建过程中发现错误,可以及时发送邮件或者短信提供给开发人员进行修复。

    如果集成服务器在部署环节发现当前版本有问题不可用,集成服务器会将部署回退到上一个版本。这样服务器上始终都会有一个可用的版本。
  4. 减少手工的错误
    人与机器的一个最大的区别是,在重复性动作上,人容易犯错,而机器犯错的几率几乎为零。所以,当我们搭建完成集成服务器后,以后的事就交给集成服务器来打理吧。
  5. 减少了等待时间
    持续集成缩短了从开发、集成、测试、部署各个环节的时间,从而也就缩短了中间可以出现的等待时间。持续集成,意味着开发、集成、测试、部署也得以持续。
  6. 更高的产品质量
    集成服务器往往提供 Code review、代码质量检测等功能。对代码不规范或者有错误的地方会进行标识,也可以设置邮件、短信等进行告警。而开发人员通过 Code review 也可以持续提高编程的能力。

持续集成的最佳实践

  1. 频繁检出代码
    为了让你本地的副本和代码库中的版本最小差异化,建议频繁检出代码。有时候代码冲突无可避免,但最小差异化最容易解决。而且,越早发现的问题,解决成本也最低。
  2. 频繁提交代码
    这个与第1条的原理类似,频繁提交代码,可以让其他人的检出副本和代码库中的版本最小差异化。
  3. 减少分支,回归主干
    虽然代码管理工具都支持分支的概念,但应尽量减少其使用。假设有多个分支并行,应及早将变更集成到主干中,而不是同时维护软件的多个版本。主干作为软件开发的工作版本。
  4. 使用自动化构建
    可以使用 Maven、Ant 等来实现自动化构建,这些工具可以帮助你在构建过程中实现自动化测试。前提是你有写单元测试用例,比如 JUnit 等。
  5. 提交自测
    在提交工作之前,每个程序员必须本地集成所有的代码,做一个完整的构建和运行,并通过所有单元测试。这样就减少了集成测试在集成服务器上构建失败的风险。
  6. 当前状态对于每个人都可见
    集成服务器在持续集成过程中发现问题,应能发送告警给相关的干系人。同时,也可以在墙上等醒目的位置设置一个大屏显示器,将集成服务器的状态实时展现在大屏上,方便提醒组员“赶紧回去解决问题”!

持续集成可能会面临的挑战

  1. 团队人员思想上的抵触
    • 无法接受新事物:不管怎么样,求稳心态的人还是多。总是有人认为老的技术代表稳定,新的事物往往会带来问题。
    • 认为手工集成也没有多少工作量:不是所有的人都参与到了整个持续集成的环节,所以没有办法认识到问题全貌。

      针对这个问题,可以通过设置一定的持续集成技术培训、宣讲得到改观。
  2. 管理层的抵触
    • 培训持续集成需要投入资金啊,没钱。
    • 持续集成服务器要增加软硬件成本啊,没钱。
    • 开发人员领了那么高的工资,多干活多加班应该啊。

      针对这一点,可以从开发人员的成本和持续集成的投入(软硬件)的成本上两者做下估算。
  3. 生产环境的复杂

    比如部署的生成环境是在政务外网,无法从互联网直接访问等。

    目前,这个是最麻烦的,还在研究中。初步设想是让政务外网开辟一个白名单,给持续集成服务器设置一个单独的通道。只是思路,未验证。

    当然,考虑到目前的工作的实际,可以先持续部署软件到自己公司的演示服务器上,这样,起码先解决了客户和产品经理沟通所使用的原型问题。 毕竟,客户真实使用的软件在更新的频率上可以适度的放宽。

参考资料

  • Grady Booch. Object-Oriented Design with Applications.Benjamin Cummings,1991,3(5):209
  • Paul M. Duvall,Steve Matyas,Andrew Glover.Continuous Integration:Improving Software Quality and Reducing Risk.Upper Saddle River:Addison-Wesley,2007
  • http://martinfowler.com/articl ... .html

原文链接:https://waylau.com/why-we-need ... tion/

原文发布时间为:2017-08-17

本文作者:李颖杰

本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:为什么我们迫切需要持续集成?

相关文章
|
6月前
|
前端开发 测试技术 持续交付
前端可持续集成与持续交付
前端可持续集成与持续交付
|
Kubernetes 容灾 Java
浅谈持续集成
角色:功能测试→自动化测试、性能测试、安全测试→测试开发(对软件研发过程提供各种支持,包括工具,框架,方案,最佳实践)
|
jenkins Java Shell
jenkins实现持续集成、持续部署
想要利用jenkins实现持续集成、持续部署,首先我们先思考需要jenkins帮我们做些什么事情才能达到这个目的。首先开发人员提交了代码jenkins应该知道这个变动;其次jenkins知道代码变更后,想要拉取代码,此时要求jenkins服务器上也要有代码拉取的终端,比如git、gitee等;再其次拉取完代码后jenkins就需要打包这些代码成为jar包或者war包,这就需要maven、gradle等打包工具;再然后jenkins需要将这些jar包部署到目标服务器,那就需要相应的插件和脚本来部署这些jar或者war包。
395 1
jenkins实现持续集成、持续部署
|
jenkins 测试技术 持续交付
你真的懂持续集成、持续交付、持续部署吗?!
你真的懂持续集成、持续交付、持续部署吗?!
248 0
你真的懂持续集成、持续交付、持续部署吗?!
|
Kubernetes Java jenkins
6. k8s + jenkins 实现持续集成(完)
一. 在node节点上安装软件. 具体软件内容如下
496 0
6. k8s + jenkins 实现持续集成(完)
|
存储 jenkins Devops
DevOps之持续集成
软件持续集成
860 0
DevOps之持续集成
|
安全 jenkins Devops
2019 DevOps 必备面试题——持续集成篇
原文地址:https://medium.com/edureka/devops-interview-questions-e91a4e6ecbf3 原文作者:Saurabh Kulshrestha 翻译君:CODING 戴维奥普斯 Q1:什么是持续集成? 我会建议你以持续集成的最小定义作为开始来回答这个问题。
|
持续交付
持续集成、持续交付、持续部署简介
怎样去理解集成、交付、部署的概念?首先集成是指软件个人研发的部分向软件整体部分交付,以便尽早发现个人开发部分的问题;交付是指研发尽快向客户交付,以便尽早发现生产环境中存在的问题;部署是代码尽快向可运行的开发/测试节交付,以便尽早测试。
1203 0
持续集成、持续交付、持续部署简介
|
Java jenkins 持续交付
Jenkins 自动化部署 持续集成
螢幕快照 2017-11-18 22.56.06.png Source files build/libs/cms-0.0.1-SNAPSHOT.
1558 0

相关产品

  • 云迁移中心