什么是CI/CD
创作不易，请珍惜，之后会持续更新，不断完善
个人比较喜欢做笔记和写总结，毕竟好记性不如烂笔头哈哈，这些文章记录了我的IOS成长历程，希望能与大家一起进步
温馨提示：由于简书不支持目录跳转，大家可通过command + F 输入目录标题后迅速寻找到你所需要的内容
目录
- 一、DevOps
- 二、Continuous Integration
- 三、架构师的日常
- 四、关于旅行
- 参考文献
CI/CD 的出现改变了开发人员和测试人员发布软件的方式。从最初的瀑布模型， 到后来的敏捷开发（Agile Development ）， 再到今天的 DevOps，这是现代开发人员构建出色产品的技术路线。 随着 DevOps 的兴起，出现了持续集成，持续交付（CI/CD）和持续部署的新方法， 而传统的软件开发和交付方式在迅速变得过时。过去的敏捷时代里， 大多数公司的软件发布周期是每月、每季度甚至每年；而在现在 DevOps 时代，每周、每天甚至每天多次都是常态。 当 SaaS 成为业界主流后尤其如此，您可以轻松地动态更新应用程序， 而无需强迫用户下载更新组件。很多时候，用户甚至都不会注意到正在发生变化。
开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期， 大多数团队都有自动化流程来检查代码并部署到新环境。 我们一直在关注自动化测试流程。 今天，我们将介绍什么是 CI/CD ，以及现代软件公司如何使用工具将部署代码的流程自动化。
一、DevOps
DevOps是Development和Operations的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。
DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。具体来说，就是在软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。
也就是说DevOps是一组过程和方法的统称，并不指代某一特定的软件工具或软件工具组合。各种工具软件或软件组合可以实现DevOps的概念方法。其本质是一整套的方法论，而不是指某种或某些工具集合，与软件开发中设计到的OOP、AOP、IOC（或DI）等类似，是一种理论或过程或方法的抽象或代称。
在了解了什么是DevOps之后、我们来看看到底什么是CI/CD？CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。
具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。现在我们把CI/CD拆分开、我们先来看看什么是CI？
二、Continuous Integration
CI的英文名称是Continuous Integration，中文翻译为：持续集成。CI中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。 持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。CI的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。
通俗点讲就是：通过持续集成， 开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。这里的一个重要思想就是让开发人员更快更、频繁地做到这一点，从而降低集成的开销。 实际情况中，开发人员在集成时经常会发现新代码和已有代码存在冲突。 如果集成较早并更加频繁，那么冲突将更容易解决且执行成本更低。当然，这里也有一些权衡，这个流程不提供额外的质量保障。 事实上，许多组织发现这样的集成方式开销更大，因为它们依赖人工确保新代码不会引起新的 bug 或者破坏现有代码。 为了减少集成期间的摩擦，持续集成依赖于测试套件和自动化测试。 然而，要认识到自动化测试和持续测试是完全不同的这一点很重要。
CI 的目标是将集成简化成一个简单、易于重复的日常开发任务， 这样有助于降低总体的构建成本并在开发周期的早期发现缺陷。 要想有效地使用 CI 必须转变开发团队的习惯，要鼓励频繁迭代构建， 并且在发现 bug 的早期积极解决。
三、CD
这里的CD可对应多个英文名称，持续交付Continuous Delivery和持续部署Continuous Deployment。下面我们分别来看看上面是持续交付和持续部署。
持续交付（CD）
持续交付（CD）实际上是 CI 的扩展，其中软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。 成熟的持续交付方案也展示了一个始终可部署的代码库。使用 CD 后，软件发布将成为一个没有任何紧张感的例行事件。 开发团队可以在日常开发的任何时间进行产品级的发布，而不需要详细的发布方案或者特殊的后期测试。
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。
CD 集中依赖于部署流水线，团队通过流水线自动化测试和部署过程。此流水线是一个自动化系统， 可以针对构建执行一组渐进的测试套件。CD 具有高度的自动化，并且在一些云计算环境中也易于配置。在流水线的每个阶段，如果构建无法通过关键测试会向团队发出警报。否则，将继续进入下一个测试， 并在连续通过测试后自动进入下一个阶段。流水线的最后一个部分会将构建部署到和生产环境等效的环境中。 这是一个整体的过程，因为构建、部署和环境都是一起执行和测试的，它能让构建在实际的生产环境可部署和可验证。
持续部署（CD）
持续部署扩展了持续交付，以便软件构建在通过所有测试时自动部署。在这样的流程中， 不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。 此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容。采用持续部署的组织可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，并且可以迅速处理任何明显的缺陷。 用户对无用或者误解需求的功能的快速反馈有助于团队规划投入，避免将精力集中于不容易产生回报的地方。
随着 DevOps 的发展，新的用来实现CI/CD流水线的自动化工具也在不断涌现。这些工具通常能与各种开发工具配合， 包括像 GitHub 这样的代码仓库和 Jira 这样的 bug 跟踪工具。此外，随着 SaaS 这种交付方式变得更受欢迎， 许多工具都可以在现代开发人员运行应用程序的云环境中运行，例如 GCP 和 AWS。但是对于一个成熟的CI/CD管道（Pipeline）来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。目前最受欢迎的自动化工具是 Jenkins。
持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。持续交付表示的是一种能力，而持续部署表示的则一种方式；持续部署是持续交付的最高阶段。
四、Agile Development
最后我们再来看看上面是敏捷开发，这个称呼似乎还没有所谓的简称，而且这个称呼似乎在国内被滥用了。敏捷开发着重于一种开发的思路，拥抱变化和快速迭代。如何实现敏捷开发，目前似乎尚没有完善的工具链，更多的是一种概念性，调侃的说法“既想马尔跑得快，又想马儿不吃草”的另外一种说法。
