在規(guī)劃超出原型設(shè)計(jì)階段的系統(tǒng)設(shè)計(jì)時(shí)，事情變得更加復(fù)雜。本文主要對(duì)開發(fā)和維護(hù)基本操作系統(tǒng)(OS)映像的機(jī)制進(jìn)行闡述。有許多工具可以幫助解決這個(gè)問題，但在此不會(huì)討論各種工具。這里感興趣的是維持和增強(qiáng)這種形象的基本模式，以及它將如何使人們的生活變得更好或更糟。
生成這些映像有兩種主要模型：
1. Centralized Golden Master
2.分布式構(gòu)建系統(tǒng)
這些類別反映了源代碼管理(SCM)系統(tǒng)的驅(qū)動(dòng)模型，在討論操作系統(tǒng)映像時(shí)，許多關(guān)于集中式和分布式的論點(diǎn)都是適用的。
Centralized Golden Master
業(yè)余愛好者和制造商項(xiàng)目主要使用Centralized Golden Master方法來創(chuàng)建和維護(hù)應(yīng)用程序映像。這一事實(shí)使該模型具有速度和熟悉度的優(yōu)勢(shì)，允許開發(fā)人員快速設(shè)置這樣的系統(tǒng)并使其運(yùn)行。這一速度來自于許多設(shè)備制造商為其現(xiàn)成的硬件提供固定映像的事實(shí)。例如，來自BeagleBone和Raspberry Pi等系列的主板提供即用型操作系統(tǒng)映像和閃存。依靠這些映像意味著只需點(diǎn)擊幾下鼠標(biāo)即可啟動(dòng)并運(yùn)行系統(tǒng)。這些映像通?；谠S多設(shè)備開發(fā)人員已經(jīng)使用的桌面發(fā)行版，例如Debian。多年使用Linux可以直接轉(zhuǎn)移到嵌入式設(shè)計(jì)，包括包裝實(shí)用程序基本保持相同的事實(shí)，而且對(duì)于設(shè)計(jì)人員來說，獲得他們需要的額外軟件包很簡(jiǎn)單。
這種方法有一些缺點(diǎn)。首先，Centralized Golden Master的映像通常是一個(gè)瓶頸，導(dǎo)致原型設(shè)計(jì)階段后開發(fā)人員的工作效率下降，因?yàn)槊總€(gè)人都必須等待輪到他們?cè)L問最新映像并進(jìn)行更改。在供應(yīng)鏈管理(SCM)領(lǐng)域，這種做法相當(dāng)于具有單獨(dú)文件鎖定的集中式系統(tǒng)。只有具有鎖定的開發(fā)人員才能處理任何給定的文件。
這種方法的第二個(gè)缺點(diǎn)是映像再現(xiàn)性。通常通過人工登錄目標(biāo)系統(tǒng)，使用本機(jī)包管理器安裝包、配置應(yīng)用程序和點(diǎn)文件，然后就地修改系統(tǒng)配置文件來管理。完成此過程后，將使用dd命令的實(shí)用程序或等效工具對(duì)磁盤進(jìn)行映像，然后進(jìn)行分發(fā)。
同樣，這種方法會(huì)造成潛在問題。例如，基于網(wǎng)絡(luò)的軟件包源可能不再存在，并且供應(yīng)商映像提供的基礎(chǔ)軟件可能會(huì)更改。腳本可以幫助緩解這些問題。但是，當(dāng)對(duì)配置文件格式或供應(yīng)商的基本軟件包進(jìn)行更改時(shí)，這些腳本往往很脆弱并且會(huì)中斷。
這種開發(fā)模式產(chǎn)生的最后一個(gè)問題是依賴第三方。如果硬件供應(yīng)商的映像更改不適合企業(yè)的設(shè)計(jì)，則可能需要投入大量時(shí)間進(jìn)行調(diào)整。
分布式構(gòu)建系統(tǒng)
這種為應(yīng)用程序創(chuàng)建和維護(hù)映像的方法依賴于與目標(biāo)硬件分離的目標(biāo)映像的生成。這里的開發(fā)人員工作流程類似于使用供應(yīng)鏈管理(SCM)系統(tǒng)的標(biāo)準(zhǔn)軟件開發(fā);映像可以通過工具完全構(gòu)建，每個(gè)開發(fā)人員都可以獨(dú)立工作。通過編輯元數(shù)據(jù)文件(腳本、配方、配置文件等)對(duì)系統(tǒng)進(jìn)行更改，然后重新運(yùn)行工具以生成更新的映像。然后使用供應(yīng)鏈管理(SCM)系統(tǒng)管理這些元數(shù)據(jù)文件。各個(gè)開發(fā)人員可以將最新的更改合并到他們的工作副本中，以生成他們的開發(fā)映像。在這種情況下，開發(fā)人員可以避免相關(guān)的瓶頸。
然后，構(gòu)建系統(tǒng)使用標(biāo)準(zhǔn)供應(yīng)鏈管理(SCM)技術(shù)生成發(fā)布映像，以從所有開發(fā)人員處獲取更改。
以這種方式工作可以增加開發(fā)團(tuán)隊(duì)的規(guī)模，而不會(huì)降低開發(fā)人員的工作效率。所有工程師都可以獨(dú)立工作。此外，這種設(shè)置可確保企業(yè)的構(gòu)建可以重現(xiàn)。使用標(biāo)準(zhǔn)供應(yīng)鏈管理(SCM)工作流可以確保在未來的時(shí)間重新生成特定的構(gòu)建，從而允許長期維護(hù)，即使上游提供程序不再可用。與使用分布式供應(yīng)鏈管理(SCM)工具類似，還需要有其他策略來實(shí)現(xiàn)可重現(xiàn)的候選映像。各個(gè)開發(fā)人員擁有自己的源代碼副本，并且可以構(gòu)建自己的測(cè)試映像，但是為了正確的發(fā)布工作，開發(fā)團(tuán)隊(duì)需要建立合并和分支標(biāo)準(zhǔn)，并確保所有針對(duì)發(fā)布的更改最終合并到明確定義中。許多上游項(xiàng)目已經(jīng)為這種發(fā)布策略定義了明確的流程(例如，使用* -stable和* -next分支)。
這種方法的主要缺點(diǎn)是缺乏熟悉度。例如，向映像添加包通常需要?jiǎng)?chuàng)建某種配方，然后更新定義，以便包二進(jìn)制文件包含在映像中。這與登錄到正在運(yùn)行的系統(tǒng)時(shí)運(yùn)行apt非常不同。這些系統(tǒng)的學(xué)習(xí)曲線可能令人生畏，但結(jié)果更具可預(yù)測(cè)性和可擴(kuò)展性，在考慮大規(guī)模生產(chǎn)的產(chǎn)品設(shè)計(jì)時(shí)可能是更好的選擇。
OpenEmbedded和Buildroot等專用構(gòu)建系統(tǒng)使用此模型，如debootstrap和multistrap等發(fā)行版打包工具。而Isar、debos和ELBE等新工具也使用這個(gè)基本模型。這樣的選擇還有很多，為企業(yè)的設(shè)計(jì)學(xué)習(xí)一個(gè)或多個(gè)這些包是值得投資的。這些系統(tǒng)的長期可維護(hù)性和可重復(fù)性將允許企業(yè)生成可重現(xiàn)的構(gòu)建、跟蹤所有源代碼，并消除企業(yè)對(duì)第三方提供商的依賴性，從而降低設(shè)計(jì)風(fēng)險(xiǎn)。
結(jié)論
需要明確的是，分布式模型確實(shí)遇到了與Golden Maste模型相同的一些問題，尤其是對(duì)第三方的依賴。這是使用由他人設(shè)計(jì)的系統(tǒng)的結(jié)果，除非企業(yè)選擇自己完全采用的方法，而這種方法在開發(fā)和維護(hù)方面會(huì)帶來巨大的成本。
對(duì)于原型設(shè)計(jì)和概念驗(yàn)證級(jí)別設(shè)計(jì)，以及由少數(shù)開發(fā)人員組成的團(tuán)隊(duì)，Golden Master模型可能是正確的選擇，因?yàn)樵诖穗A段的開發(fā)中存在時(shí)間和預(yù)算限制。對(duì)于小批量、高接觸設(shè)計(jì)，這可能是一個(gè)可接受的權(quán)衡生產(chǎn)使用。
對(duì)于一般生產(chǎn)用途，團(tuán)隊(duì)規(guī)模可擴(kuò)展性、映像再現(xiàn)性、開發(fā)人員生產(chǎn)力方面的好處大大超過了實(shí)現(xiàn)分布式模型的系統(tǒng)的學(xué)習(xí)曲線和開銷。板卡和芯片供應(yīng)商的支持也在這些系統(tǒng)中廣泛使用，降低了使用它們進(jìn)行開發(fā)的前期成本。對(duì)于企業(yè)推出的新產(chǎn)品，建議在認(rèn)真考慮用于生成基本操作系統(tǒng)映像的模型的情況下啟動(dòng)設(shè)計(jì)。如果企業(yè)選擇使用Golden Master模型進(jìn)行原型設(shè)計(jì)以轉(zhuǎn)移到分布式模型，需要確保在企業(yè)的計(jì)劃中為此工作提供足夠的時(shí)間;根據(jù)企業(yè)選擇的具體工具以及要求的范圍，以及企業(yè)的代碼所依賴的軟件包的開箱即用的可用性，其估算值會(huì)有很大差異。
京公網(wǎng)安備 11010502049343號(hào)