Jenkins学习总结（4）——持续集成，持续交付，持续部署之间的区别
常见听到持续集成、持续交付、持续部署这三个概念, 但它们具体指什么, 其间的关联与差异又如何呢?
假如把开发工作流程分为以下几个阶段：
编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署
如图所示，「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」各自呈现出各自的自动化交付周期特征。
持续集成
持续集成指的是将软件个体研发的部分逐步提交至全局，并通过频繁整合快速定位并修复潜在问题。“持续集成”源自于极限编程（XP）这一方法论，并属于其最初提出的十二项实践之一。
CI 需要具备这些：
- 全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要；
- 灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折；
- 版本控制工具。如 Git，CVS，SVN 等；
- 自动化的构建和软件发布流程的工具，如 Jenkins，flow.ci；
- 反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。
持续集成的优点
- 采用快速部署的方式，在产品无风险的前提下进行测试，并迅速做出响应。
- 最大限度地降低潜在风险，并减少修复错误代码所需的成本。
- 通过自动化重复性手工流程的处理工作，使开发人员能够将注意力集中在代码编写上。
- 持续频繁地发布版本，并迅速生成可直接部署到生产环境的软件版本。
- 提升项目的可见度水平，在团队中更方便地了解项目进展和成熟度。
- 增强开发人员对软件产品的信心水平，并促进良好的工程师文化氛围的形成。
持续集成，该从何入手
挑选合适的持续集成系统对于提升效率至关重要。是在私有部署模式与托管型持续集成系统之间做出选择，在于团队对系统的基础设施配置以及对资源投入的程度。
对私有部署与托管型持续集成系统进行比较分析后发现，在实际应用中选择合适的方案能够显著提升开发效率。
Self Hosted CI 指的是将软件部署于企业的机房或内部网络中，并为此提供了必要的服务器配置以便构建CI系统。例如使用Maven、Gradle及Jenkins等工具时需注意这些开源自由且文档支持全面的特性。优势在于能够完全掌控构建环境从而实现高度定制化的优势然而这种做法也带来了较高的门槛包括搭建环境及配置工作量大维护成本高昂需要投入专门设备导致的人力物力消耗以及更新迁移过程中潜在风险的升高问题。
Hosted Continuous Integration (CI)指的是基于云平台提供的自动化代码管理和测试工具。通过完全在线的方式自动处理代码构建配置，并且能够自动处理环境搭建工作而无需自行部署服务器或安装软件。其中CircleCI, Codeship以及TravisCI等国际知名平台广受欢迎；此外，在国内也有最新的人工智能驱动自动化测试平台flow.ci。SaaS型的CI的特点是无需额外机器；几分钟就可以上手并开始使用；可以根据实际需求灵活调配资源；最后还可以实现高效的工作流程管理：节省时间的同时也能降低工作压力和复杂度
就目前情况来看，Jenkins曾经是大多数企业的首选工具。然而这一趋势正经历着转变，在云计算服务、容器化技术以及软件即服务（SaaS）日益普及的情况下，在这种背景下越来越多的企业现在倾向于采用托管型持续集成系统作为他们的开发流程的一部分。
此外，在选择合适的持续集成服务时,还需要考虑系统的灵活性以便满足开发和测试的需求
采用持续集成系统仅是持续集成方案中的一部分工作流程，在构建组织良好的持续集成文化方面还需投入相应的资源和精力包括但不限于代码质量管理与测试导向的文化建设等环节。若想确保系统的稳定运行需从软件构建与部署的关键环节入手为其提供坚实的保障
持续交付
持续交付机制在持续集成的基础上实现了集成后代码向更贴近真实运行环境的「类生产环境」（production-like environments）迁移过程。该机制在整个软件开发周期中采用高度自动化和高效的持续集成平台实现，并通过严格的时间管理确保资源利用率最大化。在整个软件开发周期中采用这一机制能够显著提升效率
考虑到等到全部流程完成后再向下级环节进行交付的情况会导致所有问题集中显现并产生巨大的解决成本这种做法并不理想
持续交付的好处
持续交付和持续集成的优点非常相似：
- 高效发布：不仅能够满足业务需求的需求响应能力，并且能够在较短的时间内实现更高的软件价值。
- 开发流程中的迭代周期显著缩短：通过优化现有架构设计和流程安排；从而带来及时的反哺。
- 严格的软件发布标准：确保系统运行的安全性和稳定性。
- 规范化且易于复制的操作流程：保证系统的稳定运行。
- 系统化的团队协作模式：从需求分析到产品全生命周期管理；通过多维度协同运作；相比传统的瀑布式管理模式；实现了资源投入的最大化利用。
持续部署
持续发布是指在代码经过评审确认无误后自动进入生产环境的过程。这是持续交付体系中的顶级阶段。该流程意味着所有经过多步自动化测试修改均会即时投入生产环境使用。也可简称为"Continuous Release"。
为什么说持续部署是理想的工作流程？
开发人员将代码提交至系统中进行处理；接着由持续集成服务器接收待测代码；随后运行单元测试用例；基于测试结果判断是否将应用推入预发布环境；若在预发布环境中顺利完成部署，则随后进行全面的功能验收测试；若验收测试顺利通过，则系统将应用直接推送到正式生产环境中完成最后的稳定运行验证。
实际情况下,产品在从需求转化为具体实施的过程中,会经历多个不同的运行环境,包括QA环境以及各种自动化测试运行环境和生产环境等。这些不同环境下系统的搭建、配置与管理,以及产品在整个过程中如何实现无缝切换与稳定运行等问题都面临着诸多挑战,完全实现全自动持续部署并非易事。然而,若能够实现持续交付能力的提升,则能在模拟环境中安全通过测试并确保代码质量的同时,使团队成员对系统的关键工作点具备充分信心掌握所有关键点
持续部署的优点
持续部署的主要显著优势在于,能够以高度自治的方式部署新的功能,并且能够高效地收集真实用户的反馈
而与其仅仅构建系统（You build it），不如将其投入持续运营（you run it）——这是亚马逊每年可实现5\times1e^8次部署的核心秘诀。
每位开发人员的日均部署量达到每日超5\times1e1次。
最后
构建了一个卓越的DevOps环境