DevOps中持续基础效果如何

首先，我们需要确保我们对“CD”的定义是一致的。连续交付是一个工作流，其中非常频繁地进行小的更改，并集成到版本控制的主干中。从那里，一个工件要么被管道认证为符合我们的“可发布”的定义，要么被拒绝，我们立即修复它被拒绝的原因。我们总是处于一种状态，在这种状态下，我们可以发布产品的最新变化。我们做得越频繁，变更就越小，我们产生重大缺陷的风险就越小，我们就能越快地得到关于变更价值的反馈。我们为什么要这么做？这对于一个简单的网站来说很好，但是为什么要为“真正的”应用程序做呢？

安全

一个边缘情况是安全性。只有当我们将安全视为一个问题时，我们才应该担心这一点。几乎每个应用程序都有安全漏洞。唯一的问题是他们是否为人所知。当它们为人所知时，它们就是一种需要迅速缓解的风险。首先，我们需要确保每次变更都检查安全问题，而不是每年检查一次。我们的管道中需要安全质量门，我们需要定期运行该管道，以便在系统中报告新的漏洞时捕捉它们。当它们被发现时，我们需要立即修复它们。为了快速做到这一点，我们需要一种标准的方法来确保我们在应用安全补丁时没有破坏现有的行为。我们需要信心来进行修复，将它推到主干，并在几分钟内发现我们可以释放它。Log4J漏洞就是一个很好的例子。已经实施了标准化、自动化验收测试的高绩效组织在一个工作日内就解决了这个问题。

合规

另一个边缘情况是严格监管的环境。我们需要确保我们遵守审计员将检查的所有标准。我们需要在每次代码更改时都这样做，我们需要阻止不符合要求的更改。一个共同的要求是，每一个变化都有两双眼睛，以防止坏演员。我们应该在我们的管道中建立合规门来执行这一点，而不是在审计过程中发现我们有可能产生法律后果的问题。

高可用

另一个罕见的情况是需要系统24x7可用。当这些系统出现问题时，我们需要一种标准化的方法在凌晨3点半醒时修复它们，以降低使糟糕情况变得更糟的风险。在极少数情况下，我们在这样的系统上工作，我们需要改进我们交付修补程序的标准方法，将它作为向系统部署增强功能的唯一方法。通过这种方式，我们可以使用肌肉记忆和经过验证的质量门来提供修复并减少影响。

质量

另一个边缘情况是当我们在质量很重要的系统上工作时。这很令人惊讶，但是有些软件要求的质量水平超出了“拿着我的啤酒！”驱动开发。质量是一个过程，需要对质量问题的快速反馈和及时解决这些问题的能力。对于这样的系统来说，拥有全自动和快速的质量门以及向最终用户交付小变化以获得额外质量反馈的能力是非常重要的。只有在质量不重要的系统中，我们才应该使用手工测试方法和每月或每季度交付。