DevOps 概览：第一部分

【注】本文节译自：https://intellipaat.com/blog/tutorial/devops-tutorial/DevOps 到底是什么？

  不要“ DevOps”这个术语吓倒。它只是使“开发人员”和“运营”团队一起工作的实践或方法。

  那么，这究竟是如何实现的？我们在后面会进行讨论。

为什么要 DevOps？

  在理解 DevOps 的概念和方法之前，我们需要了解为什么需要 DevOps？

  为什么选择 DevOps？而不使用其他方法？

  在 DevOps 出现之前，瀑布模型是用于软件开发的最早的 SDLC（软件开发生命周期） 方法。首先，该方法用于按顺序说明 SDLC，因此被认为是可靠的。

瀑布方法的工作流程

  设想一下，如果我们正在使用瀑布方法开发软件，那么要包含下面的步骤：

可行性检查：可行性阶段用于确定某种特定的方法/技术在开发软件是否足够可行。

需求分析：在此阶段，我们需要从客户的角度分析所有系统和软件需求，并收集有关这些需求的信息。然后，将需求记录在软件需求规范（SRS）文档中，以避免产品的不完整性。

设计：此阶段的目标是将 SRS 文档中列出的需求转换为适合于编程实现的有序结构。

编码和单元测试：将前一阶段中创建的设计在此阶段转换为源代码，然后对每个设计模块进行编码和检查。

集成和系统测试：在完成各模块的设计编码后，对这些模块进行适当的集成。然后，对这些集成的模块分别进行测试。此后，执行验收测试，将产品交付给客户，由客户进行测试，以确定是否接受或拒绝该产品。

软件维护：维护是软件开发生命周期的一个阶段，其中花费了全部工作的60％。在此阶段中会执行几种维护操作，例如纠正维护、完善维护和自适应性维护，其中会完成纠错和功能增强，并在新的环境和操作系统上尝试软件。

  现在，让我们讨论该模型的优缺点。

优点

--- 这种方法简单易用

--- 成熟耐用、易于管理

--- 每个阶段都有审查过程，因此不容易出错

--- 一个一个的处理阶段不会相互重叠

--- 适用于小型项目

缺点

--- 当应用处于测试阶段时，由于沟通不畅或缺乏知识，很难对先前步骤中发生的任何问题进行更改

--- 由于难以诊断和提供反馈，因此这是一个冒险的过程

--- 它的主要重点是帮助内部团队有效地工作。它不包括最终用户/客户，因此大多数人不信任此方法。

--- 测试过程会有所延迟，因为此方法要求团队一直等到过程达到第 4 或第 6 阶段

  由于所有这些缺点，组织希望使用一种高效的模型来执行 SDLC。因此出现了改变这种情况的敏捷方法。

敏捷软件开发

  敏捷包括一种增量方法，类似于瀑布模型，但是具有迭代的观点，同时关注客户反馈、合并小的快速变更、快速发布。它基本上将产品分解成更小的部分，最后将它们集成到测试过程中。

  现在，让我们看一下它的优缺点。

优点

--- 敏捷方法论在整个项目中都会考虑客户的反馈，这就给了团队足够的时间进行决策

--- 它欢迎进行变更，但代价巨大

--- 它具有扩展能力

--- 不断关注卓越的技术和良好的设计

--- 此方法对最有价值特性进行优先级排序和调度，从而降低资源不可用的风险

--- 小而精的团队有高度的参与和协调

缺点

--- 在敏捷中可预测性较低

--- 每个利益相关者都需要更多的时间和投入。 测试人员、开发人员和客户必须经常相互交流，并且应该彼此同意才能完成任务，因此敏捷非常耗时

--- 有限的文档通常会带来问题。在回退的情况下，很少有详细的文档，以便交叉检查

--- 敏捷模型在开始时需要最少的计划，这使得更容易快速地开发项目，但是没有一个有限的结束 。由于意想不到的功能，无法获得清晰的项目愿景，而且大多数涉众不确定他们最终的产品是什么样子的

   简而言之，当瀑布模型无法提供结果一致性时，敏捷方法就应用而生了。但是，如上所述，敏捷模型也有许多缺点：

--- 在瀑布模型的情况下，客户的软件需求与开发人员之间存在差距，敏捷解决了这一问题

    客户与开发人员之间的差距

--- 在敏捷方法的情况下，开发人员和运营人员之间仍然存在差距

运营团队与开发人员之间的差距

您认为如何克服？

  在这种情况下，引入DevOps是为了克服开发人员和运营团队之间的差距。

  现在，让我们检查一下敏捷和 DevOps 之间的主要区别。

敏捷与 DevOps 之间的差异