【.com快言】敏捷编程是最常用的方法，它使开发团队能够将他们的软件发布到生产环境中，经常收集反馈并完善底层需求。为了使敏捷在实践中发挥作用，需要一个流程来允许自动构建修改后的应用程序并将其发布到生产环境中——通常称为持续集成/持续部署或CI/CD。CI/CD使软件团队能够通过定期吸引真实用户并迭代地合并他们的反馈来构建复杂的应用程序，而不会冒丢失初始需求的风险。数据科学面临着类似的挑战。虽然数据科学团队缺少初始需求的风险现在已不再是威胁（并且这将在未来十年内发生变化），但自动将数据科学部署到生产中所固有的挑战已使许多数据科学项目陷入停顿。首先，将任何东西放入生产系统通常需要IT参与。其次，验证通常是一项未指定的手动任务（如果存在的话）。第三，可靠地更新生产数据科学过程通常非常困难，以至于它被视为一个全新的项目。那么数据科学可以从软件开发中学到什么？让我们首先看看软件开发中CI/CD的主要方面，然后深入研究相似之处以及数据科学家需要采取不同转变的地方。软件开发中的CI/CD软件开发的可重复生产过程已经存在了一段时间，持续集成/持续部署是当今普遍使用的标准。大型软件开发通常遵循高度模块化的方法。团队处理部分代码库并独立测试这些模块（通常对这些模块使用高度自动化的测试用例）。在CI/CD的持续集成阶段，代码库的不同部分被自动插入在一起并作为一个整体再次测试。理想情况下，这种集成工作经常（因此“连续”）进行，以便可以立即发现不影响单个模块但破坏整个应用程序的副作用。在理想情况下，当我们拥有完整的测试覆盖率时，我们可以确保几乎立即发现由任何模块更改引起的问题。实际上，没有任何测试设置是完整的，完整的集成测试可能每晚只运行一次。但我们可以试着靠近一点。CI/CD的第二部分，持续部署，指的是将新构建的应用程序投入生产。每分钟更新数万个桌面应用程序几乎是不可行的（而且部署起来更复杂）。但是对于基于服务器的应用程序，随着越来越多的基于云的工具可用，我们可以更频繁地推出更改和完成更新；如果我们最终推出了损坏的东西，我们也可以快速恢复。部署的应用程序需要持续监控可能的故障，但如果测试做得好，这通常不是问题。数据科学中的CI/CD数据科学过程通常不是由不同的团队独立构建的，而是由不同的专家协作构建的：数据工程师、机器学习专家和可视化专家。值得注意的是，数据科学的创立与ML算法开发（即软件工程）无关，而是与ML算法在数据上的应用有关。算法开发和算法使用之间的这种区别经常引起混淆。数据科学中的“集成”也指将底层部分整合在一起。在数据科学中，这种集成意味着确保特定工具包的正确库与我们最终的数据科学过程捆绑在一起，并且，如果我们的数据科学创作工具允许抽象，那么这些模块的正确版本也捆绑在一起.但是，在集成阶段，软件开发和数据科学之间存在很大差异。在软件开发中，我们构建的是一个被部署的应用程序。也许在集成过程中删除了一些调试代码，但最终产品是在开发过程中构建的。在数据科学中，情况并非如此。在数据科学创建阶段，已经建立了一个复杂的过程来优化数据的组合和转换方式和内容。这个数据科学创建过程经常迭代不同类型和参数的模型，甚至可能在每次运行时以不同的方式组合其中的一些模型。集成期间发生的事情是将这些优化步骤的结果组合到数据科学生产过程中。换句话说，在开发过程中，我们生成特征并训练模型；在集成过程中，我们将优化的特征生成过程与训练模型相结合。这种整合包括生产过程。那么什么是数据科学的“持续部署”呢？如前所述，生产过程——即需要部署的集成结果——不同于数据科学创建过程。实际部署类似于软件部署。我们希望自动替换现有的应用程序或API服务，理想情况下具有所有常见的好处，例如正确的版本控制以及在生产中发现问题时回滚到以前版本的能力。数据科学生产过程的一个有趣的附加要求是需要持续监控模型性能——因为现实往往会发生变化！变更检测对数据科学过程至关重要。我们需要适当的机制来识别我们的生产过程的性能何时恶化。然后我们要么自动重新训练和重新部署模型，要么提醒我们的数据科学团队注意这个问题，这样他们就可以创建一个新的数据科学流程来重新触发数据科学CI/CD流程。因此，虽然监控软件应用程序往往不会导致自动代码更改和重新部署，但这些都是数据科学中非常典型的要求。这种自动化集成和部署如何涉及（部分）原始验证和测试设置取决于这些自动化更改的复杂性。在数据科学中，测试和监控都是流程本身不可或缺的一部分。我们不太关心测试我们的创建过程（尽管我们确实想要存档/版本化解决方案的路径），而更关心持续测试生产过程。这里的测试用例也是“输入-结果”对，但比测试用例更可能由数据点组成。这种监控差异也会影响预部署验证。在软件部署中，我们确保我们的应用程序通过测试。对于数据科学生产过程，我们可能需要测试以确保标准数据点仍被预测为同一类（例如，“好”客户继续获得高信用评级）并且仍然捕获已知异常（例如已知产品故障仍被归类为“故障”）。我们还可能希望确保我们的数据科学过程仍然拒绝处理完全无意义的模式。简而言之，我们希望确保引用典型或异常数据点或简单异常值的测试用例继续按预期进行处理。MLOps、ModelOps和XOps所有这些与MLOps、ModelOps或XOps（Gartner称之为DataOps、ModelOps和DevOps的组合）有何关系？提到这些术语的人往往会忽略两个关键事实：首先，数据预处理是生产过程的一部分（而不仅仅是进入生产的“模型”），其次，生产环境中的模型监控通常只是静态的和非富有成效的。反应性。目前，许多数据科学堆栈只解决了数据科学生命周期的一部分。不仅其他部分必须手动完成，而且在许多情况下技术之间的差距需要重新编码，因此生产数据科学过程的全自动提取几乎是不可能的。在人们意识到真正的生产数据科学不仅仅是将奇特的模型扔过墙之前，每当组织试图可靠地将数据科学作为其运营不可或缺的一部分时，我们将继续看到失败。数据科学过程还有很长的路要走，但CI/CD提供了许多可以吸取的教训。但是，用于数据科学的CI/CD与用于软件开发的CI/CD之间存在两个根本区别。首先，在集成过程中自动创建的“数据科学生产过程”与数据科学团队创建的不一样。其次，生产中的监控可以导致自动更新和重新部署。也就是说，部署周期可能会由检查生产中数据科学过程的监控过程自动触发，只有当监控检测到重大变化时，我们才会回到战壕并重新启动整个过程。【翻译稿件，合作网站转载请注明原译者和出处.com】
