什么是持续集成 源程序量


什么是持续集成 源程序量



编译自: http://img8888.yunnanlong.com/2023/1156/nbizrjx14l0
作者: Brent Laster
译者: pityonline
在软件开发中经常会提到 持续集成(Continuous Integration)(CI)和 持续交付(Continuous Delivery)(CD)这几个术语 。但它们真正的意思是什么呢?
在谈论软件开发时,经常会提到 持续集成(Continuous Integration)(CI)和 持续交付(Continuous Delivery)(CD)这几个术语 。但它们真正的意思是什么呢?在本文中,我将解释这些和相关术语背后的含义和意义,例如 持续测试(Continuous Testing)和 持续部署(Continuous Deployment) 。
概览工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品 。同样,软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本 。如何完成这项工作的总体设计称为“持续交付”(CD) 。启动装配线的过程称为“持续集成”(CI) 。确保质量的过程称为“持续测试”,将最终产品提供给用户的过程称为“持续部署” 。一些专家让这一切简单、顺畅、高效地运行,这些人被称为 运维开发(DevOps)践行者 。
“持续”是什么意思?“持续”用于描述遵循我在此提到的许多不同流程实践 。这并不意味着“一直在运行”,而是“随时可运行” 。在软件开发领域,它还包括几个核心概念/最佳实践 。这些是:
频繁发布:持续实践背后的目标是能够频繁地交付高质量的软件 。此处的交付频率是可变的,可由开发团队或公司定义 。对于某些产品,一季度、一个月、一周或一天交付一次可能已经足够频繁了 。对于另一些来说,一天可能需要多次交付也是可行的 。所谓持续也有“偶尔、按需”的方面 。最终目标是相同的:在可重复、可靠的过程中为最终用户提供高质量的软件更新 。通常,这可以通过很少甚至无需用户的交互或掌握的知识来完成(想想设备更新) 。自动化流程:实现此频率的关键是用自动化流程来处理软件生产中的方方面面 。这包括构建、测试、分析、版本控制,以及在某些情况下的部署 。可重复:如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为,则这个过程应该是可重复的 。也就是说,如果我们把某个历史版本的代码作为输入,我们应该得到对应相同的可交付产出 。这也假设我们有相同版本的外部依赖项(即我们不创建该版本代码使用的其它交付物) 。理想情况下,这也意味着可以对管道中的流程进行版本控制和重建(请参阅稍后的 DevOps 讨论) 。快速迭代:“快速”在这里是个相对术语,但无论软件更新/发布的频率如何,预期的持续过程都会以高效的方式将源代码转换为交付物 。自动化负责大部分工作,但自动化处理的过程可能仍然很慢 。例如,对于每天需要多次发布候选版更新的产品来说,一轮 集成测试(integrated testing)下来耗时就要大半天可能就太慢了 。什么是“持续交付管道”?将源代码转换为可发布产品的多个不同的 任务(task)和 作业(job)通常串联成一个软件“管道”,一个自动流程成功完成后会启动管道中的下一个流程 。这些管道有许多不同的叫法,例如持续交付管道、部署管道和软件开发管道 。大体上讲,程序管理者在管道执行时管理管道各部分的定义、运行、监控和报告 。
持续交付管道是如何工作的?软件交付管道的实际实现可以有很大不同 。有许多程序可用在管道中,用于源代码跟踪、构建、测试、指标采集,版本管理等各个方面 。但整体工作流程通常是相同的 。单个业务流程/工作流应用程序管理整个管道,每个流程作为独立的作业运行或由该应用程序进行阶段管理 。通常,在业务流程中,这些独立作业是以应用程序可理解并可作为工作流程管理的语法和结构定义的 。

推荐阅读