开发人员总是有开发更多软件和发布软件更快的压力，这就督促开发人员要采用新的概念和工具。但是令人困惑的术语混淆了真正的技术和商业利益，特别是当一个供应商有东西可以出售时。 这使得在构建和交付的持续流程中，难以确定哪些概念最适合实际，而哪些仅仅是营销短语。本文提供了持续交付的基础知识，以帮助你解决所有相关问题。

首先，这些术语适用于同一生产弧线的不同部分，每个部分都是不同程度的自动化:

• 持续集成意味着经常将代码合并到中央存储库中。 “常常”是指通常每天多次。 每个合并触发一个自动化的“构建和测试”实例，这个过程有时称为持续构建。 但是，持续集成和持续构建，对交付或部署不产生任何作用。 他们只是针对于代码管理，而不关注代码集成后的变化。
• 持续交付是指软件发布过程的自动化，其中包括开发人员的一些手动操作。通常，由开发人员批准或启动部署，同时也有其他的手动操作步骤。
• 持续部署是不需要开发人员手动操作的持续交付。整个过程都是自动化的，它不需要人类的同意。
  
  
  

Marko Anastasov在一篇博客文章中解释道，“在持续部署中，开发人员的工作通常是在回顾队友的请求后，将其合并到主分支，由持续集成/持续部署服务接管运行所有测试并将代码部署到生产环境中，同时让团队了解每个重要事件的结果。”

然而，了解这些术语及其定义并不足以帮助你确定何时何地使用它们最好。

如果市场能清楚地区分概念和工具及其用途，就像他们使用DevOps这样的术语一样，那就太好了。

软件交付自动化公司XebiaLabs的首席营销官Gottfried Sehringer说:“DevOps是一个概念，一个想法，一个生活哲学。不是一个过程或工具集，也不是技术。”

但是，遗憾的是，行业术语很少能简洁地表达出来。也没有如何以及何时使用它们的提示。因此本指南旨在帮助你了解何时使用他们。

根据你需要的速度选择你的

但是等等!速度是所有软件开发的关键吗?现在，公司经常要求他们的开发人员每天、每周或每月更新或添加功能。这在当时是闻所未闻的，即使是在敏捷软件开发的时代也是难以想象的。

这并没有结束，仍有一些企业推动软件更新更快。塞林格说，“如果你在亚马逊工作，可能每隔几秒就会有一次更新”。

即使你是一个软件开发的高手，你如何能够在你需要快速构建和发布软件的时候，交付高质量的“不被任何破坏”的代码?每个人都有自己的灵丹妙药。“敏捷!“一个人哭道。“[持续构建](Continuous build)!”另一个喊道。“持续集成!“第三个人欢呼道。

让我们切入正题，好吗?

软件服务提供商Nexient的高级副总裁Nate Berent-Spillson表示：“将连续性视为自动化，自动化正在降低成本和开发部署的时间。”

那么，为什么人们不直接说自动化呢?

持续构建，持续交付，持续的一切，再加上自动化的概念这就是DevOps的核心，但是我们发现自己在绕圈子。接下来让我们把这些概念都整理一下。

1 - 2 - 3自动化的DevOps

持续构建意味着“一步一步地构建它”。每一小步都在将软件持续集成到产品中。

“持续集成”的标签通常用于相同的事情，尽管一些实践者有不同意见。持续构建是持续集成的一部分，在此过程中，开发人员编写代码，并与存储库中的现有代码合并，然后依靠自动化来构建和测试现已集成的代码。这使得开发人员可以花更多的时间在编写代码和创新上，而不用花时间在手动编译和测试。

但仅仅因为一些工作是自动化就认为更快是不正确的。首先，它可能还没有被部署。其次部署过程可能是手动的，或者是长期的，或者是延迟的，一直要等到忙碌的开发人员开始部署。

面向企业移动和网络应用的快速应用交付平台OutSystems的首席技术布道者Dan Juengst解释说:“随着持续集成，一个组织要从思维定势中转变，要把重量级应用程序软件开发方法升级转变为一中小型和频繁更改的软件开发手段。”

然而，持续构建更像是一个同步的步骤，而不是在更大的持续集成队列中的一个孤立的步骤。InfoZen的首席转型官苏珊·w·斯帕克斯(Susan w . Sparks)，她也是敏捷软件开发、DevOps和云迁移服务提供商的首席转型官说，“持续构建代表了持续集成的持续的签入和构建方法，而持续交付实际上是在创建一个可持续的、低风险的方法来部署应用程序代码。但前提是你的代码始终处于可部署状态，通过持续集成可以实现连续交付”。

把你的创新团队放在前面。前任雅虎首席信息官，现在是应用和代码安全即服务提供商Cybric的首席技术官Mike Kail表示：“持续整合的过程通常是DevOps开发过程的第一步， 这为开发人员创造了一个更加协调的环境，通常会提高代码质量。”

何时使用持续集成vs应用程序发布自动化

那么，这意味着持续集成和应用程序发布自动化(ARA)是同一事物的两个名称吗?不,它们是一个整体框架中的两个独立的组件。

使用持续集成的人集中于使用公共源代码库(如GitHub)的应用程序开发人员。每一次开发人员更新软件，他们的代码被重新整合到整个应用程序中。换句话说，持续集成工具检查所有的源代码，构建一切(比如编译软件)，运行所有单元测试，并即时反馈。

另一方面，ARA是对集成代码的封装，代码在开发生命周期中的自动运行。

Sparks说，“举一个例子，进行代码开发时，当所有特性都完成，所有单元测试都完成后，将使用应用程序发布自动化将该代码包移动到下一个环境，例如测试环境。”

Sehringer说，“从另一个角度看它，持续集成等于内容，应用程序发布自动化等同于工具和过程，它们是同一事物的不同侧面。”

冲洗。重复、重复、重复、重复(DevOps的自动化点)

自动化具有明显的投资回报。 Sehringer说：“你确保它在预生产中是很好的，并在不破坏任何东西的情况下立即把它推向生产，然后重复、重复、重复、反复地重复。”

换句话说，你通过一种结构化的、可重复的、自动化的方式来交付所有的步骤，以降低风险，并提高发布和更新的速度。

在一个理想的世界里，你会按下一个按钮，每隔几秒就会释放一个按钮，”Sehringer说。但这并不是一个理想的世界，所以人们会在这个过程中把这个过程连接起来。

公司需要相关法律部门的批准才能改变应用程序。Sehringer指出，“一些公司受到严格监管，可能需要额外的方法来确保合规，了解这些瓶颈在哪里是很重要的。“ARA软件可以提高效率，确保应用程序能够按时发布或更新。

他说，“开发人员更熟悉持续集成，应用程序发布自动化是最新出来的，但是不那么容易理解。”

把它包起来，用弓把它捆起来

首先，了解承诺，所涉及的内容以及您要实现的目标。

Berent-Spillson说：“持续的构建、持续的集成和和持续交付应该是最低限度的。” “持续部署是一个更大的一步。”

他补充说:“在持续部署的情况下，你将在无人参与下，部署每一种新的代码，而不是最后一次点击就能把程序全部发送出去。当新代码提交到存储库时，它将自动构建、集成、测试和分段。这里更大的变化是对主线开发的承诺。”

不同程度的自动化是区分这些概念的标准，但它们都符合更大的开发框架。总体过程如下所示：持续集成，然后持续交付或持续部署。认为连续部署是持续交付的最终结果。但在代码整合，构建和测试之前，没有什么可以部署的，这就是为什么连续集成是第一个。

专家说，把这些概念付诸实践的最佳建议是从小做起，在每一个周期内改善一些事情。努力工作，直到您不再专注于点问题，最终通过自动化形成捕获速度和安全性所必需的结构。

Berent-Spillson建议，”从持续构建开始，然后提交自动化测试，测试金字塔，并开始进行持续集成。随着持续集成更加合理，并改进自动部署，从而确保你的回滚是无缝的“。

他说，这种方法使得连续部署更容易，因为回滚变得简单得多。 “在你遭遇失败的时候，你会回过头来，然后问自己，我们能有什么自动化的、仪器化的或测试来防止这一问题的发生?”

课程的领导人

• 如果你所做的只是持续的构建和持续的集成，那么你很可能会遇到瓶颈并减慢部署过程。我们的目标是经常发布，您将需要更多的自动化来更快地发布版本。
• 在每个循环中自动化或改进某些东西，直到你最终达到完全的自动化状态。列一张清单或一张地图，这样就能使你稳步前进。
  
• 在持续集成之后，使用持续交付。只有在连续交付中解决了遵从性和治理问题之后，如果你继续进行持续部署，那么您的回滚将是无缝的。持续部署是软件发布的自动化。
  
  

原创：Pam Baker

开发人员总是有开发更多软件和发布软件更快的压力，这就督促开发人员要采用新的概念和工具。但是令人困惑的术语混淆了真正的技术和商业利益，特别是当一个供应商有东西可以出售时。 这使得在构建和交付的持续流程中，难以确定哪些概念最适合实际，而哪些仅仅是营销短语。本文提供了持续交付的基础知识，以帮助你解决所有相关问题。

首先，这些术语适用于同一生产弧线的不同部分，每个部分都是不同程度的自动化:

• 持续集成意味着经常将代码合并到中央存储库中。 “常常”是指通常每天多次。 每个合并触发一个自动化的“构建和测试”实例，这个过程有时称为持续构建。 但是，持续集成和持续构建，对交付或部署不产生任何作用。 他们只是针对于代码管理，而不关注代码集成后的变化。
• 持续交付是指软件发布过程的自动化，其中包括开发人员的一些手动操作。通常，由开发人员批准或启动部署，同时也有其他的手动操作步骤。
• 持续部署是不需要开发人员手动操作的持续交付。整个过程都是自动化的，它不需要人类的同意。
  
  
  

Marko Anastasov在一篇博客文章中解释道，“在持续部署中，开发人员的工作通常是在回顾队友的请求后，将其合并到主分支，由持续集成/持续部署服务接管运行所有测试并将代码部署到生产环境中，同时让团队了解每个重要事件的结果。”

然而，了解这些术语及其定义并不足以帮助你确定何时何地使用它们最好。

如果市场能清楚地区分概念和工具及其用途，就像他们使用DevOps这样的术语一样，那就太好了。

软件交付自动化公司XebiaLabs的首席营销官Gottfried Sehringer说:“DevOps是一个概念，一个想法，一个生活哲学。不是一个过程或工具集，也不是技术。”

但是，遗憾的是，行业术语很少能简洁地表达出来。也没有如何以及何时使用它们的提示。因此本指南旨在帮助你了解何时使用他们。

根据你需要的速度选择你的

但是等等!速度是所有软件开发的关键吗?现在，公司经常要求他们的开发人员每天、每周或每月更新或添加功能。这在当时是闻所未闻的，即使是在敏捷软件开发的时代也是难以想象的。

这并没有结束，仍有一些企业推动软件更新更快。塞林格说，“如果你在亚马逊工作，可能每隔几秒就会有一次更新”。

即使你是一个软件开发的高手，你如何能够在你需要快速构建和发布软件的时候，交付高质量的“不被任何破坏”的代码?每个人都有自己的灵丹妙药。“敏捷!“一个人哭道。“[持续构建](Continuous build)!”另一个喊道。“持续集成!“第三个人欢呼道。

让我们切入正题，好吗?

软件服务提供商Nexient的高级副总裁Nate Berent-Spillson表示：“将连续性视为自动化，自动化正在降低成本和开发部署的时间。”

那么，为什么人们不直接说自动化呢?

持续构建，持续交付，持续的一切，再加上自动化的概念这就是DevOps的核心，但是我们发现自己在绕圈子。接下来让我们把这些概念都整理一下。

1 - 2 - 3自动化的DevOps

持续构建意味着“一步一步地构建它”。每一小步都在将软件持续集成到产品中。

“持续集成”的标签通常用于相同的事情，尽管一些实践者有不同意见。持续构建是持续集成的一部分，在此过程中，开发人员编写代码，并与存储库中的现有代码合并，然后依靠自动化来构建和测试现已集成的代码。这使得开发人员可以花更多的时间在编写代码和创新上，而不用花时间在手动编译和测试。

但仅仅因为一些工作是自动化就认为更快是不正确的。首先，它可能还没有被部署。其次部署过程可能是手动的，或者是长期的，或者是延迟的，一直要等到忙碌的开发人员开始部署。

面向企业移动和网络应用的快速应用交付平台OutSystems的首席技术布道者Dan Juengst解释说:“随着持续集成，一个组织要从思维定势中转变，要把重量级应用程序软件开发方法升级转变为一中小型和频繁更改的软件开发手段。”

然而，持续构建更像是一个同步的步骤，而不是在更大的持续集成队列中的一个孤立的步骤。InfoZen的首席转型官苏珊·w·斯帕克斯(Susan w . Sparks)，她也是敏捷软件开发、DevOps和云迁移服务提供商的首席转型官说，“持续构建代表了持续集成的持续的签入和构建方法，而持续交付实际上是在创建一个可持续的、低风险的方法来部署应用程序代码。但前提是你的代码始终处于可部署状态，通过持续集成可以实现连续交付”。

把你的创新团队放在前面。前任雅虎首席信息官，现在是应用和代码安全即服务提供商Cybric的首席技术官Mike Kail表示：“持续整合的过程通常是DevOps开发过程的第一步， 这为开发人员创造了一个更加协调的环境，通常会提高代码质量。”

何时使用持续集成vs应用程序发布自动化

那么，这意味着持续集成和应用程序发布自动化(ARA)是同一事物的两个名称吗?不,它们是一个整体框架中的两个独立的组件。

使用持续集成的人集中于使用公共源代码库(如GitHub)的应用程序开发人员。每一次开发人员更新软件，他们的代码被重新整合到整个应用程序中。换句话说，持续集成工具检查所有的源代码，构建一切(比如编译软件)，运行所有单元测试，并即时反馈。

另一方面，ARA是对集成代码的封装，代码在开发生命周期中的自动运行。

Sparks说，“举一个例子，进行代码开发时，当所有特性都完成，所有单元测试都完成后，将使用应用程序发布自动化将该代码包移动到下一个环境，例如测试环境。”

Sehringer说，“从另一个角度看它，持续集成等于内容，应用程序发布自动化等同于工具和过程，它们是同一事物的不同侧面。”

冲洗。重复、重复、重复、重复(DevOps的自动化点)

自动化具有明显的投资回报。 Sehringer说：“你确保它在预生产中是很好的，并在不破坏任何东西的情况下立即把它推向生产，然后重复、重复、重复、反复地重复。”

换句话说，你通过一种结构化的、可重复的、自动化的方式来交付所有的步骤，以降低风险，并提高发布和更新的速度。

在一个理想的世界里，你会按下一个按钮，每隔几秒就会释放一个按钮，”Sehringer说。但这并不是一个理想的世界，所以人们会在这个过程中把这个过程连接起来。

公司需要相关法律部门的批准才能改变应用程序。Sehringer指出，“一些公司受到严格监管，可能需要额外的方法来确保合规，了解这些瓶颈在哪里是很重要的。“ARA软件可以提高效率，确保应用程序能够按时发布或更新。

他说，“开发人员更熟悉持续集成，应用程序发布自动化是最新出来的，但是不那么容易理解。”

把它包起来，用弓把它捆起来

首先，了解承诺，所涉及的内容以及您要实现的目标。

Berent-Spillson说：“持续的构建、持续的集成和和持续交付应该是最低限度的。” “持续部署是一个更大的一步。”

他补充说:“在持续部署的情况下，你将在无人参与下，部署每一种新的代码，而不是最后一次点击就能把程序全部发送出去。当新代码提交到存储库时，它将自动构建、集成、测试和分段。这里更大的变化是对主线开发的承诺。”

不同程度的自动化是区分这些概念的标准，但它们都符合更大的开发框架。总体过程如下所示：持续集成，然后持续交付或持续部署。认为连续部署是持续交付的最终结果。但在代码整合，构建和测试之前，没有什么可以部署的，这就是为什么连续集成是第一个。

专家说，把这些概念付诸实践的最佳建议是从小做起，在每一个周期内改善一些事情。努力工作，直到您不再专注于点问题，最终通过自动化形成捕获速度和安全性所必需的结构。

Berent-Spillson建议，”从持续构建开始，然后提交自动化测试，测试金字塔，并开始进行持续集成。随着持续集成更加合理，并改进自动部署，从而确保你的回滚是无缝的“。

他说，这种方法使得连续部署更容易，因为回滚变得简单得多。 “在你遭遇失败的时候，你会回过头来，然后问自己，我们能有什么自动化的、仪器化的或测试来防止这一问题的发生?”

课程的领导人

• 如果你所做的只是持续的构建和持续的集成，那么你很可能会遇到瓶颈并减慢部署过程。我们的目标是经常发布，您将需要更多的自动化来更快地发布版本。
• 在每个循环中自动化或改进某些东西，直到你最终达到完全的自动化状态。列一张清单或一张地图，这样就能使你稳步前进。
  
• 在持续集成之后，使用持续交付。只有在连续交付中解决了遵从性和治理问题之后，如果你继续进行持续部署，那么您的回滚将是无缝的。持续部署是软件发布的自动化。
  
  

原创：Pam Baker