本帖最后由 adminlily 于 2018-9-22 11:40 编辑
开发人员总是面临着软件发布规模与速度层面的种种压力，而这亦促使其采用各类新型概念和工具。但是，令人困惑的术语混淆了真正的技术和商业利益，特别是考虑到供应商也拥有自己的倾向与诉求。如果您需要的是真正的技术手段而非营销口号，大家往往会发现自己很难为持续构建与交付的实现找到最佳方法。本文将为大家带来与持续交付相关的基础知识，希望能够为各位带来一点启示。
首先，以下术语适用于同一生产流程的不同部分，而各个部分的自动化程度皆不尽相同。
Marko Anastasov在一篇博文（[ /RpMtkJQ]RpMtkJQ[/url]）中解释称，利用持续部署，“开发人员的工作通常集中在检查同事们提交的合并请求，并在将其合并到主分支上后即宣告完成。”持续集成/持续部署服务在这里接管后续工作，包括运行一切测试案例并将代码部署到生产环境中，而后通知相关团队每一个重要事件的对应结果。
然而，仅仅了解术语和它们的定义并不能帮助大家确定应在何时、何地对其加以运用——毕竟每种技术都拥有着自己的优势与劣势。
当然，如果市场能像对待DevOps一样清楚地区分这些概念、工具及其对应受众，自然可以带来完美的成效。然而……
“DevOps是一种概念，一个想法，一类生活哲学。”软件交付自动化厂商XebiaLabs公司首席营销官Gottfried Sehringer指出。“这并非一种特定工序或者工具集，也不是一种技术。”
遗憾的是，行业里的术语很少配有简单明了的表述，也没有提示能够告诉人们如何以及何时使用这些技术。因此，这份指南旨在帮助大家了解何时适合使用哪种技术。
根据你对速度的需求来选择加速方案
等等，速度难道不是所有软件开发的关键吗？现如今，公司通常都会要求开发人员每天，每周或是每月进行软件更新或者添加新的功能。这在过去，甚至在敏捷开发时代下都是闻所未闻的严苛要求。
不止于此，一些公司还会追求更快的软件更新速度。Sehringer说：“如果你在亚马逊工作，那很可能每几秒钟就需要进行一次更新。”
不论你是软件漏洞的行家，或是开发人员又或是运维专家，当必须快速完成构建与发布任务时，大家该如何提供高质量且“不破坏任何既有成果”的代码呢？面对这样的问题，每个人都有自己的妙招。“敏捷开发”，“持续构建”和“持续集成”则是其中呼声最高的三种方案。
下面让我们对其进行概括说明。
软件服务供应商Nexient公司资深交付主管Nate Berent-Spillson指出，“你可以把持续性看成是‘自动化’。它降低了开发和部署的成本与时间。”
那为什么不直接使用自动化作为专业表达？
自动化概念的加入、持续构建、持续交付以及任何与持续性相关的因素，都属于DevOps的核心范畴，而我们其实陷入了文字表述的误区。下面，我们将带大家共同理清思路。
自动化DevOps的三要素
持续构建的本质在于“通过小步骤进行构建。”每个小的步骤都是为了把软件以持续性方式集成到生产环境中这一目标而服务。
尽管部分实践者会对“持续集成”概念作出进一步细分，但“持续集成”这一标签仍常常被指向同一类事物。持续构建属于持续集成的组成部分：在持续构建的过程中，开发者只需编写代码，并将其与仓库中现有的代码合并，之后就可以让自动化来接管构建和测试合并后的代码。这样开发者将不必浪费时间在手动编译和测试上，而是把更多时间投入到代码编写与创新实现身上。
但是，仅仅利用部分自动化工具并不意味着能够提升整个发布流程的速度表现。毕竟代码本身还没有部署完成——而部署工作可能需要手动操作，也可能因为开发人员忙不过来而被推迟。
作为OutSystems（面向企业的移动和网页应用的快速交付平台）公司的首席技术布道者，Dan Juengst解释说：“随着持续集成的运用，组织能够从以笨重的整体式应用（monolithic application）为核心的思维模式升级到一种能够支持并鼓励轻量化且高频度软件更新的方案。”
然而，在更大规模的持续集成过程中，与其说持续集成是一个独立的步骤，不如将它看成是一种并行的步骤。InfoZen公司首席转型官Susan W.Sparks说：“不同于仅仅提供了一种可持续且低风险代码部署方案的持续交付机制，持续构建在持续集成当中负责定期合并新代码并实施构建。”
正如Sparks所言：“通过持续集成，你也可以实现持续交付。”当然，前提条件是大家的代码具备可部署性。
另外，大家还需要把创新团队放在首位。前雅虎首席技术官，现任Cybic首席技术官的Mike Kail说：“将DevOps落地的第一步通常就是采用持续集成。这为开发人员提供了更加协调的环境，有利于提高代码质量。”
何时使用持续集成vs.应用程序的自动化发布
那么持续集成是否就是应用的自动化发布（ARA）——这两种称为是否代表着同一事物？答案是否定的，正如Sparks所言：“它们是同一框架下的两种不同组件。”
持续集成的运用集中体现在使用公共源代码库（如GitHub）的应用开发人员上。Sparks说，每当开发人员更新软件时，他们的代码都将被重新整合到整个应用中。换句话说，持续集成工具检查所有的源代码，构建所有成果(例如编译软件)，运行所有的单元测试，同时立即作出结果反馈。
另一方面，应用的自动化发布是指对集成后的代码进行打包，并在开发结束后将代码自动转移。
Sparks说：“举个例子，开发始于代码。当实现了所有功能并通过了所有测试之后，你就可以利用应用程序自动化发布来将代码包移动到下一个环境，例如测试环境。”
从另一个角度来看，就像Sehringer说的：“持续集成是内容，而应用的自动化发布则是运用工具的过程，二者属于同一事物的不同侧面。”
冲洗。重复、重复、重复、重复（DevOps中的自动化）
自动化机制拥有理想的投资回报。Sehringer指出：“如果在前期制作阶段能够确保产品的万无一失，那你就能立即把它推向生产而不破坏任何原有成果，之后只要重复这一过程就可以了。”
换句话说，您可以通过结构化、可重复的自动化方式来实现所有的交付步骤，从而降低风险并提高发布和更新的速度。
“在最理想的情况下，你只需按下一个按钮，就可以做到每几秒钟就进行一次发布。”Sehringer说。“但现实世界没那么理想化，还是需要人工插手来把整个流程对接起来。”
公司可能需要法务部门的批准才能对应用做修改。Sehringer指出：“一些受到严格监管的公司甚至需要额外的手段来确保合规性。因此，了解瓶颈的具体所在是很重要的。”ARA软件应该提高效率，并确保应用能够按时发布或更新。
Sehringer 还说：“开发人员对持续集成更为熟悉，而应用的自动化发布则属于较新的概念，也因此导致理解程度普遍不高。”
整合，而后加以尝试
首先，要了解你的承诺、风险在哪里以及目标是什么。
Berent-Spillson表示：“持续构建、持续集成和持续交付只能算是基本底限，持续部署才是更为深入的步骤。”
他补充称：“利用持续部署，您可以承诺在不需要人工参与的情况下来部署每一行新代码，而不再以人为方式一次性将代码发布出去。当新代码提交到存储库时，其将自动接受构建、集成、测试和暂存（stage）。其中的核心变在于对主线开发作出的承诺。”
这些概念的差异之处表现为自动化程度的区别，但它们都适用于一套更为宏观的开发框架。整个流程可以总结为：首先进行持续集成，而后是持续交付或持续部署。我们可以把持续部署看作是持续交付的升级版。但是在集成、构建和测试完成之前，不会有任何代码被实际部署——这就是为什么我们要将持续集成放在首位。
专家们对于把这些概念付诸实践的最佳建议是从小处着手，然后在每一次迭代中作出小范围改进。最终，大家将不再专注于单个问题，而是构建起一套能够通过自动化机制实现速度与安全性保障的架构。
Berent-Spillson的建议是，“从持续构建开始，然后提交给自动化测试（测试金字塔），并开始进行持续集成。随着你对持续集成的效果愈发满意，同时不断改进你的自动化部署方案，最终需要确保回滚的无缝化实现能力。”他解释称，因为回滚难度有所下降，这种方法将使得持续部署变得更容易。“在遇到错误的时候，大家可以进行回滚，然后问自己，‘我们能够如何利用自动化、感知化或测试手段来防止这一问题的发生?’”
给领导者们的经验教训
原创：马申君 译
原文链接：[ /articles/the-quickie-guide-to-continuous-delivery-in-devops-1708.html]article ... in-devops-1708.html[/url]
| 
广州-小新_QSAN
发表于 2018-9-22 22:09:07
转播
分享
淘帖
()
