Kubernetes和微服务为更小更频繁的发布打开了大门，而DevOps CI/CD实践和工具加快了软件开发和部署过程。这些云原生架构的动态特性使得现代应用程序不仅复杂，而且难以监控、发现和修复问题。由于软件交付的不同阶段有许多活动部件，因此一旦进入生产环境，就很难确保发布版按照预期运行。DevOps团队可能花费数小时试图诊断、排除故障并补救问题和风险。这种日益增长的复杂性及其创建的维护工作直接影响应用程序性能、客户体验和公司收入，使得持续验证成为现代软件交付的关键下一步。
什么是持续验证?
持续验证是一种主动实验的规程，使用验证系统行为的工具实现。它使用结果来验证应用程序始终遵循发布标准，并做出改进部署过程的决策。然而，要实现这种持续的改进，可能需要付出巨大的努力。持续验证面临的挑战是在一个不断变化的系统中识别隐藏的故障点和软件退化，而不会减慢发布速度。
持续验证实现中缺少什么?
实现持续验证是更快地部署生产就绪应用程序的下一个阶段，但目前使用现有工具实现它的方式存在差距。
监控不等于验证
随着对复杂系统属性的了解越来越多，公司正试图实现持续验证。一种常见的方法是将各种工具拼凑在一起，用于对意外模式进行调试和系统探索。这通常包括监控(Grafana, Lens, Cloudwatch, Kubernetes仪表板)，实时数据收集和查询(Prometheus)，日志记录(Coralogix, Logz, Elastic/ELK)和可观测性工具(Datadog, NewRelic)。
从理论上讲，拥有观察系统所有不同组件的多个数据源应该会给您足够的信心。在实践中，验证和批准发布仍然是手动的，耗时且容易出错。团队要对来自多个工具和数据源的数百(如果不是数千)个快速移动的事件做出反应。其中每一个都提供了工作负载在特定阶段的独立快照，并对其对整个应用程序的影响提供了有限的见解。
验证与管道隔离开来
当公司最初开始构建持续交付管道时，他们通常将持续验证视为一种扩展，而不是流程的组成部分。在顶部添加工具可以提供关于应用程序性能的潜在重要见解，但不能保证平稳或快速交付。发布元数据不是运行自动的事件驱动流程，而是在管道之外手动监视、集成和分析，以评估风险、解决故障并批准发布的升级。使用这些手动过程，通常不清楚谁拥有验证。是应用程序开发人员评估构建的风险，还是QA或测试人员针对发布版本进行实验，还是DevOps人员最终决定部署何时以及是否可以安全投入生产?
开始改进持续验证
为了控制更改后应用程序的行为，不应将持续验证视为CI/CD的手动扩展或执行外部阶段的工具集合。它应该是软件交付生命周期(“SDLC”)的一个集成部分，作为一个定义良好的过程，驱动CI/CD根据验证输出采取行动。将这些过程构建到SDLC中，可以通过在问题可以快速、容易地修复的阶段发现问题，以及在生产中感受到问题的影响之前发现问题，从而加速部署。随着我们更多地了解需要什么，我们看到了一个更清晰的画面，即良好实施的持续验证应该是什么样子。
CD进程是一个闭环。管道触发测试，结果反馈到管道中。自动执行必要的回滚操作。
将新部署与安全版本进行比较。偏离定义的、合理的性能基线会触发警报和回滚。
优化的基础设施与工作负载需求保持一致。工作负载自动获得以高性能和成本效益运行所需的基础设施。
动态验证多个微服务。对一个微服务所做的更改不会对它们所连接的其他服务产生负面影响。
机器学习提高CD过程自动化。实时和历史数据用于做出更好的决策，从而更快地发现和解决问题。
开发持续验证作为软件持续交付的关键阶段
最近公布的现在在私人预览中Ocean CD是一个完全托管的SaaS产品，为Kubernetes应用程序的大规模频繁部署过程提供端到端控制和标准化。
通过Ocean CD, Spot构建了一个以开发人员为中心的kubernetes本地解决方案，它将简化发布流程，并通过自动部署和管理提供全面的渐进式交付支持。C将持续验证作为发布过程的一个组成部分是Ocean CD的核心原则，因此您可以更快速、更有信心地进行扩展。要开始使用Ocean CD，请加入我们的私人预览。
