在本文中，我们将学习关于DevOps以及它与敏捷方法论的不同之处。我们还将介绍一些流行的DevOps工具及其在DevOps生命周期中的角色。
你将学习到
- 什么是Docker、Kubernetes和Azure DevOps
- 什么是DevOps以及我们为什么需要它？
- DevOps与敏捷有什么不同？
- 一些重要的DevOps工具有哪些？
- Docker如何帮助DevOps？
- Kubernetes如何帮助DevOps？
- Azure DevOps如何帮助DevOps？
- 什么是持续集成和持续交付（CI/CD）？
- 什么是基础设施即代码？
- Terraform和Ansible如何帮助DevOps？
Docker
Docker是一个开源软件工具，用于构建、测试和部署容器化应用程序。顺便问一下，什么是容器化？容器化是将所有库和文件与应用程序代码打包在一个称为“容器”的单一单元中的概念，以便它可以在任何基础设施上运行。
Kubernetes
Kubernetes是一个容器编排系统，用于管理容器化的应用程序和服务。它负责在容器化环境中执行的任务，如扩展、部署、负载平衡等。Kubernetes具有便携性、高效性和经济性，并提供诸如系统集成、基于API的支持等功能。
Azure DevOps是微软的产品，提供各种工具和功能，使软件开发和部署过程更快速、更有组织性。它提供一套流程，允许软件开发人员、项目经理和其他贡献者共同开发软件。它可以添加到现有的编辑器或集成开发环境中，使团队能够高效地处理各种规模的项目。
让我们从一个简单的用例开始。
免费课程 — 以10个步骤学习
什么是DevOps？
与软件开发周围的大多数时髦词汇一样，对于DevOps并没有公认的定义。
定义可能简单，比如下面这个，也可能复杂，长达一整页书。
DevOps是文化哲学、实践和工具的结合，可以增加组织以高速度交付应用程序和服务的能力 — 亚马逊云服务（AWS）不要试图定义DevOps，让我们来了解软件开发是如何演变成DevOps的。
瀑布模型
瀑布模型是一种遵循结构化方法的方法论。它包括六个阶段：需求、设计、实施、测试、部署和维护。每个阶段都建立在前一个阶段的完成基础上。它在不重返早期过程的情况下通过这些阶段，使其成为一个线性过程。
软件开发的最初几十年以瀑布模型为中心，并且它以与构建房地产项目相同的方式对待软件开发 — 例如，建造一座桥梁。
您将会在多个阶段构建软件，这些阶段可能需要几周甚至几个月。
在大多数瀑布项目中，企业看到一个可工作版本的应用程序可能需要数月的时间。
构建优秀软件的关键元素
在瀑布模型工作了几十年后，我们理解了几个开发优秀软件的关键要素：
- 沟通
- 反馈
- 自动化
沟通的重要性
人与人之间的沟通对软件项目的成功至关重要。
在瀑布模型中，我们试图通过准备1000页的需求、设计、架构和部署文档来增强沟通。
但是，随着时间的推移，我们发现：
- 增强团队内部沟通的最佳方法是将他们聚集在一起，并在同一个团队中拥有多种技能。
- 跨职能团队——拥有广泛技能的团队——效果显著。
早期反馈的重要性
快速获取反馈非常重要。构建优秀软件的关键在于快速反馈。
- 我们构建的应用程序是否符合业务期望？
- 如果应用程序部署到生产环境，会不会出现问题？
你不想等几个月后才知道。你希望尽早发现，因为我们越早发现问题，解决问题就越容易。
我们发现，最优秀的软件团队的结构有利于快速反馈。
自动化的重要性
自动化至关重要。软件开发涉及广泛的活动。手动操作既慢又容易出错。我们明白，始终寻找引入自动化的机会是至关重要的。
了解了开发优秀软件的关键要素后，让我们看看我们是如何发展到敏捷和DevOps的。
发展到敏捷
敏捷是一种强调增量进展、频繁反馈以及能够通过开发生命周期响应变化需求的方法。敏捷推动跨职能团队在短期开发周期内工作，促进持续改进并快速向最终用户交付价值。这是朝着加强团队之间的沟通、获取反馈并引入自动化的学习实施的第一步。
敏捷将业务和开发团队融合成一个团队，共同致力于通过名为“冲刺”的小迭代构建优秀软件。
与花费数周甚至数月在开发的每个阶段上不同，敏捷专注于在几天内、有时甚至同一天内将称为用户故事的小需求通过开发周期。
敏捷如何增强团队之间的沟通？
敏捷将业务和开发团队融合在一起。
- 业务负责定义要构建的内容。需求是什么？
- 开发负责构建符合需求的产品。开发包括设计、编码、测试和打包软件的所有参与者。
在敏捷开发中，来自业务的代表，称为产品负责人，始终与团队在一起，团队清楚地了解业务目标。
当开发团队不了解需求并走错了方向时，产品负责人帮助他们进行调整并保持正确的方向。
结果：团队构建的最终产品符合业务需求。
另一个重要因素是敏捷团队具有跨职能技能：编码技能（前端、API 和数据库）、测试技能和业务技能。这增强了需要共同合作构建优秀软件的人员之间的沟通。
敏捷和自动化
敏捷团队关注哪些自动化领域？
软件产品可能存在各种缺陷：
- 功能缺陷意味着产品无法按预期工作。
- 技术缺陷使软件维护变得困难。例如，代码质量问题。
总的来说，敏捷团队致力于尽早使用自动化来发现技术和功能缺陷。
敏捷团队还广泛关注代码质量。工具如SONAR用于评估应用程序的代码质量。
如果您拥有出色的自动化测试和优秀的代码质量检查，这就足够了吗？关键在于频繁运行这些流程。敏捷团队强调持续集成，即对版本控制的提交触发一系列操作。这包括运行单元测试、自动化测试和代码质量检查，所有这些都无缝集成到持续集成管道中。Jenkins，在早期敏捷时代被广泛采用的CI/CD工具，在编排这些自动化流程中发挥了关键作用。
敏捷如何促进即时反馈？
最重要的因素是企业不需要等待几个月才能看到最终产品。每个迭代结束时，产品都会向包括架构和业务团队在内的所有利益相关者进行演示。所有反馈都会被接受，同时对下一个迭代的用户故事进行优先排序。结果：团队构建的最终产品是业务想要的东西。
促使即时反馈的另一个重要因素是持续集成。比如我提交了一些代码到版本控制中。在30分钟内，如果我的代码导致单元测试失败或集成测试失败，我就会收到反馈。如果我的代码不符合代码质量标准或单元测试中的代码覆盖率不足，我也会收到反馈。
敏捷成功了吗？是的。毫无疑问。通过专注于改善业务和开发团队之间的沟通，并专注于早期发现各种缺陷，敏捷将软件开发推向了一个新水平。
我与一些了不起的团队使用敏捷方法工作的经历非常美好。软件工程对我来说代表着从需求到将应用程序首次上线的所有努力，这与编程一样令人愉快。
但演变会停止吗？不会。
新的挑战出现了。
微服务架构的演变
我们开始朝着微服务架构迈进，开始构建几个小型API，而不是构建大型单体应用程序。
新的挑战是什么？
运维变得更加重要。你不再每月发布一个单体版本，而是每周发布数百个小型微服务版本。在微服务之间调试问题并获取微服务的运行情况变得至关重要。
是时候在软件开发中引入一个新的流行词了。DevOps。
DevOps的出现
DevOps的重点是什么？
DevOps的重点是增强开发团队与运维团队之间的沟通。
- 我们如何使部署变得更简单？
- 我们如何使运维团队的工作对开发团队更具可见性？
DevOps如何增强团队之间的沟通？
DevOps使运维团队更接近开发团队。
- 在更成熟的企业中，开发和运维团队合作作为一个团队。他们开始分享共同的目标，两个团队都开始理解对方面临的挑战。
- 在企业中，处于DevOps演进的早期阶段，运维团队的代表可以参与冲刺——站会和回顾会议。
DevOps团队关注哪些自动化领域？
除了敏捷的关注领域——持续集成和测试自动化——DevOps团队还专注于帮助自动化一些运维团队的活动，如服务器的配置、服务器上软件的配置、应用程序部署以及生产环境的监控。一些关键术语包括持续部署、持续交付和基础设施即代码。
持续部署是指在测试环境上持续部署新版本软件。在像谷歌和Facebook这样更成熟的组织中，持续交付有助于持续将软件部署到生产环境——也许每天进行数百次生产部署。
基础设施即代码是指将基础设施视为应用程序代码一样对待。您可以使用配置以自动化方式创建您的基础设施——服务器、负载均衡器和数据库。您会对基础设施进行版本控制——以便跟踪一段时间内的基础设施更改。
DevOps如何促进即时反馈？
DevOps 将运营和开发团队聚集在一起。因为运营和开发是同一个团队的一部分，整个团队都了解与运营和开发相关的挑战。
- 开发人员会迅速关注任何运营问题。
- 将软件上线的挑战会得到运营团队的早期关注。
DevOps 鼓励持续集成、持续交付和基础架构即代码。
- 由于持续交付，如果我进行代码更改或配置更改可能会影响测试或分级环境，我会在几小时内得知。
- 由于基础架构即代码，开发人员可以自助配置环境、部署代码并自行解决问题，无需运营团队的帮助。
我认为敏捷和 DevOps 是两个阶段，帮助我们改善构建优秀软件的方式。它们不是相互竞争，而是共同帮助我们构建出色的软件产品。
就我而言，敏捷和 DevOps 共同的目标是：
- 促进业务、开发和运营团队之间的沟通和反馈
- 通过自动化减轻痛点。
一个 DevOps 故事
以下是一个示例故事：
- 你是一个团队中的明星开发人员，需要快速修复。
- 你进入 GitHub 仓库。
- 你迅速检出项目。
- 你迅速创建本地环境。
- 你做了一个更改。你进行了测试。你更新了单元和自动化测试。
- 你提交了它。
- 你收到一封邮件，告知它已部署到QA环境。
- 一些集成测试会自动运行。
- 你的QA团队收到一封请求批准的邮件。他们进行了手动测试并批准。
- 几分钟后，你的代码在生产环境中上线。
- 你可能会认为这是一个理想的场景。但是，你知道这就是像Netflix、亚马逊和谷歌这样的创新企业每天发生的事情吗？
这就是DevOps的故事。
DevOps = 开发 + 运营
DevOps是软件开发的自然演进。DevOps不仅仅是一个工具、一个框架或仅仅是自动化。它是这些的结合。
DevOps关注的是人、流程和产品。DevOps的人部分全是关于文化和创建良好心态——一种促进开放沟通和重视快速反馈的文化，一种重视高质量软件的文化。
敏捷方法帮助弥合了业务与开发团队之间的差距。开发团队理解业务的优先级，并与业务合作，首先交付提供最大价值的故事；然而，开发和运营团队并未对齐。
他们有不同的目标。
- 开发团队的目标是尽可能多地将新功能推向生产环境。
- 运维团队的目标是尽可能保持生产环境的稳定。
正如你所看到的，如果将事物推向生产是困难的，开发和运维就不协调。
DevOps的目标是通过共享目标来使开发和运维团队保持一致。
开发团队与运维团队合作，了解和解决运营挑战。运维团队是Scrum团队的一部分，了解正在开发中的功能。
我们如何做到这一点呢？打破开发和运维之间的壁垒！
让开发和运维团队团结一致
选项1
在成熟的DevOps企业中，开发和运维作为同一Scrum团队的一部分共同工作并分享彼此的责任。
选项2
然而，如果你处于DevOps演变的早期阶段，如何让开发和运维拥有共同目标并共同工作呢？
以下是你可以采取的一些措施：
- 让开发团队分享部分运维团队的责任。例如，开发团队可以在生产部署后的第一个星期负责新版本的发布。这有助于开发团队了解运维在推出新版本时面临的挑战，并帮助他们共同寻找更好的解决方案。
- 另一件你可以做的事是让运维团队的代表参与Scrum活动。让他们参与每日站会和回顾会议。
- 接下来你可以做的一件事是让运营团队面临的挑战更加明显地展现给开发团队。当你在运营中遇到任何挑战时，将开发团队纳入解决方案工作团队之中。
无论采取何种方式，都要找到打破隔阂、让开发和运营团队走到一起的方法。
另一个有趣的选择是因为自动化而出现。通过使用基础设施即代码并为开发人员启用自助服务，你可以创造一个运营和开发团队都理解的共同语言 — 代码。
一个DevOps应用案例
考虑下面的图片：
这幅图片展示了两个简单的工作流程
- 使用Terraform和Azure DevOps对Kubernetes集群进行基础设施即代码部署。
- 使用Azure DevOps对微服务进行持续部署，构建和部署微服务的Docker镜像到Kubernetes集群中。
听起来复杂吗？
让我们分解并尝试理解它们。
我们从第2项开始 —— 首先是持续部署。
#2：使用Azure DevOps和Jenkins进行DevOps持续部署
如果你不经常运行优秀的测试和代码质量检查，那有什么用呢？
如果你不经常部署软件，部署自动化有什么用呢？
当开发人员将代码提交到版本控制系统时，将执行以下步骤：
- 单元测试
- 代码质量检查
- 集成测试
- 应用程序打包 — 创建可部署版本的应用程序。工具 — Maven，Gradle，Docker
- 应用程序部署 — 将新应用程序或新版本的应用程序投入使用
- 发送电子邮件给测试团队测试应用程序
一旦测试团队批准，应用程序立即部署到下一个环境。
这被称为持续部署。如果您持续部署到生产环境，则称为持续交付。
最受欢迎的CI/CD工具是Azure DevOps和Jenkins。
#1：使用Terraform进行DevOps基础设施即代码
很久以前，我们习惯手动创建环境和部署应用程序。
每次创建服务器都需要手动操作。
- 软件版本需要手动更新
- 需要手动安装安全补丁
您手动操作，以下是结果：
- 出错几率较高
- 复制环境困难
基础设施即代码
基础设施即代码 — 将基础设施与应用程序代码同等对待。
以下是一些重要的基础设施即代码理解要点：
- 基础设施团队专注于增值工作（而不是例行工作）
- 减少错误，快速从故障中恢复
- 服务器保持一致（避免配置漂移）
最受欢迎的IaC工具是Ansible和Terraform。
通常IaC的步骤如下：
- 从模板中通过云服务提供服务器
- 安装软件
- 配置软件
服务器配置
通常会使用配置工具来提供服务器并准备好具有网络功能的新服务器。最流行的配置工具是Cloud Formation和Terraform。
使用Terraform，您可以提供服务器和其他基础设施，如负载均衡器、数据库、网络配置等。您可以使用Packer和AMI（Amazon Machine Image）等工具创建预先创建的镜像创建服务器。
配置管理
配置管理工具用于：
- 安装软件
- 配置软件
流行的配置管理工具包括Chef、Puppet、Ansible和SaltStack。这些工具旨在在现有服务器上安装和管理软件。
Docker和Kubernetes在DevOps中的作用
在微服务世界中，有些微服务可能是用Java构建的，有些是用Python构建的，有些是用JavaScript构建的。
不同的微服务将有不同的构建应用程序和部署到服务器的方式。这使得运维团队的工作变得困难。我们如何以类似的方式部署多种类型的应用程序？容器和Docker登场。
使用Docker，您可以构建微服务的镜像 — 无论它们的语言如何。您可以在任何基础设施上以相同的方式运行这些镜像。这简化了运维工作。
Kubernetes通过帮助编排不同类型的容器并将它们部署到集群中来扩展这一功能。
Kubernetes还提供：
- 服务发现
- 负载均衡
- 集中配置
Docker和Kubernetes使DevOps变得简单。
重要的DevOps指标
以下是一些重要的DevOps指标，您可以跟踪并随着时间的推移进行改进。
- 部署频率 — 应用程序被部署到生产环境的频率是多少？
- 上线时间 — 从编码到生产发布一个功能需要多长时间？
- 新版本失败率 — 您的发布中有多少是失败的？
- 修复交付时间 — 修复生产问题和将其发布到生产环境需要多长时间？
- 平均恢复时间 — 从重大问题中恢复生产环境需要多长时间？
DevOps最佳实践
敏捷项目管理
敏捷项目管理是一种迭代开发软件应用的方法。通过这种实践，团队可以提高开发速度，并对不同的客户需求做出良好响应。敏捷方法不同于传统的瀑布方法，传统方法中存在着长周期的发布。敏捷使用Scrum和Kanban框架根据客户需求交付软件。
使用正确的工具
软件开发人员和系统管理员需要在DevOps生命周期的每个阶段选择并使用正确的一组DevOps工具来构建高价值的应用程序。
以下是一些例子，DevOps工程师、系统管理员和其他利益相关者可以使用的工具：
- 像Jira这样的工具可以帮助团队将任务分解为更小更易管理的部分，从而提高团队的生产力。
- 像Jenkins和Bitbucket这样的工具可以帮助您自动化从测试到部署阶段的代码流程。
- 像Slack、GetFeedback等工具可以帮助DevOps团队将聊天工具与调查平台集成，以收集和审查实时反馈。
持续集成/持续交付
持续集成（CI）和持续交付（CD）是帮助组织快速有效地交付软件的现代软件开发实践。通过CI，开发人员持续将应用程序代码提交到共享存储库多次。有了CD，代码可以快速无缝地交付到生产环境。CD还确保集成过程不会出现延迟或故障。
集成安全
安全是软件开发过程中的一个重要部分。在当今这个网络犯罪和数据泄露事件日益增加的世界里，组织越来越意识到将安全性集成到其系统中的重要性。在过去，安全性通常是在软件开发生命周期的最后阶段考虑的，但随着DevSecOps的出现，安全性从应用开发的第一天起就被考虑和集成。
可观察性
可观察性在开发使用微服务和云架构的复杂应用时非常重要。可观察性帮助DevOps团队理解不同应用（微服务、云应用等）的复杂结构，并有助于满足环境未来的需求。Kubernetes可观察性和Splunk是一些最佳的可观察性平台。
DevOps成熟度信号
如何衡量您的DevOps实施的成熟度？
- 从开发过程到部署所需的时间应该总体令人满意
- 确定新代码部署的频率
- 从事件或意外事件中恢复的平均时间（MTTR）应尽可能短
- 成功的部署应该超过失败的部署
- 更快、更可靠的发布应该带来高投资回报率（ROI）。
DevOps转型最佳实践
- 领导层的支持至关重要
- 需要前期成本
- 设立中心运营团队来帮助团队
- 选择合适的应用和团队
- 从小处着手
- 分享经验（新闻通讯、沟通、中心运营团队）
- 鼓励具有探索和自动化思维的人
- 认可DevOps团队
Source:
https://dzone.com/articles/devops-tutorial-devops-with-docker-kubernetes-and