在當今由物聯網(IOT)驅動的互聯嵌入式設備市場中，開發中的大部分設備都是以某種形式的Linux為基礎的。具有現成Linux發行版的低成本電路板的普及應用是這方面的關鍵驅動因素。而獲取硬件，構建自定義代碼，將設備連接到其他硬件外圍設備和互聯網中，以及使用商業云提供商進行設備管理從未如此簡單。開發人員或開發團隊可以快速構建新應用程序的原型，并將設備提供給潛在用戶。這是一件好事，將產生許多有趣的新應用，但也產生了許多不良的應用。

在規劃超出原型設計階段的系統設計時，事情變得更加復雜。本文主要對開發和維護基本操作系統(OS)映像的機制進行闡述。有許多工具可以幫助解決這個問題，但在此不會討論各種工具。這里感興趣的是維持和增強這種形象的基本模式，以及它將如何使人們的生活變得更好或更糟。

生成這些映像有兩種主要模型：

• Centralized Golden Master
• 分布式構建系統

這些類別反映了源代碼管理(SCM)系統的驅動模型，在討論操作系統映像時，許多關于集中式和分布式的論點都是適用的。

[[267065]]

Centralized Golden Master

業余愛好者和制造商項目主要使用Centralized Golden Master方法來創建和維護應用程序映像。這一事實使該模型具有速度和熟悉度的優勢，允許開發人員快速設置這樣的系統并使其運行。這一速度來自于許多設備制造商為其現成的硬件提供固定映像的事實。例如，來自BeagleBone和Raspberry Pi等系列的主板提供即用型操作系統映像和閃存。依靠這些映像意味著只需點擊幾下鼠標即可啟動并運行系統。這些映像通常基于許多設備開發人員已經使用的桌面發行版，例如Debian。多年使用Linux可以直接轉移到嵌入式設計，包括包裝實用程序基本保持相同的事實，而且對于設計人員來說，獲得他們需要的額外軟件包很簡單。

這種方法有一些缺點。首先，Centralized Golden Master的映像通常是一個瓶頸，導致原型設計階段后開發人員的工作效率下降，因為每個人都必須等待輪到他們訪問***映像并進行更改。在供應鏈管理(SCM)領域，這種做法相當于具有單獨文件鎖定的集中式系統。只有具有鎖定的開發人員才能處理任何給定的文件。

這種方法的第二個缺點是映像再現性。通常通過人工登錄目標系統，使用本機包管理器安裝包、配置應用程序和點文件，然后就地修改系統配置文件來管理。完成此過程后，將使用dd命令的實用程序或等效工具對磁盤進行映像，然后進行分發。

同樣，這種方法會造成潛在問題。例如，基于網絡的軟件包源可能不再存在，并且供應商映像提供的基礎軟件可能會更改。腳本可以幫助緩解這些問題。但是，當對配置文件格式或供應商的基本軟件包進行更改時，這些腳本往往很脆弱并且會中斷。

這種開發模式產生的***一個問題是依賴第三方。如果硬件供應商的映像更改不適合企業的設計，則可能需要投入大量時間進行調整。

分布式構建系統

這種為應用程序創建和維護映像的方法依賴于與目標硬件分離的目標映像的生成。這里的開發人員工作流程類似于使用供應鏈管理(SCM)系統的標準軟件開發;映像可以通過工具完全構建，每個開發人員都可以獨立工作。通過編輯元數據文件(腳本、配方、配置文件等)對系統進行更改，然后重新運行工具以生成更新的映像。然后使用供應鏈管理(SCM)系統管理這些元數據文件。各個開發人員可以將***的更改合并到他們的工作副本中，以生成他們的開發映像。在這種情況下，開發人員可以避免相關的瓶頸。

然后，構建系統使用標準供應鏈管理(SCM)技術生成發布映像，以從所有開發人員處獲取更改。

以這種方式工作可以增加開發團隊的規模，而不會降低開發人員的工作效率。所有工程師都可以獨立工作。此外，這種設置可確保企業的構建可以重現。使用標準供應鏈管理(SCM)工作流可以確保在未來的時間重新生成特定的構建，從而允許長期維護，即使上游提供程序不再可用。與使用分布式供應鏈管理(SCM)工具類似，還需要有其他策略來實現可重現的候選映像。各個開發人員擁有自己的源代碼副本，并且可以構建自己的測試映像，但是為了正確的發布工作，開發團隊需要建立合并和分支標準，并確保所有針對發布的更改最終合并到明確定義中。許多上游項目已經為這種發布策略定義了明確的流程(例如，使用* -stable和* -next分支)。

這種方法的主要缺點是缺乏熟悉度。例如，向映像添加包通常需要創建某種配方，然后更新定義，以便包二進制文件包含在映像中。這與登錄到正在運行的系統時運行apt非常不同。這些系統的學習曲線可能令人生畏，但結果更具可預測性和可擴展性，在考慮大規模生產的產品設計時可能是更好的選擇。

OpenEmbedded和Buildroot等專用構建系統使用此模型，如debootstrap和multistrap等發行版打包工具。而Isar、debos和ELBE等新工具也使用這個基本模型。這樣的選擇還有很多，為企業的設計學習一個或多個這些包是值得投資的。這些系統的長期可維護性和可重復性將允許企業生成可重現的構建、跟蹤所有源代碼，并消除企業對第三方提供商的依賴性，從而降低設計風險。

結論

需要明確的是，分布式模型確實遇到了與Golden Maste模型相同的一些問題，尤其是對第三方的依賴。這是使用由他人設計的系統的結果，除非企業選擇自己完全采用的方法，而這種方法在開發和維護方面會帶來巨大的成本。

對于原型設計和概念驗證級別設計，以及由少數開發人員組成的團隊，Golden Master模型可能是正確的選擇，因為在此階段的開發中存在時間和預算限制。對于小批量、高接觸設計，這可能是一個可接受的權衡生產使用。

對于一般生產用途，團隊規模可擴展性、映像再現性、開發人員生產力方面的好處大大超過了實現分布式模型的系統的學習曲線和開銷。板卡和芯片供應商的支持也在這些系統中廣泛使用，降低了使用它們進行開發的前期成本。對于企業推出的新產品，建議在認真考慮用于生成基本操作系統映像的模型的情況下啟動設計。如果企業選擇使用Golden Master模型進行原型設計以轉移到分布式模型，需要確保在企業的計劃中為此工作提供足夠的時間;根據企業選擇的具體工具以及要求的范圍，以及企業的代碼所依賴的軟件包的開箱即用的可用性，其估算值會有很大差異。