DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

　　它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

png

DevOps

DevOps 的文化理念

　　向 DevOps 的过渡需要文化理念和心态上的转变。简单来说，DevOps 的宗旨就是消除两个传统上孤立的团队（开发团队和运营团队）之间的壁垒。有些组织甚至没有独立的开发团队和运营团队，工程师可能身兼两职。利用 DevOps，这两个团队可以携手合作，共同提高开发人员的生产力，同时增强运营的可靠性。他们力求频繁沟通、提高效率，并改善客户服务的质量。他们能够完全掌控自己的服务，并且经常越过自己的既定角色或职能的传统工作范畴，思考最终用户的需求以及解决这些需求。质保和安全团队也可以与这两个团队紧密协作。凡是采用DevOps模式的组织，无论组织结构如何，参与团队都会将整个开发和基础设施生命周期视为己任。

落实DevOps的指导思想：“快速交付价值，灵活响应变化”。其基本原则如下：

  • 高效的协作和沟通；

  • 自动化流程和工具；

  • 快速敏捷的开发；

  • 持续交付和部署；

  • 不断学习和创新。

png

success with enterprise dev-ops - whitepaper:

png

DevOps 实践说明

　　有一些重要的实践经验能够通过自动实施和简化软件开发与基础设施管理流程，帮助组织加快创新速度。这些实践经验有大部分需要通过适当的工具来完成。

　　其中一个基本实践经验就是要频繁地进行小规模更新。这是组织能为客户快速提供创新的有效方式。与传统发布实践中偶尔的更新相比，这种更新通常更具渐进性质。频繁的小规模更新能够降低每次部署的风险。它们可以帮助团队更快速地处理错误，因为团队能够确定引发错误的最近一次部署。虽然更新的节奏和规模可能有所不同，但使用 DevOps 模式的组织与使用传统软件部署实践的组织相比，会更频繁更新。

　　此外，组织还可以使用微服务架构来提升应用程序的灵活性，从而加快创新步伐。微服务架构将大型的复杂系统拆分为简单的独立项目。应用程序被拆分为许多单个组件（服务），每个服务限定到单个目的或功能，这些服务既可以与其同级服务相互独立运行，也可以与应用程序一起作为整体运行。这种架构降低了更新应用程序的协调开销，当每个服务都与掌控各项服务的敏捷小型团队一一对应时，组织就可以实现更快的发展。

　　但是，微服务与较高的发布频率相结合会导致部署量大幅度增加，可能会带来运营挑战。因此，持续集成和持续交付等 DevOps 实践经验有助于解决这些问题，让组织能够以安全可靠的方式快速交付。与基础设施即代码和配置管理一样，基础设施自动化实践经验也有助于维持计算资源的弹性和对频繁变更的适应性。此外，进行监控和记录这一实践经验可帮助工程师追踪应用程序和基础设施的性能，以便他们快速应对出现的问题。

　　综合采用上述实践经验，可以帮助组织向客户更快交付更可靠的更新。对重要DevOps实践经验的简要介绍如下。

持续集成

　　持续集成是一种 DevOps 软件开发实践。采用持续集成时，开发人员会定期将代码变更合并到一个中央存储库中，之后系统会自动运行构建和测试操作。持续集成通常是指软件发布流程的构建或集成阶段，需要用到自动化组件（例如 CI 或构建服务）和文化组件（例如学习频繁地集成）。持续集成的主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布新软件更新所需的时间。

  • 为什么需要持续集成？

　　过去，一个团队的开发人员可能会孤立地工作很长一段时间，只有在他们的工作完成后，才会将他们的更改合并到主分支中。这使得合并代码更改变得困难而耗时，而且还会导致错误积累很长时间而得不到纠正。这些因素导致更加难以迅速向客户交付更新。

  • 持续集成的工作原理是什么？

　　采用持续集成时，开发人员可以使用诸如 Git 之类的版本控制系统，将更新频繁提交到共享存储库中。在每次提交前，开发人员可以选择在集成前对其代码执行本地单元测试，作为额外的验证层。持续集成服务在新代码更改上自动构建和运行单元测试，以立即发现任何错误。

png

　　持续集成是指软件发布流程的构建和单元测试阶段。提交的每一个修订都会触发自动化的构建和测试操作。

　　采用持续交付时，系统会自动构建、测试并准备代码变更，以便发布到生产环境中。持续交付通过在构建阶段后将所有代码变更部署到测试环境和/或生产环境中，实现对持续集成的扩展。

  • 持续集成的优势

    • 提高开发人员的工作效率
    • 更快发现并解决缺陷
    • 更快交付更新

持续交付

　　持续交付是一种 DevOp 软件开发实践。采用持续交付时，系统会自动构建、测试并准备代码变更，以便将其发布到生产环境中。持续交付通过在构建阶段后将所有代码变更部署到测试环境和/或生产环境中，实现对持续集成的扩展。当持续交付得以正确实施时，开发人员将始终能够获得一个已通过标准化测试流程的部署就绪型构建工件。

　　采用持续交付时，开发人员可以自动执行单元测试以外的测试，这样他们就可以在部署到客户环境前跨多个维度对应用程序更新进行验证。这些测试可能包括 UI 测试、负载测试、集成测试、API 可靠性测试等。这有助于开发人员更全面地验证更新并抢先发现其中的问题。借助云，开发人员可轻松高效地自动创建和复制多个用于测试的环境，而这一点以前在本地很难实现。

  • 持续交付与持续部署

　　采用持续交付时，系统会构建并测试每一个代码变更，然后将其推送到非生产测试环境或临时环境中。生产部署前可能存在多个并行测试阶段。持续交付与持续部署之间的区别在于，需要手动批准才能更新到生产环境。对于持续部署，生产会在没有明确批准的情况下自动发生。

png

　　持续交付可实现整个软件发布流程的自动化。提交的每一个修订都会触发一个自动化流程，即构建、测试并提供更新。部署到实际生产环境的最终决定由开发人员触发。

微服务

　　微服务架构是一种将单个应用程序构建为一系列小服务的设计方法。其中每个服务均按各自的流程运行，并利用一种轻型机制（通常为基于 HTTP 的应用程序编程接口 (API)）通过一个明确定义的接口与其他服务进行通信。微服务围绕着业务能力进行构建，每项服务均限定到单个目的。您可以使用不同的框架或编程语言来编写微服务，并将其作为单个服务或一组服务进行独立部署。

　　例如Docker、Amazon Elastic Container Service等。

基础设施即代码

　　基础设施即代码是一种实践经验，其中基础设施通过代码和软件部署技术（例如版本控制和持续集成）得以预置和管理。借助云的 API 驱动型模式，开发人员和系统管理员能够以编程方式与基础设施进行大规模互动，而无需手动设置和配置资源。因此，工程师可以使用基于代码的工具来连接基础设施，并且能够以处理应用程序代码的方式来处理基础设施。基础设施和服务器由代码进行定义，因此可以使用标准化模式进行快速部署、使用最新补丁和版本进行更新，或者以可重复的方式进行复制。

AWS CloudFormation 工作原理：

png

监控和日志记录

　　组织对各项指标和日志进行监控，以了解应用程序和基础设施性能如何影响其产品的最终用户体验。通过对应用程序和基础设施生成的数据进行采集、分类和分析，组织可以了解变更或更新如何影响用户，同时深入了解出现问题或意外变故的根本原因。由于服务必须全天候持续可用，而且应用程序和基础设施的更新频率不断提高，因此主动监控变得日益重要。此外，创建警报或对这些数据执行实时分析也能帮助组织更主动地监控其服务。

沟通与合作

　　增强组织内部的沟通与合作是 DevOps 文化的一个重要方面。DevOps 工具的使用和软件交付流程的自动化能够以物理方式将开发和运行的工作流程及职责结合起来，从而建立团队之间的相互协作。在此基础上，这些团队树立了强大的文化规范，提倡信息共享和通过聊天应用程序、问题或项目追踪系统以及 Wikis 来促进沟通。这有助于加快开发人员、运营团队甚至其他团队（如营销团队或销售团队）之间的沟通，从而使组织的各个部门围绕共同的目标和项目更紧密地结合在一起。

DevOps清单

下面的清单可以用来检验你的组织对DevOps的应用情况。

  • 开发团队和运维团队之间没有障碍。两者皆是DevOps统一流程的一部分。

  • 从一个团队流到另一个团队的工作都能够得到高质量的验证

  • 工作没有堆积，所有的瓶颈都已经被处理好。

  • 开发团队没有占用运维团队的时间，因为部署和维护都是处于同一个时间盒里面的。

  • 开发团队不会在周五下午5点后把代码交付进行部署，剩下运维团队周末加班加点来给他们擦屁股

  • 开发环境标准化，运维人员可以很容易將之扩展并进行部署

  • 开发团队可以找到合适的方式交付新版本，且运维团队可以轻易的进行部署。

  • 每个团队之间的通信线路都很明确

  • 所有的团队成员都有时间去为改善系统进行试验和实践

  • 常规性的引入(或者模拟)缺陷到系统中来并得到处理。每次学习到的经验都应该文档化下来并分享给相关人员。事故处理成为日常工作的一部分，且处理方式是已知的

完整DevOps的Pipeline：

png

  • 提交：工程师将代码在本地测试后，提交到版本控制系统，如 Git代码仓库中。

  • 构建：持续整合系统（如JenkinsCI），在检测到版本控制系统更新时，便自动从Git代码仓库里拉取最新的代码，进行编译、构建。

  • 单元测试：Jenkins完成编译构建后，会自动执行指定的单元测试代码。

  • 部署到测试环境：在完成单元测试后，Jenkins可以将应用程序部署到与生产环境相近的测试环境中进行测试。

  • 预生产环境测试：在预生产测试环境里，可以进行一些最后的自动化测试，例如使用Appium自动化测试工具进行测试，以及与实际情况类似的一些测试可由开发人员或客户人员手动进行测试。

  • 部署到生产环境：通过所有测试后，便可以使用灰度更新将最新的版本部署到实际生产环境里。

常用工具

  • 敏捷管理工具:Trello、Teambition、Worktile、Tower
  • 产品&质量管理：confluence、禅道、Jira、Bugzila
  • 代码仓库管理：Git、Gitlab、Github
  • 开发流程规范：Git Flow、Github Flow、Gitlab Flow
  • 自动化构建脚本：Gradle、Maven、SBT、ANT
  • 虚拟机与容器化：VMware、VirtualBox、Vagrant、Docker
  • 持续集成（CI）&持续部署（CD）：Jenkins、Hudson、Travis CI、CircleCI
  • 自动化测试：Appium、Selenium、Mock测试、消费者驱动契约测试
  • 自动化运维工具：Ansible、Puppet、Chef
  • 监控管理工具：Zabbix、ELK Stack日志分析系统、云监控（如Amazon CloudWatch）

　　DevOps是一种思维方式。所有人都是该系统流程的一部分，每个参加到这个软件交付流程上来的成员都能够加速或减缓整个系统的运作速度。系统出现的一个缺陷，以及错误配置的团队之间的“防火墙”，都可能会使得整个系统瘫痪。所有要实施DevOps的组织都应该牢记一句话：所有的人都是DevOps的一部分。

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆