持续集成，交付，部署和成熟度模型

持续集成，持续部署和持续交付都相互关联，并且相互融合。 已经用这些术语写了几篇文章。 该博客将尝试以一种易于理解的方式解释这些术语。

什么是持续集成？

持续集成（CI）是一种软件实践，要求开发人员每天至少一次，可能几次将其代码提交到主工作区。 期望开发人员在提交源代码之前在其本地环境中运行单元测试。 团队中的所有开发人员都遵循这种方法。 通常在每次提交之后或可能定期地检出主要工作区，然后验证其是否存在构建问题，集成测试，功能测试，性能，寿命或任何其他类型的测试。

在CI中执行的测试级别可以完全不同，但是关键的基本原理是一天之内都要完成来自不同开发人员的多次集成。 遵循此方法的最大优点是，如果有任何错误，则可以在周期的早期（通常是在提交后不久）将它们识别出来。 找到更接近提交的错误确实会使它们更容易修复。 马丁·福勒对此作了很好的解释 ：

持续集成并不能消除错误，但确实可以使查找和删除错误变得更加容易。

有许多提供CI功能的工具。 最常见的是来自CloudBees的Jenkins，来自TravisWorks的 Travis CI ， 来自ThoughtWorks的Go和来自Atlassian的Bamboo 。

什么是连续交付？

持续交付是持续集成的下一个逻辑步骤。 这意味着只需按一下按钮，就可以释放对系统的每次更改，即每次提交。 这意味着对工作区所做的每个提交都是生产的候选发布。 但是，此版本仍是手动过程，需要明确按下按钮。 由于诸如降低软件部署速度之类的业务问题，此手动步骤可能至关重要。

在某些时候，您甚至可以将软件推向生产环境，以获得反馈。 这样可以在每次提交时获得有关软件生产就绪状态的快速自动反馈。 高度自动化的测试对于实现持续交付至关重要。

通过构建部署管道可以实现持续交付。 这在Jez Humble（ @jezhumble ）的“ 持续交付”书中有最好的描述。

部署管道是应用程序的构建，部署，测试和发布过程的自动化实施。

管道，所使用的工具和过程的实际实现可能有所不同，但是100％自动化的基本概念是关键。

什么是持续部署？

连续部署通常与连续交付相混淆。 但是，这是连续交付的逻辑结论，其中完全实现了生产发布。 这意味着对工作区的每次提交都会自动发布到生产环境，从而导致一天中多次部署软件。

连续交付是连续部署的基本先决条件。

持续交付成熟度模型

成熟度模型允许团队或组织根据明确定义的基准评估其方法和过程。 根据能力成熟度模型中的定义， 术语“成熟度”涉及流程的形式化和优化程度，从临时实践到正式定义的步骤，到管理结果度量，再到流程的积极优化 。

该模型解释了不同的阶段，并通过从较低阶段过渡到较高阶段来帮助团队进行改进。 可以使用几种连续交付成熟度模型，例如InfoQ ， UrbanCode ， ThoughtWorks ， Bekk等。

能力成熟度模型集成 （CMMI）由卡内基梅隆大学的软件工程学院定义。 CMMI-Dev特别定义了模型，该模型为在开发组织中应用CMMI最佳实践提供指导。 它定义了五个成熟度级别：

• 初始
• 管理
• 已定义
• 量化管理
• 最佳化

提到的这些“持续交付”成熟度模型中的每一个都定义了自己的成熟度级别。 例如，InfoQ使用了基础，初学者，中级，高级，专家。 专家已更改为UrbanCode的Extreme。 ThoughtWorks使用CMMI-Dev的成熟度级别，但并未将其划分到不同的区域。

这是成熟度模型的另一种尝试，该模型从每个模型中挑选最好的模型。

作为团队/组织，您需要查看适合此成熟度模型的位置。 而且，一旦您确定了这一点，更重要的是，算出如何进入下一个层次。 例如，如果您的团队没有任何数据管理或迁移策略，则您处于“数据迁移”中的“初始”级别。 您的目标是从初始->托管->定义->定量管理->优化。 从一个级别到下一个级别的进展不一定是连续的。 但是，组织中的任何更改通常都会遇到惯性，因此这些增量更改可作为改进的指南。

翻译自: https://www.javacodegeeks.com/2015/02/continuous-integration-delivery-deployment-maturity-model.html