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

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

是的，西门子健康需求。大家可能都知道西门子医疗是世界上生产医疗设备的领先公司之一。医疗点是西门子医疗集团旗下的一个组织单位。所以我要谈谈护理点。我们所做的。护理点是最基本的。

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

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

这是一个有趣的问题，因为当我们的业务做得很好的时候，你为什么要来做开发?有了这项新兴技术，我们的生意做得很好，一切都很顺利。随着这些新兴技术的出现，我们面临着很多竞争。所以我们必须制造复杂的设备，应该是手持设备，你可以在几小时内，如果不是几分钟内提供设备更新，只要有需要，因为你不希望设备在你取结果的时候，当你得到结果的时候出现故障。这就是原因。由于这些原因，我们现在正在开发下一代产品。hth华体会最新官方网站这些都是基于Android的产品。hth华体会最新官方网站这就是我们有CICD的地方所有的东西都映入眼帘。

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

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

所以除了现代化，你知道，需要和新兴市场一起成长。这是我们从阿特拉西安取来的东西。源代码在这里，如果你想用的话。它已经存在一段时间了。当我加入这个项目的时候，我把这个带了进来，我想，这个看起来眼熟吗?我并没有什么反应，因为我想每个人都知道这感觉很熟悉。这就是人工分娩的循环。所以我们要做的就是把所有这些痛苦的工作都自动化，这样我们就不会有这些斜坡。所以，是的，这是动力的一部分。

我们从哪里开始?我们不是在一个环境中，它是医疗的，是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电脑，我们想要证明这个概念。所以我们在一台Windows机器上安装了我们的Jenkins master，它拥有Jenkins拥有的所有东西，JVM，工作区，冲突，构建记录，所有的东西都在一台机器上，所有这些都是手动配置的，并且机器的资源有限。2022世界杯阿根廷预选赛赛程

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

这并不是一件有趣的事情，但大约一年前，也许现在更早，有一个通用版本的Jenkins配置作为代码，这是一个Jenkins的插件，这意味着你可以定义YAML文件来提供一个Jenkins主。因此，我们将旧的JenkinsStein转换为基于YAML的配置，作为代码Jenkins master，我们可以启动它并为生产做好准备，而不管启动Docker镜像需要多长时间。这很好。这是作为代码标识的配置，我们目前正在Docker Swarm上运行它，但我们最近刚刚获得了一个内部部署作为您的实例。所以我们将把事情转移到Kubernetes，现在我们有了Kubernetes引擎。我们仍然有Windows代理，他们手动维护。但是，现在我们有了Zuora，我们要看看Terraform和Packer，你知道，创建这些不可变的Windows代理，我们可以随心所欲地启动和删除，每个人都会很高兴。

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

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

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

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

所以是公共平台，所以是管理工件。所以这是另一个有趣的话题，因为，正如我们所说，我们将为西门子Healthineers医疗点开发下一代产品，但是。这个通用平台是一个基于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，我们可以把它集成到我们的詹金斯管道。现在一切都是自动化的，我们不需要手动操作。

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

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

一旦构建完成，我们就开始发布和标记。所以基本上我们将工件标记为核心资产，然后，例如，如果您将其视为核心资产X，那么我们将自动触发下游，它使用相同的工作流机制。基本上它更新源。基本上我们在这里做的是，我们也在标记来源。我们也给Artifactory打上了标签，从这个账单中生成的工件，这样我们就可以追踪到使用了哪些来源，以及使用了哪些工件，发布到Artifactory中。

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

好了，下一个话题。OSS的东西。是的，我们想信任开源代码，但我们也想验证它。我们要确保在使用它的时候，我们有正确的许可证。我把Verifa写在这里，因为我写了verify，我现在总是意外地或相反地写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设备。我们将运行一些UI测试和测试自动化的东西，并将一些结果反馈给塔服务器。所以我们整个测试实验室都有一个切入点。现在我们将它用于集成测试，开发团队编写，我们将它用于测试团队编写的验证测试。

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

是的。

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

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

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

因此，我们可以进入我们的塔服务器界面，获取我们需要的所有信息，然后调试一个问题。所以我们不应该给开发者发邮件或其他东西，告诉他们有些东西失败了。重现这个，这样我们就能修复它。相反，有些事情失败了。这是你需要的所有信息来修复它。你不需要做任何事情，除了实际修复它。但我们把这个问题留给开发团队。

我们现在正在做的是，几周前我们有一个概念验证，我们有很多不同的仪表盘，但是我们的仪表盘在仪表盘的上面。所以有办法把所有这些结果和信息收集到一个集中的地方。我们现在正在研究Mosaic，这是一个开源的框架，你必须试着把所有相关的信息带给它，并把这些信息呈现给不同的人。

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

是的，在仪表板上。

酷。未来的计划。那么我们未来的计划是什么?做你现在正在做的事。所以不要破坏任何东西。只要继续做下去，它就应该是连续的。所以在我们讨论的时候，所有东西都应该是连续的。所以我们想要连续的管道。我们想要持续交付，我们想要持续集成。所以，开始做我们所做的一切，让它持续下去。

所以，事实上，对于医疗设备，我们有一个CIL，配置项目列表，这基本上是我们需要与产品一起发货的东西。我们现在正战略性地通过这些来实现。好吧。我们能做到吗?我们能做到吗，我们能做到吗?然后把它放到管道里。所以我认为我们现在所处的是一个非常成熟的持续集成环境。现在我们正在考虑将其转向CD，在监管环境下，这是可能的。所以我们…是的，这是我们的下一个飞跃，就是到达那里。是的。 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，因为它只是在工作。它就在那里，就像在后台服务它的目的，这正是我喜欢的技术。