在物联网医疗项目中实施现代CI - Jacob Lärfors, Ravi Sudhireddy, Verifa & Siemens Healthineers

酷。好的。所以我们要做的是我们要谈一谈护理点，西门子的护理点，他们在做什么。我也将简要介绍我的公司Verifa，然后我们将介绍几个不同的主题，关于我们在RCI管道中所做的工作。你知道，通过实际建立管道，测试，OSS合规，管理，管理结果，你知道，基本上是我们已经做过的一些主要事情，在这短短的时间里有太多的内容要涵盖。所以希望它应该是相关的。

是的，西门子健康需求。大家可能都知道西门子医疗是世界领先的医疗设备生产公司之一。护理点是西门子医疗保健的一个组织单元，Healthineers。所以我要讲一点护理点。我们做什么。注意点是最基本的。

所以对于那些不知道什么是护理点测试的人来说，护理点测试基本上是病人在床边时做的测试。举个例子，想象一下如果没有定点护理设备。那么会发生什么呢?病人的样本是由医疗接待人员和医生采集的，他们会把样本送到实验室。

实验室是用来检测结果的，如果医疗实验室不在建筑内，可能需要几天甚至几个小时。所以，医生仍然要在不知道结果的情况下照顾这些病人，因为在这段时间内，医生是不知道结果的。所以，我们已经开发了这些护理点设备，你可以把这些手持设备带到病人的床边，提取样本，然后你就可以在那里和现场得到结果。所以，这就是点关怀制造所做的。所以我们基本上是血气分析仪和尿液分析设备的领先制造商。几十年来，我们一直做得很好。我们为什么要来参加开发作业?

这是一个有趣的问题，因为当我们的业务发展良好时，你为什么还要来开发运营?因此，有了这种新兴技术，我们的生意做得很好，一切都很顺利。随着这些新兴技术的出现，我们面临着激烈的竞争。所以我们必须制造复杂的设备，应该是手持式的，你可以在几小时内更新设备，如果需要的话，因为你不希望设备在你拍摄的时候，当你得到结果的时候出现故障。这就是原因。由于这些原因，我们现在正在开发下一代产品。hth华体会最新官方网站这些都是基于Android的产品。hth华体会最新官方网站这就是我们有CICD的地方。

是的。我想，Android的有趣之处在于，现在我们想要的是，传统上他们是有产品线的，对吧?所以他们从头到尾做了一条生产线然后又从头到尾做了下一条生产线。基本上这些生产线上没有重复使用。所以现在他们已经开发了一个Android平台，基本上是手持设备，产品线将扩展它。这里有个有趣的例子，我们想要重用这个代码，确保每个人都使用最新版本。现在我们有一条产品线即将上市。但我的意思是，这将被用于很多很多的情况。是的。

酷。关于Verifa。所以我们是一个相对年轻的公司，我们专注于CICD管道和几乎所有与CICD管道相关的东西。所以我们帮助建立它们，我们帮助基础设施，我们帮助分析，我们帮助测试自动化，我们帮助OSS合规……是的，很多……基本上所有涉及到CI的东西。所以我参与了很多不同的领域，我喜欢这样做。所以如果有人想知道更多，你知道，你可以在这之后来找我。要乐于聊天。

除了现代化之外，你知道，需要与新兴市场和其他事物一起发展。这是我们从Atlassian中获得的东西。源在这里，如果你想用的话。它已经存在一段时间了。当我加入这个项目的时候我带了这个，我想，这个看起来眼熟吗?我并没有什么反应，因为我想每个人都知道这感觉很熟悉。这就是人工交付的循环。所以我们要做的就是把所有这些痛苦的活动都自动化，这样我们就不会有这些斜坡了。所以，是的，这是动力的一部分。

我们从哪里开始呢?我们不是在一个环境中，它是医疗的，是FDA的，是受监管的。所以我们并没有处在这样的环境中，我们需要快速发布。我们想做的是打造一款高质量的产品，我们更关注质量而不是速度。我知道有人说过，稳定性等于速度因为这是相关的。但它更多的是在内部构建高质量的产品，而不是能够快速频繁地向外部交付产品。所以我们就想，好吧，我们可以在我们的管道里放什么?我们就像，嗯，你知道，我们想要构建软件，对吧?我们想做一些静态代码分析。再次强调，这里的重点是质量。 So we didn’t just want to put a static analysis tool in and then say tick.

我们想，好吧，我们需要遵守编码准则。因此，我们开始寻找可以帮助编码指南的工具。在CC + +的基础上，有像Misera这样的东西他们的安全标准，比如特定的CWE。我们有自己的内部编码指南。所以我们就像，好吧，让我们把这些编码指南构建到我们的管道和静态代码分析的一部分。同样，也有安全静态分析工具。因此，发现数组缓冲区溢出和可能使您的代码或系统处于易受攻击状态的一般缺陷。现在也有相当复杂的静态分析工具。我的意思是，我们有很多静态分析工具在我们的管道中运行，我们稍后会讲到这个。

我们还想做架构分析。所以一开始我们有一个很好的软件设计，我们想要确保当我们开发我们的软件时，随着软件的发展，这个设计不只是，你知道，一个word文档或一张纸，我们有一个时间点。我们想要确保最终的系统能够真实地反映设计。而且设计是随着软件系统一起发展的。所以我们在管道里放了一个工具，它对设计所呈现的东西进行了XML定义，然后每次我们运行管道时，我们都会得到某种验证，我们的软件是否反映了我们想要制作的东西。

我们想做单元测试和突变测试。对于那些没有意识到的人来说，突变测试是当你运行完全相同的单元测试，但你翻转了位。如果你有一个正号，就把它变成负号，如果你有一个等号，就把它变成不等于号，你就把它变成大于号。运行相同的单元测试。你所期望发生的是你的单元测试会失败，对吗?

如果你的单元测试没有失败，那么你的单元测试有多好?比如在合格/不合格标准上的条件有多好?同样，一些集成测试、一些验证测试和一些性能测试。这些是非功能性需求。如果你运行一个测试，一旦它成功了。当然。但是，如果您在两周或一个月的时间内运行相同的测试呢?它还能用吗?显然，我们希望它具有工件管理，并将其绑定到管道中。我们希望在许可证和其他方面的法律方面以及安全方面都符合OSS的规定。 And, I mean, that was just the beginning lists that we had when we were like, all right, let’s build a pipeline. And that’s already a fair few things. And again, it’s not just a tool and a tick, but we really invested time and going into each of these areas and defining what it is that defines quality or what it is that defines security in each of these areas.

所以我们面临着一个挑战。我们有所有这些我们想做的事情，作为我们管道的一部分，但我们不想运行一个管道，会持续5个小时或什么的，因为，我的意思是，那真的不会帮助任何人。我们还是想要，你知道，快速的反馈。我们在Verifa提出的其中一件事，这个项目是我们首创并实施的，这就是Tx的想法，Tx基本上是开发过程中的不同时间点。我可以简单地讲一下。如果你有一个开发团队在这里，他们会创建一些功能分支或者一些他们可以工作的分支，我们有t - 0。所以这是开发生命周期中最早的阶段，在这个阶段你可以运行任何类型的测试。

所以这将是，你知道，运行代码分析和运行单元测试在开发人员桌面上作为一种初始的质量检查。一旦他们提交了他们的代码，我们就可以使用Jenkins和管道之类的东西并开始运行这些。所以他们推到的第一个分支是t - 1，在这里我们将定义一个阶段列表，我们可以作为质量闸门运行。如果质量闸门没有通过，那么，他们应该修复它。一旦成立，它们就可以合并成一个共享的积分分支我们就可以运行t - 2这样的程序，也就是更多的检查。这就像一个金字塔，从快速提供反馈到逐步提高质量和安全保障。

这是我们在项目进行了大约三个月后创造出来的，我们看到，这是一个愿景，这是我们应该达到的目标。我们真的很亲密。就像我们很亲密一样。还有一些事情要做，但我很高兴我们已经走了这么远。不管怎样，这显然不是实际的实现，我现在要讲一下这个的不同部分。

我想这里的每个人都在做CI，所以我很确定每个人都经历过这个有趣的快乐，好吧，我们想建立一个CI系统，我们想得到Jenkins。我们得到了一台Windows机器，我们想要验证这个概念。所以我们把Jenkins master放在一台Windows机器上，它拥有Jenkins拥有的所有东西，JVM、工作区、冲突、构建笔记，所有东西都在一台机器上……所有这些都是手动配置的，机器的资源有限。2022世界杯阿根廷预选赛赛程

对于那些知道Jenkins社区的人来说，这是JenkinsStein。这是一个非常常见的陷阱，你只是把所有东西都塞进Jenkins master，它只是扩展到它爆炸的点，你可能有比你实际需要的多300%的插件，因为人们只是安装它们，而不是卸载它们。所以我们遇到了这种情况，这并非意外，所以我们想，好吧，我们想把事情做得更好。所以我们有，你知道，我们是软件工程师，我们可以做伟大的事情。所以我们想要一些可扩展的东西。它不会被破坏，我们可以控制其中的变化。因此，自然的结果是在使用容器并将Jenkins配置为代码时。这样做的时机非常好，因为我过去曾在groovy脚本和配置Jenkins master中工作过。

这不是一件很有趣的事情，但是大约一年前，也许现在稍微多一点，有一个Jenkins配置代码的通用版本，这是一个Jenkins的插件，这意味着您可以定义YAML文件来提供一个Jenkins master。因此，我们将旧的JenkinsStein转换为基于YAML的配置，作为代码Jenkins master，我们可以启动它，它已经准备好生产了，无论启动Docker映像需要多长时间。这很好。这是作为代码标志的配置，我们目前正在Docker Swarm上运行这个，但我们最近才得到一个on-prem作为你的实例。所以我们将把事情转移到Kubernetes，现在我们有了Kubernetes引擎。我们仍然有Windows代理，他们手动维护。但是，现在我们有了一个Zuora，我们要看看Terraform和Packer，你知道，创建这些不可变的Windows代理，我们可以启动和关闭我们喜欢的，每个人都会高兴。

这就是我们为詹金斯建立的基础设施和配置，它产生了巨大的变化。是的。巨大的差异。它再次工作得很好，当出现问题时，我们可以恢复或检查门的历史记录。我们有进行更改的拉请求。所以，对你来说，一切都控制得很好。是的。

关于我们的管道根据这种Tx方法。所以，当我们想要平衡反馈和测试的完整性时，我们有很多不同类型的测试要做。因此，我们的解决方案是使用Jenkins管道在Jenkins文件中定义阶段，并为Jenkins文件中的阶段设置一个布尔参数。我知道有基于分支或基于标签之类的是很常见的。

但我们不想在每个项目的每个Jenkins文件中都添加大量复杂的内容。相反，我们想要有一个非常简单的，对Jenkins文件中的不同阶段做这个，是或否，而不是把逻辑放到我们的，这在Jenkins中创建管道作业。这是将Jenkins配置为代码的一个巨大好处，现在你的Jenkins master基本上就像一个管道。所以你可以把所有的公共逻辑放在那里然后你的管道就继承了它。我们做构建，做静态代码分析，做单元测试，还有一些。这有点复杂，但你懂的。当我们创建Jenkins master时，我们已经配置了这些参数。所以基本的工作流程和Docker一样，我们有一个Docker文件，里面有Jenkins YAML和我们构建的C作业，它基本上创建了一个Jenkins master，我们有环境变量，Windows注释，我们想要连接，然后是管道。

你可以在这里看到，例如，项目X DevCI有这些参数来开始代码分析。真实的。等等等等。这些指向我们的存储库，里面有Jenkins的文件，所有的东西都在那里。所以部署到Docker Swarm上，这不是火箭科学。我们只是在遵循枯燥的原则。所以我们试着把所有的逻辑放到Jenkins master和C job中。所以Jenkins文件是尽可能简单干净的。我们克服了詹金斯文件的另一个挑战，它们在不断增长，这真的很有帮助。酷。 So…

所以公共平台，所以管理工件。这是另一个有趣的话题，因为，正如我们所说，我们将为西门子健康护理点开发下一代产品，但是，这个公共平台是一个基于Android开发的公共仪器平台，来自公共仪器平台的核心资产正被不同的产品团队用于开发该产品。所以我们基本上要开发一个公共仪器平台。

所以这里的挑战是，我们必须确保这些在公共仪器平台上开发的核心资产必须分配给不同的团队。因此，我们需要了解我们需要如何管理工件，并确保我们如何标记这些工件，因为我们需要确保不同的产品团队正在使用核心资产的哪个版本。这就是挑战所在，我们发现JFrog的Artifactory帮助我们实现了这一目标。我们现在已经用Artifactory在这方面取得了很大的成功。

是的。我想如果你参考图片，我们有一个平台团队，这是几个核心资产，但实际上这可能是30到40个包，Android的AR文件。然后产品团队有应用程序，扩展这些。是的，其中一个大问题不是，你知道，我们如何把它交给产品团队，而是我们如何控制他们使用的版本，并确保，当我们测试一次平台时，我们可以再次为不同的产品线重复使用这些测试。所以我猜…

是的。如图所示，这是我们的复杂性。例如，核心资产是相互依赖的。你知道，就像我们必须确保所有的工件，例如核心资产，也依赖于所有这些其他组件，比如第三方组件，比如煎锅等等。因此，我们必须确保所有这些都存储在一个中心位置，我们应该能够获取这些信息，我们不希望在世界各地有不同的网络位置，并确保每个人都从任何地方部署。所以我们必须有一个中央存储库，这就是我们有Artifactory的地方。是的。例如，如果你看到Artifactory，就像我说的，一个核心资产依赖于另一个核心资产。

因此，就像核心资产X基本上是使用第三方组件，如Griller和NPM来编译。我们对它进行版本控制，也对它进行标签，我们将它们存储回Artifactory中。然后核心资产Y依赖于核心资产X的二进制文件，所以它需要核心资产X，核心资产X的版本级别，还有第三方，比如组件，需要Griller和NPM来编译。一旦核心资产Y被构建，它就被部署到，它被发布到Artifactory。然后我们有这个应用，它使用核心资产X和Y以及它自己的第三方其他组件来创建应用，然后我们将其存储回来。因此，这种工作流程可以使用Artifactory，我们可以将其集成到我们的Jenkins管道中。现在一切都是自动化的，我们不需要手动操作。

我想手动的观点真的值得一提，因为用于共享这些平台的方法将是将文件压缩并通过文件共享来共享，这看起来并不太疯狂。我的意思是，我很惊讶这样做的频率，但这是一个巨大的改进，因为现在我们可以，我们不需要做任何事情来发布一个新版本。它只是由管道来处理。所以…

是的。那么我们如何管理进入Artifactory的工件呢?所以这是一个基本的管道。在这个管道中，你会说，只需要获取最新版本的源代码。例如，对于核心资产X，然后你增加那个版本，然后应用这个版本。我们所做的基本上是，获取源代码，更新源代码，然后增加Artifactory上的版本。因此，我们必须确保在Artifactory中为每个核心资产定义了版本，我们必须确保它是递增的，这样我们就知道向产品团队提供了什么样的版本控制。

一旦构建完成，我们就会发布和标记。因此，基本上我们正在为核心资产标记工件，然后，例如，如果您将其视为核心资产X，就像我们将自动触发下游一样，它使用相同的工作流机制。基本上它更新源代码。基本上我们在这里所做的，就像我们也在标记来源一样。我们也标记了Artifactory，从这个法案中产生的工件，这样我们就有了一个可追溯性，什么来源正在被使用，什么工件正在被使用，正在被发布到Artifactory中。

我想，这里真正有趣的事情是，假设我们在最后构建了应用程序我们在管道中运行它，一些自动化测试失败了。我们想确切地知道使用了哪个版本的应用程序，也许代码驻留在我们的核心资产之一。所以我们想知道核心资产到底是哪个版本。我们也希望能够获得核心资产的特定版本。我们有。我们有可追溯性，从应用程序和版本一直到，你知道，与它一起发布的确切代码段，这在调试东西时很有用。

好了，下一个话题。航天局的东西。所以，是的，我们想信任开源代码，但我们也想验证它。我们希望确保当我们使用它时，我们有正确的许可。我把Verifa写在这里是因为我写verify我总是不小心写了Verifa或者反过来写了Verifa。所以我现在总是在写错别字。我在这次演讲中差点就讲到这里了，就讲到这里吧。我们所做的，这实际上是我们的营销材料，但它反映了我们所实施的。所以我就把它插进去。我们现在已经在我们的管道中建立了OSS遵从性。 So the basic workflow is that together with the build, and as part of the pipeline, we do the library identification.

所以我们现在使用Y源，这给了我们一份材料清单。所以它告诉我们我们正在使用的依赖关系的整个树，以及关于它们的许可和安全漏洞。我们使用一个叫做Software360的开源工具，它基本上是一个存储组件或第三方库的数据库，关于他们的许可证等。这是一个法律可以去的地方，他们可以对我们是否可以使用不同的许可证做出决定。我们正在将最新的材料清单与目录中已有的内容同步。所以我们得到这个，我们得到这个dif作为每次管道运行的一部分。与此同时，我们有一个许可的债务指标，这样我们就可以在任何时候看到我们需要支付多少债务来清算我们的项目。

我们的目标是在许可证和安全方面持续遵守规定。从长远来看，我们将添加更多的持续交付的东西，我们将生成有版权的OSS自述文件，以及一个清算报告和我们最终的工件二进制文件。这些就是我们为实现OSS遵从性所采取的步骤。实际上应该是第三方合规进入我们的管道。所以我们现在可以很清楚地看到我们在软件中放入了什么以及它的状态。现在的想法是，如果一个开发人员要引入一个GPR3库或其他东西，那么我们会立即标记它。所以他们不会围绕这个开始开发代码库。然后三个月后，我们就会说，嘿，你突然就得把这个撕掉，或者想办法遵守许可证的规定。

所以说自动化测试。我将快速介绍一下我们的产品，我们有医院网络，同hth华体会最新官方网站样，我们不在云端，这些医院网络可能是关闭的，不能上网。这是一个有趣的挑战。医生们将拿着安卓设备。这些Android设备与引擎相连，我们把试管、血液样本、尿液样本等等都放在引擎上。他们通过蓝牙交流。当我们在设备上进行读取时，我们将结果返回到Android设备上，我们在站点上也有一个数据库，我们可以在医院网络上有一个安全的通道来存储信息。这就是我们的客户将要使用的设置。所以，是的，我们想在我们的实验室里尽可能多地复制这个，这样我们就能尽可能近地测试它。

所以我们有一个研发网络，同样是离线的。我们在那里放了一些机器，我们连接了Android设备，我们有一个用于引擎的模拟器。我们在这里运行模拟器我们有一个用于数据库的模拟器。有了这个，我们可以在Android端模拟终端环境。我们还做了一些这样的东西，这些都是事先准备好的。我们用的是芬兰的一个工具叫做。它基本上就像一个服务器和一个客户端。这个服务器控制着客户端或者笔记。这是典型的服务器客户机体系结构。它最酷的地方在于，它了解Android设备的所有信息。

它知道它是什么手机，设备，制造商，安卓版本，操作系统，上面安装的应用程序，应用程序的版本，几乎所有的东西。所以我们有一个中央仪表盘，我们可以去那里，看到我们整个测试实验室。这很好，因为当我们运行管道时，我们只发送一个测试请求到这个服务器，它会根据一些参数，比如设备池或项目，找出在哪里运行这个，然后它会把它推到一个Android设备上。我们将运行一些UI测试和自动化测试，并将一些结果反馈给塔服务器。所以我们的整个测试实验室只有一个入口。现在我们用它来进行集成测试，由开发团队编写，我们用它来进行测试团队编写的验证测试。

我们也用它来满足非功能性需求。所以我们想要做的事情之一就是尽可能多地重用测试用例。所以我们已经建立了一个完整的测试用例的测试套件，塔的一个很好的功能是我们可以把这些测试用例，然后说，嘿，把它们按随机顺序排列，然后运行它们两个星期。因此，我们不需要创建更多的测试用例来运行非功能测试或稳定性测试。我们可以重用已经编写的测试。实际上，这也有一个连锁效应，因为这也要求您编写真正高质量的测试用例。你不像可以任意顺序运行的测试用例。所以我们几乎什么都有了。有了这个中心，所有的测试自动化问题都解决了。

是的。

是的。你讲了这么多测试，这么多测试，这么多质量。那么结果会如何呢?

是的,没错。我们产生了很多数据，很多很多的数据。我们有所有这些静态分析，我们有所有这些单元测试，我们有所有的目标测试，我们有OSS遵从性。所以我们需要让开发团队能够使用这些数据。我们使用SonarQube作为一个代码质量仪表板。我们并不经常使用SonarQube分析器。我们使用了许多不同的静态分析工具，并将它们集成到SonarQube中，这样我们就有了一个用于代码质量信息的中央存储库。这意味着一旦我们运行了所有的静态分析，我们就有了质量缺陷的真实来源。然后我们就可以把它作为质量闸门的一部分来引用，或者告诉开发团队，嘿，你引入了新东西，或者实际上你的代码质量很高。

我们也有管道，很明显，它做了所有不同类型的测试和我们所设置的所有不同的活动。这是塔的照片。这些是我们的测试结果，我们可以从这些地方得到我们想要的关于我们一夜之间运行的自动化测试的任何信息。这里有一个非常好的事情，我们也得到了侧写信息。因此，如果我们基于签入或隔夜运行我们的管道，并且测试失败，我们需要做的很明显的事情就是重现失败，试图找出哪里出了问题。我们捕捉了所有的分析信息，比如CPU使用情况、内存使用情况、电池使用情况、Android设备上的任何崩溃情况，以及Android设备上运行的所有不同服务。

所以我们可以进入我们的塔服务器接口，获得我们需要的所有信息，去调试一个问题。所以我们不应该给开发人员发邮件，告诉他们某个东西失败了。复制这个，这样我们就可以修复它。相反，有些事情失败了。这里有你需要的所有信息去修复它。你不需要做任何事情，除了实际修复它。但我们把这个问题留给了开发团队。

我们现在正在做的是，我们在几周前进行了一个概念验证，就是把一个。我们有各种不同的仪表盘，但我们的仪表盘在仪表盘上。所以有办法把所有这些结果和信息集中到一个地方。我们现在在看Mosaic，这是一个开源的框架，你必须尝试把所有相关的信息都带进去，并把这些信息呈现给不同的人。

我们关心，我们关心这个实验室。你知道这些节点什么时候下线，我们想知道。我们关心詹金斯的环境。我们要知道它什么时候下线。我们关心管道故障。开发团队，他们关心，嗯，缺陷，发现，测试，失败，你知道，他们所涉及的东西。对于管理者来说，他们关心的是……我们所参与的不同活动，代码质量指标，OSS遵从指标，测试结果的最新快照等等。所以现在我们正致力于定义我们的高级仪表板，并将我们拥有的所有这些数据，使其具有代表性和可用性，这样当人们问我们状态如何时，[相声00:00:33:06]，我们就可以指向某个地方。

是的，在仪表盘里。

酷。关于未来的计划。那么我们未来的计划是什么?做你现在在做的事。所以不要打碎任何东西。一直做下去，它应该是连续的。所以我们讨论的所有东西都应该是连续的。所以我们需要连续的管道。我们想要持续交付，我们想要持续整合。所以，是的，开始做我们所做的一切，并使之持续下去。

所以，是的，事实上，对于医疗设备，我们有一个CIL，配置项列表，这基本上是我们需要与产品一起发布的。我们现在正从战略上进行研究。好的。我们能这样做吗?我们能这样吗，我们能这样吗?然后把它放到管道里。所以我认为我们今天所处的CI是一个非常好的成熟的CI环境。现在我们正在考虑将其转向乳糜泻，在受管制的环境中，这是可能的。所以我们…对，这是我们的下一个大飞跃，就是实现目标。是的。 We have this notion of dock ops as well. I mean, everything’s ops. So doc ops is the generation of objective evidence of a test reports and stuff that we want to ship together with our products, either internally or externally.

嗯，我们必须这么做。继续学习和适应新技术，我想也可以帮助我们团队和公司的其他人尝试和采用它。所以，这就是我们所说的人工操作，当你真的想做一些很酷很伟大的事情，而其他人不同意的时候。嗯,是的。我们不都是完美的。

所以，是的，我想总结一下，我们有一个管道。我们有很多东西集成到这个管道中。我们有非常好的反馈周期，我的意思是，我们还没有过多地谈论Artifactory，但它几乎为我们所做的一切提供服务。这实际上是我们的一个主题，我们不太谈论Artifactory，因为它只是工作。它就在那里，就像在后台服务它的目的，这正是我喜欢技术做的。