瀑布开发、敏捷开发、DevOps的优缺点是什么？

点击联系发帖人 时间：2022-05-17 10:33
敏捷开发是什么

  • 为什么我们需要DevOps？

  • DevOps与敏捷开发有何不同？

  • 重要的DevOps工具是什么？

  • 持续集成，持续交付是什么？

  • 基础架构即代码是什么？

与围绕软件开发的大多数流行语一样，DevOps没有公认的定义。

定义从简单（如这两个定义）到复杂（可以持续一整本书）不等。

DevOps是文化理念，实践和应用快速交付工具的组合–AWS

DevOps是组织内部的跨学科协作，旨在确保软件新版本的自动化持续交付，同时确保其正确性和可靠性 –L Leite

与其尝试定义DevOps，不如让我们了解软件开发如何演变为DevOps。

几十年前，软件开发以Waterfall模型为中心。

Waterfall模型开发，与建筑项目类似-例如，建立一座令人惊叹的桥梁。

你将分多个阶段构建软件，这些阶段可以持续几周到几个月不等。

在大多数Waterfall项目中，企业要几个月才能看到应用程序的有效版本。

构建优秀软件的关键要素

在瀑布模型中工作了几十年，我了解到了开发出色软件的一些关键要素：

软件开发是一项涉及多种技能的跨学科工作。

人与人之间的交流对于软件项目的成功至关重要。

在瀑布模型中，我们尝试通过准备有关需求，设计，体系结构和部署的详细文档来增强交流。

但是，一段时间以来，我们了解到

  • 增强团队内部沟通的最佳方法–使团队团结在一起，这样就能在同一个团队中获得各种技能。

  • 具有多种技能的跨职能团队，会使工作出色。

快速获得反馈很重要。开发出色的软件就是要获得快速反馈。

我们是否正在构建符合业务期望的应用程序？

你不能等待几个月才能获得反馈。你可能想快速了解。

如果将其部署到生产环境中，你的应用程序会出现问题吗？

我们越早发现问题，越容易解决。

我们发现，最好的软件团队通常是快速反馈。帮助我们知道是否尽早在做正确的事情。

自动化至关重要。软件开发涉及广泛的活动。手动执行操作速度很慢且容易出错。

在了解了开发出色软件的关键要素之后，让我们看看我们如何演变为敏捷开发和DevOps。

如果通过加强团队之间的沟通，获取快速反馈和引入自动化，敏捷开发是第一步。

敏捷开发将业务团队和开发团队整合为一个团队，该团队致力于以小型迭代（称为Sprints）构建出色的软件。

敏捷开发关注开发周期不是在数周或数，而是在几天甚至一天之内的小需求。

敏捷开发如何增强团队之间的沟通？

敏捷开发使业务团队和开发团队聚集在一起。

  • 业务团队负责定义构建什么内容。有什么要求？

  • 开发团队负责构建满足要求的产品。开发包括与你的软件的设计，编码，测试和打包有关的每个人。

在敏捷开发中，业务代表（通常称为产品负责人）经常出现在团队中，团队可以清楚地了解业务目标。

当开发团队对需求的理解不正确并且走错了路时，产品负责人将帮助他们进行课程更正，并保持正确的道路。

结果：团队构建的最终产品是企业想要的东西。

另一个重要因素，是敏捷开发团队具有跨职能的技能：编码技能（前端，API和数据库），测试技能和业务技能。

敏捷开发团队关注哪些自动化领域？

软件产品可能具有多种缺陷：

  • 功能缺陷意味着产品无法正常工作。

  • 技术缺陷使软件维护困难。例如，代码质量问题。

通常，敏捷开发团队专注于使用自动化来尽早发现技术和功能缺陷。

敏捷开发团队专注于自动化测试。编写出色的单元测试以测试你的方法和类。编写出色的集成测试以测试你的模块和应用程序。敏捷开发团队还广泛关注代码质量–使用诸如SONAR之类的工具来评估应用程序的代码质量。

如果你拥有出色的自动化测试和出色的代码质量检查，是否就足够了？

你可能还希望尽可能经常地运行它们。敏捷开发团队专注于持续集成。提交代码，运行单元测试，自动化测试和代码质量检查。这些都是在持续集成管道中自动执行的。在敏捷开发早期，最受欢迎的CI/CD工具是Jenkins。

敏捷开发如何促进即时反馈？

最重要的因素是，企业无需等待数月即可看到最终产品。在每次版本迭代结束时，都会将该产品演示给所有利益相关者。在优先考虑下一次版本迭代结束时，将采纳所有反馈。结果：团队构建的最终产品是企业想要的东西。

能够立即反馈的另一个重要因素是–持续集成。假设我将一些代码提交到版本控制中，在30分钟内，如果我的代码导致单元测试失败或集成测试失败，我将获得反馈。如果我的代码不符合代码质量标准或在单元测试中没有足够的代码覆盖率，我将获得反馈。

敏捷开发成功了吗？是。当然。通过专注于改善业务与开发团队之间的沟通，并着重于尽早发现各种缺陷，Agile将软件开发提升到了一个新的水平。

但是，出现了新的挑战。

现在，我们慢慢开始转向微服务架构，并且开始构建许多小型API，而不是构建大型整体应用程序。

运维变得更加重要。你每周要进行数百个小型微服务发布，而不是一个月发布一个整体。调试微服务中的问题并了解微服务中发生的事情变得很重要。

是时候在软件开发中使用新的流行语了–DevOps。

DevOps的重点是什么？

DevOps的重点是加强开发与运维团队之间的沟通。

  • 如何使运维团队更加了解开发团队做的事情？

DevOps如何增强团队之间的沟通？

DevOps使运维团队与开发团队更加接近。

  • 在更成熟的企业中，开发团队和运维团队是一个团队。他们开始共享共同的目标，并且两个团队都开始了解另一个团队面临的挑战。

DevOps团队关注的自动化领域是什么？

除了敏捷开发的重点领域（持续集成和测试自动化）外，DevOps团队还致力于帮助使运维团队自动化，例如，在服务器上配置软件，部署应用程序以及监视生产环境。一些关键术语是持续部署和基础架构即代码。

持续部署就是要在测试环境上持续部署新版本的软件。在像Google，Facebook这样的更成熟的组织中，Continuous Delivery可帮助将软件连续部署到生产中。

基础设施即代码就是将基础设施视为应用程序代码。你可以使用自动化配置方式创建基础结构（服务器，负载平衡器和数据库）。你将对基础结构进行版本控制-以便可以跟踪。

DevOps如何促进即时反馈？

DevOps将运维和开发团队召集在一起。因为运维和开发都是同一团队的一部分，所以整个团队都了解与运维和开发相关的挑战。

  • 任何运维问题都会得到开发人员的快速关注。

  • 上线软件时遇到的任何挑战，都会引起运维团队的尽早关注。

DevOps鼓励将持续集成，持续交付和基础架构作为代码。

  • 由于持续交付，如果我进行代码更改或配置更改破坏了测试或环境，那么我会在几个小时内知道。

  • 由于使用“基础结构即代码”，开发人员可以自行配置环境，部署代码并自行查找问题，而无需运维团队的任何帮助。

尽管我们说敏捷开发和DevOps是使事情变得简单的两个不同的事物，但实际上，对于DevOps的含义没有公认的定义。

我认为敏捷开发和DevOps是两个阶段，可以帮助我们改善构建出色软件。他们不会互相竞争，但是可以一起帮助我们构建出色的软件产品。

就我而言，敏捷开发和DevOps是相辅相成

  • 促进业务，开发和运维团队之间的沟通和反馈

如果你是团队中的明星开发人员，因此软件问题需要你快速解决。

你要快速创建本地环境。

你要更新单元测试和自动化测试。

你会收到一封电子邮件，指出将进行质量检查。

一些集成测试会自动运行。

你的质量检查小组会收到一封电子邮件，要求你批准。他们进行手动测试并批准。

你的代码将在几分钟内投入生产。

这就是DevOps的故事。

DevOps是软件开发的自然发展。DevOps不仅仅是工具，框架还是自动化。这是所有这些的结合。

DevOps专注于人员，流程和产品。DevOps的“人员”部分是关于文化和树立良好思维模式的，这是一种促进开放式沟通并重视快速反馈的文化，一种重视高质量软件的文化。

敏捷开发帮助弥合了业务团队与开发团队之间的鸿沟。开发团队了解业务的优先级，并与业务合作，以提供最有价值的故事为先。但是，开发团队和运维团队并没有保持一致。

开发团队的目标是将尽可能多的新功能投入生产。

Ops团队的目标是保持生产环境尽可能稳定。

如你所见，如果将产品投入生产很困难，那么开发人员和运维人员就无法保持一致。

DevOps旨在使Dev和Ops团队实现共同目标。

开发团队与运维团队合作，以了解和解决运维难题。Ops团队是Scrum团队的成员，了解开发中的功能。

我们如何才能做到这一点？

打破开发人员和行运维人员之间的隔墙！

开发人员和运维人员结合-选项1

在成熟的DevOps企业中，Dev和Ops是同一Scrum团队的一部分，彼此分担责任。

开发人员和运维人员结合选项2

但是，如果你处在DevOps演进的早期阶段，那么如何才能使Dev和Ops拥有共同的目标并一起工作呢？

  • 你可以开始做的一件事就是让开发团队分担运维团队的一些职责。例如，开发团队可以在生产部署后的第一周内负责新版本的发布。这有助于开发团队了解在发布新版本时操作所面临的挑战，并帮助他们团结起来找到更好的解决方案。

  • 你可以做的另一件事是让运维团队的代表参与Scrum活动。

  • 接下来，你可以使开发团队更清楚地看到运维团队面临的挑战。当你在运维中遇到任何挑战时，请使开发团队成为解决方案团队的一部分。

由于自动化，出现了另一个有趣的选择。通过将基础结构即代码并为开发人员启用预配置，你可以创建操作和开发团队可以理解的通用语言-代码。

此图展示了两个简单的工作流程

让我们分解一下，尝试并理解它们。

让我们从No 2开始-首先是持续部署。

如果你不经常运行测试和代码质量检查，这有什么用？

如果你没有足够频繁地部署软件，部署自动化有什么用？

开发人员将代码提交到版本控制系统后，将立即执行以下步骤：

  • 应用程序打包—构建应用程序的可部署版本。

  • 应用程序部署-启用新版本的应用程序。

  • 给测试团队的电子邮件，用于测试应用程序。

一旦获得测试团队的批准，该应用程序将立即部署到Next Environment。

这称为连续部署。如果你持续部署到生产环境，则称为持续交付。

在过去，我们创建环境并手动部署应用程序。

每次创建服务器时，都需要手动完成。

  • 如果需要更新Java版本怎么办？

  • 是否需要应用安全补丁？

基础架构即代码—像应用程序代码一样对待基础架构

这是基础架构即代码应理解的一些重要事项

  • 基础设施团队专注于增值工作（而不是例行工作）。

  • 更少的错误，可以从故障中快速恢复。

  • 服务器是一致的（避免配置漂移）。

通常，这些是IaC中的步骤

  • 通过模板配置服务器（由云启用）

使用Terraform，你可以预配置服务器和基础架构的部分，例如负载平衡器，数据库，网络配置等。你可以使用使用Packer和AMI等工具预创建镜像来创建服务器（Amazon Machine Image）。

流行的配置管理工具是Chef，Puppet，Ansible和SaltStack。这些旨在在现有服务器上安装和管理软件。

在微服务世界中，可能会使用Java构建一些微服务，使用Python构建一些微服务，以及使用JavaScript构建一些微服务。

不同的微服务将具有不同的构建和部署方式。

这使运维团队的工作变得困难。

我们如何有相同的方式来部署多种类型的应用程序？容器和Docker。

使用Docker，你可以构建微服务的镜像-不管它们的语言如何。你可以在任何基础架构上以相同方式运行这些镜像。

Kubernetes通过帮助协调不同类型的容器并将其部署到集群。

以下是一些重要的DevOps指标。

  • 部署频率-将应用程序多长时间部署到生产一次？

  • 上线时间-从编码到投入生产，你需要花多长时间？

  • 新版本的失败率-新版本多少次失败？

  • 修复的交付时间-你需要多长时间进行生产修复并将其发布到生产中？

  • 平均恢复时间-从重大问题恢复到部署生产环境需要花费多长时间？

以下是DevOps的一些最佳做法

  • 自动化，自动化，自动化。

如何衡量DevOps实施的成熟度

你如何衡量DevOps实施的成熟度？这里是一些重要的问题。

  • 每次提交都会触发自动测试和自动代码质量检查吗？

  • 你的代码是否持续交付生产？

  • 你有很多可重复使用的模块吗？

  • 开发团队可以自我配置环境吗？

  • 快速修复生产需要多长时间？

  • 自动化测试失败时，构建会失败吗？

  • 你有自动NFR测试吗？

  • 你是否具有开发和生产环境相同？

  • 你是否使用A / B测试？

  • 你是否使用金丝雀部署？

  • 只需单击一下按钮即可部署？

  • 你可以通过单击按钮来回滚吗？

  • 你能否通过单击按钮设置和释放基础结构？

  • 你是否将IAC和版本控制用于基础架构？

  • 团队是否使用集中监控系统？

  • 只需单击一个按钮，开发团队就可以访问日志吗？

  • 如果生产中出现问题，团队是否会收到警报？

  • 团队是否希望不断改进？

  • 团队是否具备业务，开发和运维所需的全部技能？

  • 团队是否跟踪关键的DevOps指标并对其进行改进？

}

设计走到今天，最流行的两种设计方法是LeanUX和AgileUX，也就是“精益UX”和“敏捷UX”。虽然两者听起来很接近，但是两种设计方法从设计过程到涉及的范围都截然不同。精益UX更接近于一种业务运营方式，而敏捷用户体验设计则接近一个项目的执行方法。来源：LeanUXvs.AgileUX—IsThereaDifference?曾经，设计师只需要将设计好的内容打包发给开发者，然后丢下一句“祝你好运”就可以潇洒地收钱走人了，可惜这样的时代已经一去不复返了。著名的网页设计师、博客写手BradFrost认为，随着屏幕和设备的碎片化，曾经的“PSD时代”已经彻底结束了，因为这种打包PSD交付的方式，属于典型的瀑布式开发流程（瀑布模型），已经无法应对当前市场的需求了。正是因为设计方法的缺失，精益设计和敏捷设计这两种方法的重要性就体现出来了。尽管两种设计方法有着不少差异，但是普遍都认为两种设计方法应该合理地结合起来。UXPin的CEOMarcinTreder曾经撰文对比过两种设计方法，仔细看下两种的差异，你会发现两种方法与其说是对抗，不如说是互补。1.敏捷UX敏捷宣言的发布让这种新的开发方法展现在大家面前，而敏捷UX则将设计师和开发者统一到敏捷开发过程中来。通常，在这个过程中大家会遵循下面的原则：·人和交互重于过程和工具·可以工作的软件重于求全而完备的文档·客户协作重于合同谈判·随时应对变化重于遵循计划目前，上面的几条规则被认为是“数字产品开发的黄金准则”。

下载百度知道APP，抢鲜体验

使用百度知道APP，立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。

}

与大数据和PRISM（NSA的监控项目之一），DevOps（开发运维）如今是科技人士挂在嘴边的热词，但遗憾的是，类似圣经，每个人都引用DevOps的只言片语，但真正理解并能执行的人极少。根据CA的一项，45%的受访者并不了解DevOps的含义，其余则有17%认为DevOps只不过是炒作。

DevOps如今几乎成了创新的同义词，但其原本的含义却在业界的流传中被人们弃之脑后。在开发者圈子中，DevOps专业人士经常是被嘲弄的对象，例如下面这个专门恶搞的推ter帐号：.

饶是如此，DevOps也成了类似数据科学家的性感职位。虽然在一些企业，DevOps还只停留在纸面上，但更多的企业的业务发展确实需要DevOps专业人才，人才市场对DevOps技术人员的需求非常旺盛，根据科技人才招聘网站Dice.com最近的，今年9月份DevOps的招聘职位数量高达500个，而去年同期只有200。

事实表明DevOps口惠而实不至的口水词，根据IT自动化服务商Puppet Labs的最新报告《》，采用DevOps的企业的软件代码生产速度是不采用DevOps企业的30倍！同时将错误率降低了50%。

为了深入探讨DevOps这个话题，以及搞清楚为什么DevOps工程师在企业招聘市场一将难求，VB的记者近日采访了戴尔的云计算开发总监， George本人也经常写博客讨论搭建DevOps团队的好处。IT经理网将采访内容编译整理如下：

问：DevOps这个概念是怎么来的？

答：DevOps起源于亚马逊和Google这样的大型互联网公司，这些公司需要员工紧密协作，同时又不希望出现部门割据。

问：开发人员和运营人员的目标有很大差异吗？

答：是的，他们有着相反的目标，开发者一心都在创新上，让事情看上去更酷；而运维人员最关心的则是网站运行的平稳，不要宕机，但开发者可不会关心这个。

我记得2001年2月份发布的“”是一个里程碑，打那时起开发者开始关心如何走近客户，了解他们的真实需求。开发者开始更多关注如何加快开发周期，写出更容易实现的代码、更好的用户体验，而不是更酷的功能。

相比之下运维人员并未经历类似太多变化，于是DevOps模式应运而生。

问：敏捷开发到底什么意思？你认为这仅仅意味着快速吗？

答：简单来说，敏捷开发意味着更多的迭代：更早更频繁地发布产品更新。先把东西做出来，而不是像过去那样过于忧虑产品是否完美。这就是那个“永远beta版”的概念，30天把原型快速搞出来，然后看看人们到底怎么想。敏捷的字面意思就是快速改变的能力。

如果你能更快发布，你就能跟上市场的节奏随时调整。

问：DevOps与开源运动的关系是怎样的？

答：两者是并行的。DevOps是一个文化运动，借用了开源的很多协作概念，本质上是团队协作的文化。

问：企业如何从DevOps能力中受益？

答：DevOps的目标是流程的自动化——让代码完成过去手工的工作，从而大大节省成本。

DevOps的最终目的是提高你的客户响应能力。如果网站宕机了，你自然就无法服务你的客户了，你发现问题的速度越快，成本就越低。

DevOps团队的特点是能让你为客户提供更多功能，而且不会把网站搞垮。

问：DevOps通常适用于大企业还是斗志昂扬的小企业？

答：DevOps更多会与大企业有关。小企业的协作本来就不是很难。但是类似Google或Netflix这样的企业每天都会推送大量代码，出现bug的几率很高，而和这样的开发工具能帮助系统管理员将很多工作自动化，并应对最艰巨的基础设施挑战。

问：你最常听到的对DevOps的误解或疑点都有哪些？

答：DevOps不仅仅适用于高科技公司，我一年前听过一个网络研讨会，是关于中西部一个金融公司如何开展DevOps的，DevOps绝不是硅谷的专属品。

事实上任何希望变得更加敏捷的人都可以运用DevOps。以我的观点，DevOps是IT部门保持其存在感的一种方法。我们经常看到企业中的IT部 门被排挤，因为预算受制于其他业务部门。有了DevOps，IT可以更早地参与到业务流程中，IT主管们可以冲着开发团队嚷嚷：“嗨，伙计们！我们如何实 现这个需求？我们需要什么样的自动化工具？”，而不是像过去那样，搞出成吨的代码后黄瓜菜都凉了。

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。 它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

以下几方面因素可能促使一个组织引入DevOps：

  1. 使用敏捷或其他软件开发过程与方法
  2. 业务负责人要求加快产品交付的速率
  3. 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
  4. 数据中心自动化技术和配置管理工具的普及
  5. 有一种观点认为，目前占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

 本文由用户 自行上传分享，仅供网友学习交流。所有权归原作者，若您的权利被侵害，请联系管理员。

 转载本站原创文章，请注明出处，并保留原始链接、图片水印。

 本站是一个以用户分享为主的开源技术平台，欢迎各类分享！

}

我要回帖

更多关于 敏捷开发是什么 的文章

更多推荐

版权声明：文章内容来源于网络，版权归原作者所有，如有侵权请点击这里与我们联系，我们将及时删除。

点击添加站长微信