DevOps 这个术语最早出现在 2009 年,由 Andrew Shafer 和 Patrick Debois 提出。DevOps 的出现是对传统 IT 实践的一种回应,特别是针对长期以来开发(Dev)与运维(Ops)之间的隔阂。这种隔阂导致了沟通不畅、协作效率低下等问题,进而影响了产品的上市时间和质量。
软件交付过程中,开发人员经常和运维人员经常会产生一些分歧,开发人员因为客户需求希望快速开发和部署,而运维人员希望不要轻易变更,避免出现问题。(小声蛐蛐:就是大家都在甩锅,都认为对方是菜鸟)
站在不同的角度看,这些考虑都没问题,但他们都意识到必须满足客户不断增长的需求,既然目标是一样的,那么接下去就是想办法解决了。
解决之道就是平衡这两个矛盾,又能快速开发,同时确保交付的质量。
如何解决呢?它们希望将软件交付过程中所有的角色整合到一起,形成一个高度自动化的工作流,所有人的目标:快速交付,满足用户需求,同时保持系统的稳定性和完整性。
当当当devops就这样诞生了!!!!
2009年Patrick Debois创建了DevOps这个词,其中的Dev不仅仅是开发人员,也包括产品、测试等角色,而Ops包括运维、运营销售等角色
千万不要认为DevOps只是一个工具,总体上来说,DevOps是实践、文化理念和工具的综合体,没有实践只会空中楼阁,没有文化则无根基,没有工具则没有支撑。
它期望提高IT组织的交付流程,速度一定要比传统开发流程快,企业能够通过反馈快速改进产品,从而取得竞争优势,从而实现业务目标。
更精炼的说,DevOps是一种思维方式,用于消除传统流程中的障碍,缩短软件开发生命周期。
当然DevOps不可能一触而就,它来源于很多前人的智慧,很多基本思想受到精益、敏捷、丰田之道等实践的启发。
其中最重要的两个前沿方法是ESM和敏捷方法。
ESM发展于2000年,出现了很多工具和小型解决方案,而最初DevOps中的践行者是运维,将很多ESM工具引入到DevOps中,比如自动配置、系统工具等。
另外一个方法就是耳熟能详的敏捷方法论,它的核心思想就是协作和沟通,强调流程和方法论。
那为什么DevOps能够脱颖而出呢?有一种说法是运维DevOps采取"自下而上"的方法(ps:也就是毛爷爷说的农村包围城市策略),它的实践更灵活,不是僵化的框架。
采用DevOps文化、工具和实践的团队能够有效协作,提高生产力,更快地交付更好的产品,并获得更高的客户满意度,从而实现业务目标,具体包括以下部分:
DevOps 促进团队的高速开发,以便您可以更快地为客户进行创新,更好地适应不断变化的市场,并在推动业务成果方面提高效率。
通过基于 CI/CD 的 DevOps 文化,缩短了应用程序发布周期,允许更快的客户反馈和有意义的创新在团队内的蓬勃发展。您可以更快地发布新功能并修复错误,更快地响应客户的需求并建立竞争优势。
DevOps 使您能够通过持续集成和持续交付等实践不断提高您的软件质量,以测试每项变更的功能和安全性。这造就了可靠和经过测试的应用程序和强大的基础设施的开发。DevOps 持续监控和记录实践可以帮助您实时了解软件的性能。
DevOps 培养了一种伟大的工作文化,在其文化模式下建立更有效的团队,强调所有权和责任等价值观。
通过采用 DevOps 模型,组织可以使用基础架即代码和策略即代码,在不牺牲安全性的情况下大规模定义和跟踪合规性。他们可以在保持控制和合规性的同时快速进步。
DevOps 没有任何固定的规则和实践,但它更像是通过来自不同部门具有不同的技能的团队在一起以实现预期的结果的文化。那么它实际上是如何工作的
开发人员,QA 和运维团队使用 CI/CD 实践来实现客户的预期目标。开发人员编写代码并将其提交到 GitHub 等源码控制工具。DevOps 工程师使用 CI 工具来提取代码,来进行自动化测试,并通过 CD 工具部署到处理生产或测试服务器。
开发和运维人员一起工作,并使用各种工具进行 CI/CD 和监控,以快速响应客户需求并修复问题和错误。
DevOps 工程师可以使用多种工具在整个 DevOps 生命周期的每个阶段获取期望的结果。
您可以使用 Jira 或 Azure DevOps Board 以敏捷方式管理和规划您的工作。
对于代码管理, Git 以分布式方式管理代码版本历史、分支、推送和拉取机制的首要工具。您还可以使用 Microsoft TFVC(Team Foundation Version Control),这是一个集中版本控制系统。
要进行自动化测试,您可以使用 Selenium 、 JUnit 和 Apache JMeter 。
Jenkins 是目前最受欢迎的 CI 工具之一,它可以做到无缝地集成开发和运维流程。
其他 CI 工具还有 Travis & Bamboo。
Docker 是最受欢迎和广泛使用的持续部署工具之一。它也是软件容器化工具。
其他部署和配置管理工具还有 Kubernetes 、 Chef 、Ansible 和 Puppet。
Kubernetes 是一个开源容器管理(编排)工具。其容器管理职责包括容器部署,容器扩展和伸缩以及容器的负载均衡。
将产品部署到正确的位置后,持续的监控就变得至关重要。 Nagios 、 Splunk 和 New Relics 是广泛使用的持续监控工具。
为了使技术驱动的公司变得更加以客户为导向,他们需要将自己从单体应用的软件开发实践转变为为客户发布产品的敏捷方式。让我们试着了解他们需要采用的最佳 DevOps实践:
下面让我带你去进入devops的世界中
DevOps 软件开发实践,开发人员定期将代码修改合并到中央存储库,然后运行自动构建和测试。持续集成通常是指软件发布过程的构建或集成阶段,并且需要自动化组件(例如,CI 或构建服务)。持续集成的目的是更快地发现和解决问题,提高软件质量,并减少验证和发布新软件更新所需的时间。
持续交付是一种软件开发实践,其中开发人员完成的任何代码更改都会自动为发布到生产环境做好准备。
通过在构建阶段之后将所有的代码更改部署到测试环境或生产环境,持续交付可在持续集成时进行扩展。
这是一种新的软件设计方法,您可以将单个应用程序拆分为一组小型服务/模块。与单体应用架构将所有前端和后端代码库以及数据库都全部部署在同一个服务器地址中相比,基于微服务架构的应用程序被分解为服务,其中每个服务器都在其中运行使用基于 HTTP 的应用程序编程接口(API),通过定义良好的接口使自己与其他服务进行通信。
微服务是围绕业务能力构建的; 每项服务的范围都是一个简单的用途。您可以使用不同的框架或编程语言来编写微服务并将它们作为单个服务或一组服务独立部署。
是通过机器可读定义文件(代码库)管理和配置计算机数据中心的过程,而不是物理硬件配置或交互式配置工具。
作为使用代码和软件开发技术(例如版本控制和持续集成)来配置和管理基础架构的实践。云服务的 API 驱动模型使开发人员和系统管理员能够以编程方式大规模地与基础架构交互,而不需要手动设置和配置资源。
因此,开发人员可以使用基于代码的工具与基础架构进行交互,使其更像应用程序。这使得可以使用标准化模式快速部署基础架构和服务器,使用最新的补丁和版本进行更新,或以副本的方式进行复制部署。
传统的服务(生命周期)自动化和配置管理工具用于完成IaC。现在企业也在使用连续配置自动化工具或独立的 IaC 框架,例如 Microsoft 的 PowerShell DSC 或 AWS CloudFormation。
公司可以通过监控指标和日志,来了解其应用程序和基础架构的运行情况。APM(Application performance management 应用程序性能管理)将 IT 指标转换为有意义的业务指标,致力于检测和诊断复杂的应用程序性能问题,以维持预期的服务等级。
通过捕获、分类、分析应用程序和基础架构生成的数据和日志,团队可以了解更新是如何影响用户的,从而深入了解问题或报错的根本原因。
wiki 中介绍:
密切监控两组性能指标。第一组性能指标定义了应用程序终端用户所体验的性能。性能的一个示例是峰值负载下的平均响应时间,包括加载和响应时间。
在我看来:
团队中的 DevOps 作为一种实践取得成功,需要2个基本支柱:沟通和协作,才能非常有效地工作。如果没有这种感觉并理解紧密结合团队工作的重要性,那么采用 DevOps 最佳实践将非常困难。
增加团队中的沟通和协作是 DevOps文化 的关键方面之一。有了这种文化,团队就会以良好的态度和动力聚集在一起,围绕信息共享建立强有力的文化规范,并通过沟通工具和应用促进沟通,使团队的所有部门能够更加紧密地协调共同的目标。
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有