在当今由物联网(IOT)驱动的互连嵌入式设备市场中，大多数开发中的设备都基于某种形式的Linux。带有现成Linux发行版的低成本主板的普遍存在是这方面的一个关键驱动因素。获取硬件、构建自定义代码、将设备连接到其他硬件外围设备和互联网，以及使用商业云提供商进行设备管理从未如此简单。开发人员或开发团队可以快速制作新应用程序的原型并将设备交付给潜在用户。这是一件好事，会产生许多有趣的新应用，但也会产生许多糟糕的应用。在原型设计阶段之后规划系统设计时，事情会变得更加复杂。本文重点介绍开发和维护基本操作系统(OS)映像的机制。有许多工具可以对此提供帮助，但这里不讨论各种工具。这里感兴趣的是维持和增强这种形象的潜在模式，以及它将如何使人们的生活变得更好或更糟。生成这些镜像有两种主要模型：集中式GoldenMaster分布式构建系统这些类别反映了源代码管理(SCM)系统的驱动模型，在讨论操作系统镜像时，许多关于集中式和分布式的论点都是适用的。集中式GoldenMaster爱好者和创客项目主要使用集中式GoldenMaster方法来创建和维护应用程序映像。这一事实为该模型提供了速度和熟悉度方面的优势，使开发人员能够快速设置这样的系统并使其运行。这种速度来自于许多设备制造商为其现成硬件提供固定图像这一事实。例如，BeagleBone和RaspberryPi等系列的主板提供随时可用的操作系统映像和闪存。依靠这些图像意味着只需点击几下鼠标即可启动并运行您的系统。这些映像通常基于许多设备开发人员已经使用的桌面发行版，例如Debian。多年使用Linux的经验可以直接转移到嵌入式设计中，包括封装实用程序基本保持不变这一事实，而且设计人员很容易获得他们需要的额外封装。这种方法有一些缺点。首先，CentralizedGoldenMaster的镜像往往是一个瓶颈，导致开发人员在原型设计阶段后的生产力下降，因为每个人都必须等待轮到他们访问最新镜像并进行更改。在供应链管理(SCM)领域，这种做法相当于一个带有单独文件锁的集中式系统。只有拥有锁的开发人员才能处理任何给定的文件。这种方法的第二个缺点是图像的再现性。通常通过手动登录到目标系统、使用本机包管理器安装包、配置应用程序和点文件，然后就地修改系统配置文件来管理。一旦这个过程完成，磁盘就会被镜像，然后使用dd命令的实用程序或等效的工具进行分发。同样，这种方法会产生潜在的问题。例如，基于网络的包源可能不再存在，供应商映像提供的底层软件可能会发生变化。脚本可以帮助缓解这些问题。然而，当对配置文件格式或供应商的基础包进行更改时，这些脚本往往很脆弱并且会中断。这种开发模式带来的最后一个问题就是对第三方的依赖。如果硬件供应商的形象发生变化，与企业的设计不符，则可能需要花费大量时间进行调整。分布式构建系统这种为应用程序创建和维护映像的方法依赖于与目标硬件分开的目标映像的生成。这里的开发人员工作流程类似于使用供应链管理(SCM)系统的标准软件开发；镜像完全可以通过工具构建，每个开发者可以独立工作。通过编辑元数据文件（脚本、配方、配置文件等）对系统进行更改，然后重新运行该工具以生成更新的图像。然后使用供应链管理(SCM)系统管理这些元数据文件。各个开发人员可以将最新的更改合并到他们的工作副本中以生成他们的开发映像。在这种情况下，开发人员可以避免相关的瓶颈。然后，构建系统使用标准供应链管理(SCM)技术生成发布映像，以从所有开发人员那里拉取更改。以这种方式工作可以在不降低开发人员生产力的情况下增加开发团队的规模。所有工程师都可以独立工作。此外，此设置可确保企业构建的可重现性。使用标准供应链管理(SCM)工作流程可确保在未来某个时间重新生成特定构建，从而允许长期维护，即使上游供应商不再可用。类似于使用分布式供应链管理(SCM)工具，需要额外的策略来实现可重现的候选图像。各个开发人员都有自己的源代码副本，可以构建自己的测试映像，但要使发布正常工作，开发团队需要建立合并和分支标准，并确保所有特定于发布的更改最终合并到良好的环境中。定义。许多上游项目已经针对此发布策略制定了明确的流程（例如，使用*-stable和*-next分支）。这种方法的主要缺点是不熟悉。例如，将包添加到映像通常需要创建某种配方，然后更新定义以便包二进制文件包含在映像中。这与登录到正在运行的系统时运行apt非常不同。这些系统的学习曲线可能令人望而生畏，但结果更具可预测性和可扩展性，在考虑大规模生产的产品设计时可能是更好的选择。OpenEmbedded和Buildroot等专用构建系统使用此模型，debootstrap和multistrap等分发打包工具也使用此模型。Isar、debos和ELBE等较新的工具也使用此基本模型。还有更多这样的选择，学习一个或多个用于企业设计的包是值得投资的。这些系统的长期可维护性和可重复性将允许企业生成可复制的构建、跟踪所有源代码并消除企业对第三方供应商的依赖，从而降低设计风险。结论需要明确的是，分布式模式确实遇到了一些与金主模式相同的问题，尤其是对第三方的依赖。这是使用别人设计的系统的结果，除非企业选择自己全力以赴，这会在开发和维护方面产生巨大的成本。对于原型设计和概念验证关卡设计，以及开发人员数量较少的团队，GoldenMaster模型可能是正确的选择，因为在此开发阶段时间和预算有限。对于小批量、高接触度的设计，这对于生产使用来说可能是一个可以接受的权衡。对于一般生产用途，在团队规模可扩展性、图像可再现性和开发人员生产力方面的好处大大超过了实施分布式模型的系统的学习曲线和开销。电路板和芯片供应商的支持也广泛用于这些系统，从而降低了使用它们进行开发的前期成本。对于企业推出的新产品，建议在设计之初就仔细考虑用于生成基础操作系统镜像的模型。如果企业选择使用GoldenMaster模型进行原型制作转向分布式模型，则需要确保在企业计划中为这项工作留出足够的时间；根据企业选择的具体工具和要求的范围，以及企业所依赖的代码，对包的开箱即用可用性的估计可能会有很大差异。
