了解CI和CD之间的区别:“如果某事导致疼痛,请多做点事情”

免责声明 Kostis Kapelonis-开发者倡导者Codefresh,第一个用于Kubernetes和容器的CI / CD平台,旨在捍卫和维护软件开发原则。 Codefresh的任务“自动化和简化从代码到云的一切。” 作为软件工程师,Kostis在容器化应用程序,构建CI / CD管道和开发Java应用程序方面拥有多年经验。 他住在希腊,喜欢溜冰。

俗话说,“如果某事引起疼痛,那就多做些。” 本质上,连续积分是高频重复积分步骤,以减轻其引起的“疼痛”。 本文就是关于此的-关于开发的“痛苦”以及如何减少它。

有关持续集成(CI)和持续交付(CD)的信息很多。 博客文章使用技术术语来解释CI / CD方法论的含义,其作用以及如何为您的公司提供帮助。 不幸的是,这两种方法通常都与特定工具甚至软件提供商相关联。 在公司中有关此主题的典型对话是:

-您是否在团队中使用持续集成?
-是的,我们当然使用工具X!

让我告诉你一个小秘密。 持续集成和交付是两种与特定工具或供应商完全无关的代码开发方法。 尽管有在这两种情况下都可以为您提供帮助的工具和解决方案(例如Codefresh),但实际上,公司可以仅使用bash脚本和Perl单行脚本来练习CI / CD。 这不是很实际,但肯定是可能的。

因此,我们不会陷入使用工具和技术术语来解释CI / CD本质的一般陷阱,而是将解释这些方法是基于开发过程中最重要的因素-人员!

人的故事:艰难时期的软件集成


认识Alice,Bob,Charlie,David和Elizabeth-他们全都在SoftwareCo Inc.工作。 创建SuperBigProject应用程序。 爱丽丝,鲍勃和查理是开发人员。 David是测试工程师,Elizabeth是团队项目经理。

开发应用程序的传统方法如下:Alice,Bob和Charlie在其工作站上使用三种不同的功能。 每个开发人员分别编写和测试代码。 他们使用功能的长分支,这些分支存在数周甚至数月之久,然后才被合并为最终产品。



在某个时候,项目经理Elizabeth聚集了整个团队,并说:“人们,我们已经需要发布版本,所以您可以尝试!”

之后,Alice,Bob和Charlie尝试将其所有三个功能集成到一个分支中。 这是一个非常紧张的时刻,因为这些功能从未一起测试过。 由于错误的假设或环境问题,许多错误和问题无处不在,因为到目前为止,您记住,所有功能都已经在彼此隔离的不同工作站上进行了简单测试。

一旦“整合热”结束,合并的结果将传递给David,David将执行附加的手动和自动测试。 这个时间也要花费很多时间,因为可以根据发现的严重错误的多少,由David批准或阻止发布。 每个人都在密切注意David的工作,因为对其进行测试可能会发现严重的问题,可能会延迟产品的发布。

最终,测试完成,Elizabeth高兴地宣布该软件产品已准备好包装和运输。

那么,人们对这个虚构但非常现实的故事有何感想?

  • 开发人员Alice,Bob和Charlie不满意,因为他们总是在发布前就发现集成问题。 融合期类似于枪弹从各个方向同时到达的枪战。
  • 测试人员David由于其工作的“抽搐”性质而一直感到紧张-在平静的时期内,他只是等到开发人员完成对功能的工作为止,而在测试阶段,他只是不堪重负,必须处理意外的测试脚本,以便此外,此时,开发团队确实站在他身后。
  • 作为项目经理的伊丽莎白也很不高兴。 集成阶段是项目中的关键环节。 这是一个忙碌的时期,因为任何意外的问题都会推动产品的发布。 Elizabeth梦想没有任何惊喜地发布软件,但是实际上这从来没有发生过。 在项目计划的时间表中,集成阶段的“成功”始终是一个猜谜游戏。

通常,所有团队成员都不满意。 顺便说一句,如果您的公司仍在开发此类软件,请尝试了解该开发过程对您团队的士气有害。

因此,这里唯一且主要的问题是集成阶段,集成阶段随软件产品的每个发行版而发生。 这是工作流中的一个痛点,它不允许一组程序员将自己从与程序发布相关的压力情况中解放出来。

为集成增加连续性


既然我们已经了解了“集成”的含义,那么很容易理解“持续集成”的含义。 俗话说,“如果某事引起疼痛,那就多做些。” 本质上,连续积分是高频重复积分步骤,以减轻其引起的“疼痛”。

使过程更轻松的最明显方法是在每次合并后更频繁地进行集成,而不是等待正式发布。



当团队练习持续集成时,则:

  • 所有对象都直接合并到主分支中。
  • 开发人员一起工作,而不是孤立地工作。 所有功能都是从主线开发的。
  • 如果干线可以完全正常运行并且可以在任何机器上工作,而不仅仅是在单独的工作站上工作,则认为该功能已开发。
  • 测试会在单个元素或代码对象级别以及主线级别自动进行。

这是持续集成的本质。 当然,这种方法还有其他细微差别,关于这一主题有一整本书,但是最主要的是,整合不是一个单一的紧张时期,当所有事物同时被融合和测试时,整合始终以连续的方式发生。

软件开发过程中的持续集成优于常规集成,因为:

  • 减少合并代码对象时出现的惊喜数目。
  • 它解决了“程序只能在我的机器上运行”的问题。
  • 它将测试周期分为几个周期,每个代码对象逐渐与主线合并,而不是一次合并所有对象。

因此,使用CI的团队在平静的开发阶段和压力释放之间穿插的感觉并不像过山车。 另外,她有机会清醒地评估项目离完成的距离,而不用猜测发布日期。 使用CI是现代软件开发的支柱之一。 如今,这种方法已经得到了很好的证明和公知。 因此,您的公司在软件项目的开发中仍然没有实践CI的事实是没有道理的。

艰难时期软件交付


现在,我们已经了解了常规集成的历史以及持续集成的工作方式,我们可以将其带入开发流程的下一个阶段-持续交付。 如果我们回到原始故事,我们将看到与正常整合过程相似的图片:



产品发布实质上是类似于“大爆炸”的事件。 在考虑对软件进行测试之后,必须要有人完成从容器中最小化和部署软件的过程。 在生产上部署软件也是一个非常繁忙的时期,传统上包括许多手动步骤和后续程序。 部署非常罕见,即使到今天,也有公司每六个月执行一次此过程不超过一次。 仅在极端情况下,部署是一次进行-使用软件开发的级联模型时(瀑布)。

仅在截止日期后交付软件,才会产生与常规,不频繁集成相同的问题:

  • 生产环境通常与测试环境不同,后者需要在最后一刻进行其他配置。
  • 在测试环境中正常工作的功能会破坏工作环境。
  • 发布时尚未准备就绪的功能,或者根本不会提供给客户,或者其完善会进一步推动发布。
  • 在这方面,发行版在想要添加新功能以扩展软件功能的开发人员与想要稳定且不希望一次部署太多新功能的运营商之间产生了紧张关系。

该问题的解决方案是与集成情况下的模板相同。 如果我们可以通过增加集成频率来减轻集成过程的痛苦,那么我们可以在软件交付过程中做到这一点。

增加交付的连续性


连续交付是一种实践,即尽可能多地将其包装在容器中并准备好软件,就像将其发送到生产环境一样。 最极端的交付方式是每次合并之后。



这样,CD使CI迈出了一步。 将每个功能与mainline分支合并后,不仅会检查应用程序的正确性,还将其打包并部署到与工作环境完全匹配的测试环境中。 所有这些都是在全自动模式下发生的-请注意图中没有矮个子的人指示手动操作。

还请记住,每个新功能都是投入生产的潜在候选者。 实际上,并非所有候选人都被送去生产。 根据流程的组织,有时决定要部署到生产中,而要由负责人干预,该人决定是否将发布发布到生产中,但不亲自参与发布的准备。 至此,该版本已经打​​包,测试并部署在测试环境中。

连续交付(CD)比连续集成(CI)稍微复杂一些。 原因是由于每个候选发布者都可能实现生产,因此整个生命周期应实现自动化:

  • 装配必须是可重复的和确定的。
  • 所有步骤都必须自动化,这很难付诸实践。
  • 所有配置和相关文件必须存在于版本控制系统中,而不仅仅是源代码中。
  • 每个功能/发行版都必须在其自己动态创建和动态销毁的测试环境中进行测试。
  • 所有测试套件都必须自动化并且相对较快,这也不是一件容易的事。

尽管“云”当然可以帮助满足所有这些要求,但是一个由开发人员和操作人员组成的程序员团队需要一定程度的纪律,才能真正确保持续交付软件的过程。

引入CD后,发行成为例行程序,就像单击按钮一样。 每个团队成员,而不仅仅是项目经理,都可以看到当前的候选版本。 该候选者可能没有某些必需的功能,或者可能无法完全满足所有要求,但这在影响发行过程本身之前绝对不重要。

重要的事实是,该版本已经过全面测试,打包,并在必要时准备好用于生产。 同时,任何项目参与者都应能够开绿灯,并立即发布用于生产的软件。

如果使用CD,则软件生命周期可以表示如下:



每个候选发布者总是要事先准备。 此人决定是否也要提名释放候选作品。 未达到生产要求的发行候选版本将继续作为工件存储,以备将来使用。

为了提供有关连续交付以及持续集成的信息,您还撰写了整本书,从中可以找到有关此方法的详细信息。

奖励:持续部署


CD中的字母“ D”可能表示部署部署,而不是交付交付。 这种开发过程的方法基于连续交付,并且基本上消除了人为干预。 任何可以通过所有测试和质量检查并被确认已经准备就绪的发行版候选软件,将立即投入生产。



诚然,只有极少数的公司能够以这种方式运营。 在不需人工参与的情况下,将生产提升为轻便之举,因为在撰写本文时,许多公司甚至没有实行持续交付,更不用说持续部署了。

您必须了解,开发过程的每个后续方法都基于先前方法的实现。



在走上改进之路之前,您的公司必须确保过程的每个基础都是真正牢固的。 我们在Codefresh看到许多公司打算转向云技术,试图重新配置其优化的技术,以用于CI / CD管道上的数据中心,而没有意识到其中某些技术已经过时。 尝试部署连续部署而没有完全拥抱连续交付注定会失败。

下图显示了由爱丽丝(Alice),鲍勃(Bob),查理(Charlie),大卫(David)和伊丽莎白(Elizabeth)进行的软件开发和实施过程的哪个阶段,涵盖CD和CI。



确保以正确的顺序处理每个软件开发范例。 相信引入持续交付是一个非常现实的目标,要实现该目标,必须具备所有必要的工具。

一点广告:)


感谢您与我们在一起。 你喜欢我们的文章吗? 想看更多有趣的资料吗? 通过下订单或向您的朋友推荐以支持我们,开发人员的云VPS从4.99美元起为Habr用户提供30%的折扣,这是我们为您发明的入门级服务器的独特模拟: 关于VPS(KVM)E5-2650 v4的全部真相(6核心)10GB DDR4 240GB SSD 1Gbps from $ 20或如何共享服务器? (RAID1和RAID10提供选件,最多24个内核和最大40GB DDR4)。

戴尔R730xd便宜2倍? 只有我们有2台Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100电视在荷兰起价199美元 戴尔R420-2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB-$ 99起! 阅读有关如何构建基础架构大厦的信息。 使用价格为9000欧元的Dell R730xd E5-2650 v4服务器的上等课程?

Source: https://habr.com/ru/post/zh-CN474326/


All Articles