400-666-7732

知道你已经实现了持续集成的7种方法

撰稿人 Brian Dawson

2018年/3月/9日

在去年的Jenkins世界研讨大会上，我最喜欢的时刻之一是技术大师Jez Humble在他的主题演讲中带领大家快速举手示意，并讨论谁在真正做持续集成（CI）。由于座位上坐的都是耳熟能详的最敬业的DevOps专家，人们会认为这些专家对持续集成都会有十足的把握。

Humble问了几个引导性问题：

  • 谁没有定期向他们组织的主要管道中提供构建？
  • 谁不能在10分钟内修复一个软件问题？那些做不到或不做的人，请放下你们的手。
  • 每个问题之后都有一些人放下了手。最后，原来的一小部分人的手还在空中。这些都是 Jenkins 用户！

Humble给出结论：很大一部分人认为他们在做持续集成，但他们实际上并没有。

“持续集成真的很难“，Humble 向在座的各位说道，"很多人将其重新定义为他们已经在做的任何事情"。

你真的在做持续集成吗？这是一个重要的问题。毕竟，持续交付（CD）和DevOps正在颠覆市场，为企业提供了巨大的竞争优势。持续交付是建立在持续集成久经考验的实践之上的。那些试图认识到持续交付的好处的组织往往没有完全理解持续集成的概念。

正如Humble在Jenkins 世界研讨大会的主题演讲中所说的，那些正确进行持续集成的组织都遵循一些基本规则。例如，开发人员的工作副本至少每天与共享主线同步，最好是每天多次。每个集成都会通过自动构建进行验证，以尽快发现错误。没有遵循这些步骤的组织并没有真正正确地进行持续集成。

持续集成是一个开发团队的实践，为整个组织产生真正的价值。负责实施持续集成实践的工程师希望实现这些价值，并遵循他们同行正在遵循的现代实践。他们只是在试图实现这一目标时遇到了问题。

他们了解到其他组织是如何实施持续集成后，决定他们是否能在自己团队里做同样的事情。但每个组织都是有区别的。DevOps团队可能对他们组织中的持续集成有一个愿景，但它可能不符合普遍接受的CI定义。

不遵循持续集成的核心原则的组织，很可能会在定期提供清晰、有效的构建时遇到问题。随着时间的推移，该计划将失去动力，团队成员也将不再抱有幻想。对变化有抵触情绪的人（也就是我们中的大多数人），如果看不到变化带来的好处，即使是很小的增量，也会恢复到原来的老做法。在这种情况下，您有多个问题，您的构建仍然有很多错误。您的团队已经失去了对实施的信心，您已经失去了关键的时间，现在您需要重新启动这个项目。

没有正确实施持续集成的组织往往面临文化问题。工程师擅长解决技术问题，但CI需要文化的转变。文化是很难改变的。你可以引进一个持续集成工具，并勾选大多数适用于CI所代表的方框，但CI的成功需要改变您的工作方式和合作方式。 如果团队的文化不改变，他们将很难实施持续集成。

概述：做持续集成就像在你最好的西装外穿上一件雨衣。你已经承诺严格的交付时间表，并承诺了公司新应用程序的最佳版本，因为你相信持续集成原则所提供的外衣会保护你的项目。如果雨衣不防水，你的西装就会被毁掉。CI的情况也一样。让你的项目向外界开放，它可能最终会被淹没。

如果这听起来像是适当调整的CI流程是为了消除错误，那就错了。 持续集成本身就是一个旨在接受失败的过程。我们希望创建一个系统，让开发人员可以在其中经常失败--而且是快速失败，这样他们就可以及早发现并快速修复错误。持续集成就像多风的道路上的护栏--让开发人员有信心开快车，因为如果他们的构建过于接近边缘，他们会受到保护。

持续集成的核心原则和实践至少可以追溯到15年前，当时Martin Fowler提出了这个术语，并且它们在今天仍然适用。以下是组织真正正确执行 CI 需要遵循的七个实践：

  1. 专注于主线上：这是持续集成的赌注。开发者可以设置一个自动构建，并在每次提交时运行构建。但如果企业文化是不经常提交，那就无所谓了。如果一个开发者等了三周才提交，或者在三周内没有提交，他就延迟了集成，破坏了原则。如果一个构建出现问题，团队就必须对三周的工作进行整理，以找出问题所在。
  2. 维护单一源资源储存库：在复杂的应用程序中，开发人员经常从一个主干（分支）或主干上进行分支和维护修改。 分支造成了复杂性，使每个人都无法使用单一的事实来源。团队需要每天至少向主干提交/合并一次，甚至对每一个变更都要提交/合并。
  3. 自动化构建： 这是大多数组织倾向于做好的做法。然而，一些声称实践CI的人所做的仅仅是预定的构建（即每晚的构建），或持续的构建，但他们实际上没有测试或验证每个构建。没有对构建的验证，你就没有做持续集成。
  4. 构建自测：验证过程的第一步是要知道有问题的构建实际上是失败的。下一步是确定构建的产品是否可以运行，构建的性能是否符合我们的预期。这种测试应该作为构建过程的一部分。这包括快速的功能和非功能测试。
  5. 快速构建： 如果构建一个应用程序需要太长的时间，开发人员将不愿意定期提交更改，或者会有较大的更改集。在这两种情况下，没有人会迅速发现故障。通过快速构建和快速集成，你可以快速隔离更改。如果运行需要几个小时，在这段时间里你可能还有20到30个更改，那么就很难迅速发现问题。
  6. 克隆测试： 验证过程验证了软件在其预期环境中的表现是否符合预期。如果你在不同类型的环境中测试，可能会给你带来错误的结果。
  7. 立即修复损坏的构建： 对于开发团队来说，快速发现问题并立即修复它们是至关重要的，这样它们就不会向下游发展。多年前，丰田公司制定了一种 “停止生产线 “的方法，工人们如果发现问题，可以拉动绳子并停止生产过程。CI建立了一个过程，在这个过程中，构建被不断地验证和提交，所以如果出了问题，将很容易修复。

尽管组织在实施真正的持续集成方面面临着所有的挑战，但重要的是要注意到软件开发社区在遵循为其运营创造真正价值的现代流程方面已经取得了很大的进展。许多人正在努力做出更改并改进他们的DevOps实践。原始CI的最大障碍是我们对传统技术的文化、情感和技术的依恋。这些都是变革的敌人。即使你超越了 "不能有的文化"，带着传统做法的包袱也会带来巨大的障碍。

组织面临的另一个挑战是过度发挥他们的作用。每个人都想用CI这样的方法论来改变他们的运营，但很少有人愿意诚实地谈论他们仍然需要改进他们的流程。

在持续集成首次成为行业术语的十多年后，我们仍在努力将其做得更好。

Brian Dawson是CloudBees的DevOps宣传者。

CloudBees授权合作伙伴——龙智

提供CloudBees的咨询、销售、实施部署、培训、技术支持服务。

免费试用

产品中心

Atlassian 解决方案

Mend – 开源代码安全检测

Cloudbees CI/CD – 企业版Jenkins

Incredibuild – 编译和构建加速

Jama Software – 需求管理和可追溯性

Tessy – 嵌入式测试工具

JFrog – 制品库管理

  

Perforce 解决方案

Smartbear - 软件测试、监控与开发

JetBrains 解决方案

  

Atlassian 插件-龙智自研

Perforce 插件-龙智自研

其它热门Atlassian插件

联系我们

微信公众号

订阅我们的Newsletter

服务

© 版权所有 2006-2025 上海龙智数码科技股份有限公司 

沪公网安备31010402001343

沪ICP备09059266号-1

电子营业执照

联系我们

  • 400-666-7732
  • customer@shdsd.com
  • 上海市徐汇区龙漕路299号2幢B座9楼

微信公众号

© 版权所有 2006-2025 上海龙智数码科技股份有限公司